wbrawner/openssl
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
openssl/crypto/dso/dso_err.c

145 lines
6.3 KiB
C
Raw Normal View History

This is a set of startup code for the DSO support, it's not yet linked into the build process (an upcoming commit no doubt), and is very much *new* code - what that means is that it compiles ok - usually. It certainly doesn't mean it runs well or even properly yet. Please don't muck round with this unless you're looking to help out and hunt bugs. :-) Currently this code doesn't have any support for controlling the "load" behaviour (eg. paths, filename translations, etc). That'll be handled using DSO_ctrl() and various flags, once we work out a sensible set of flags.
2000-04-04 21:57:11 +00:00
/* crypto/dso/dso_err.c */
/* ====================================================================
There's an ongoing project to bring some kind of path selection mechanism to the ENGINE framework. This means there there are going to be new functionality for the DSO part, and ultimately some way of merging two file specifications together. This commit places the merging code into the repository. It's currently not used anywhere, and hasn't been tested at all. It may be full of errors, including syntactical ones. Those will be fixed as promptly as possible.
2002-07-15 15:35:40 +00:00
* Copyright (c) 1999-2002 The OpenSSL Project. All rights reserved.
This is a set of startup code for the DSO support, it's not yet linked into the build process (an upcoming commit no doubt), and is very much *new* code - what that means is that it compiles ok - usually. It certainly doesn't mean it runs well or even properly yet. Please don't muck round with this unless you're looking to help out and hunt bugs. :-) Currently this code doesn't have any support for controlling the "load" behaviour (eg. paths, filename translations, etc). That'll be handled using DSO_ctrl() and various flags, once we work out a sensible set of flags.
2000-04-04 21:57:11 +00:00
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
*
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
*
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in
* the documentation and/or other materials provided with the
* distribution.
*
* 3. All advertising materials mentioning features or use of this
* software must display the following acknowledgment:
* "This product includes software developed by the OpenSSL Project
* for use in the OpenSSL Toolkit. (http://www.OpenSSL.org/)"
*
* 4. The names "OpenSSL Toolkit" and "OpenSSL Project" must not be used to
* endorse or promote products derived from this software without
* prior written permission. For written permission, please contact
* openssl-core@OpenSSL.org.
*
* 5. Products derived from this software may not be called "OpenSSL"
* nor may "OpenSSL" appear in their names without prior written
* permission of the OpenSSL Project.
*
* 6. Redistributions of any form whatsoever must retain the following
* acknowledgment:
* "This product includes software developed by the OpenSSL Project
* for use in the OpenSSL Toolkit (http://www.OpenSSL.org/)"
*
* THIS SOFTWARE IS PROVIDED BY THE OpenSSL PROJECT ``AS IS'' AND ANY
* EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
* PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE OpenSSL PROJECT OR
* ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
* SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
* NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
* LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
* STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
* ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED
* OF THE POSSIBILITY OF SUCH DAMAGE.
* ====================================================================
*
* This product includes cryptographic software written by Eric Young
* (eay@cryptsoft.com). This product includes software written by Tim
* Hudson (tjh@cryptsoft.com).
*
*/
/* NOTE: this file was auto generated by the mkerr.pl script: any changes
* made to it will be overwritten when the script next updates this file,
* only reason strings will be preserved.
*/
#include <stdio.h>
#include <openssl/err.h>
#include <openssl/dso.h>
/* BEGIN ERROR CODES */
Make all configuration macros available for application by making sure they are available in opensslconf.h, by giving them names starting with "OPENSSL_" to avoid conflicts with other packages and by making sure e_os2.h will cover all platform-specific cases together with opensslconf.h. I've checked fairly well that nothing breaks with this (apart from external software that will adapt if they have used something like NO_KRB5), but I can't guarantee it completely, so a review of this change would be a good thing.
2001-02-19 16:06:34 +00:00
#ifndef OPENSSL_NO_ERR
This is a set of startup code for the DSO support, it's not yet linked into the build process (an upcoming commit no doubt), and is very much *new* code - what that means is that it compiles ok - usually. It certainly doesn't mean it runs well or even properly yet. Please don't muck round with this unless you're looking to help out and hunt bugs. :-) Currently this code doesn't have any support for controlling the "load" behaviour (eg. paths, filename translations, etc). That'll be handled using DSO_ctrl() and various flags, once we work out a sensible set of flags.
2000-04-04 21:57:11 +00:00
static ERR_STRING_DATA DSO_str_functs[]=
{
Currently the DSO_METHOD interface has one entry point to bind all "symbols" including functions (of all prototypes( and variables. Whilst casting any function type to another violates ANSI C (I believe), it is a necessary evil in shared-library APIs. However, it is quite conceivable that functions in general and data symbols could very well be represented differently to each other on some systems, as Bodo said; > Since the function/object distinction is a lot more likely to be > important on real-life platforms supporting DSO *and* it can be quite > easily done *and* it will silence compilers that don't like > assignments from void pointers to function pointer variables, why > not do it? I agree. So this change splits the "dso_bind" handler in DSO_METHOD into "dso_bind_var" and "dso_bind_func". Similarly the exported function DSO_bind() has been split in two. I've also put together changes for the various DSO_METHOD implementations, but so far only DSO_dlfcn() has been tested. BTW: The prototype for dso_bind had been a bit strange so I've taken the opportunity to change its shape (in both variations). Also, the README has been updated - particularly with a note about using customised native name-translation for shared libraries (and that you can't do it yet).
2000-06-16 10:45:36 +00:00
{ERR_PACK(0,DSO_F_DLFCN_BIND_FUNC,0), "DLFCN_BIND_FUNC"},
{ERR_PACK(0,DSO_F_DLFCN_BIND_VAR,0), "DLFCN_BIND_VAR"},
{ERR_PACK(0,DSO_F_DLFCN_LOAD,0), "DLFCN_LOAD"},
There's an ongoing project to bring some kind of path selection mechanism to the ENGINE framework. This means there there are going to be new functionality for the DSO part, and ultimately some way of merging two file specifications together. This commit places the merging code into the repository. It's currently not used anywhere, and hasn't been tested at all. It may be full of errors, including syntactical ones. Those will be fixed as promptly as possible.
2002-07-15 15:35:40 +00:00
{ERR_PACK(0,DSO_F_DLFCN_MERGER,0), "DLFCN_MERGER"},
This changes the behaviour of the DSO mechanism for determining an appropriate filename translation on the host system. Apart from this point, users should also note that there's a slight change in the API functions too. The DSO now contains its own to-be-converted filename ("dso->filename"), and at the time the DSO loads the "dso->loaded_filename" value is set to the translated form. As such, this also provides an impicit way of determining if the DSO is currently loaded or not. Except, perhaps, VMS .... :-) The various DSO_METHODs have been updated for this mechanism except VMS which is deliberately broken for now, Richard is going to look at how to fit it in (the source comments in there explain "the issue"). Basically, the new callback scheme allows the filename conversion to (a) be turned off altogether through the use of the DSO_FLAG_NO_NAME_TRANSLATION flag, (b) be handled in the default way using the default DSO_METHOD's converter (c) overriden per-DSO by setting the override callback (d) a mix of (b) and (c) - eg. implement an override callback that; (i) checks if we're win32 "if(strstr(dso->meth->name, "win32"))..." and if so, convert "blah" into "blah32.dll" (the default is otherwise to make it "blah.dll"). (ii) default to the normal behaviour - eg. we're not on win32, so finish with (return dso->meth->dso_name_converter(dso,NULL)). (e) be retried a number of times by writing a new DSO_METHOD where the "dso_load()" handler will call the converter repeatedly. Then the custom converter could use state information in the DSO to suggest different conversions or paths each time it is invoked.
2000-10-26 17:38:59 +00:00
{ERR_PACK(0,DSO_F_DLFCN_NAME_CONVERTER,0), "DLFCN_NAME_CONVERTER"},
Currently the DSO_METHOD interface has one entry point to bind all "symbols" including functions (of all prototypes( and variables. Whilst casting any function type to another violates ANSI C (I believe), it is a necessary evil in shared-library APIs. However, it is quite conceivable that functions in general and data symbols could very well be represented differently to each other on some systems, as Bodo said; > Since the function/object distinction is a lot more likely to be > important on real-life platforms supporting DSO *and* it can be quite > easily done *and* it will silence compilers that don't like > assignments from void pointers to function pointer variables, why > not do it? I agree. So this change splits the "dso_bind" handler in DSO_METHOD into "dso_bind_var" and "dso_bind_func". Similarly the exported function DSO_bind() has been split in two. I've also put together changes for the various DSO_METHOD implementations, but so far only DSO_dlfcn() has been tested. BTW: The prototype for dso_bind had been a bit strange so I've taken the opportunity to change its shape (in both variations). Also, the README has been updated - particularly with a note about using customised native name-translation for shared libraries (and that you can't do it yet).
2000-06-16 10:45:36 +00:00
{ERR_PACK(0,DSO_F_DLFCN_UNLOAD,0), "DLFCN_UNLOAD"},
{ERR_PACK(0,DSO_F_DL_BIND_FUNC,0), "DL_BIND_FUNC"},
{ERR_PACK(0,DSO_F_DL_BIND_VAR,0), "DL_BIND_VAR"},
{ERR_PACK(0,DSO_F_DL_LOAD,0), "DL_LOAD"},
There's an ongoing project to bring some kind of path selection mechanism to the ENGINE framework. This means there there are going to be new functionality for the DSO part, and ultimately some way of merging two file specifications together. This commit places the merging code into the repository. It's currently not used anywhere, and hasn't been tested at all. It may be full of errors, including syntactical ones. Those will be fixed as promptly as possible.
2002-07-15 15:35:40 +00:00
{ERR_PACK(0,DSO_F_DL_MERGER,0), "DL_MERGER"},
This changes the behaviour of the DSO mechanism for determining an appropriate filename translation on the host system. Apart from this point, users should also note that there's a slight change in the API functions too. The DSO now contains its own to-be-converted filename ("dso->filename"), and at the time the DSO loads the "dso->loaded_filename" value is set to the translated form. As such, this also provides an impicit way of determining if the DSO is currently loaded or not. Except, perhaps, VMS .... :-) The various DSO_METHODs have been updated for this mechanism except VMS which is deliberately broken for now, Richard is going to look at how to fit it in (the source comments in there explain "the issue"). Basically, the new callback scheme allows the filename conversion to (a) be turned off altogether through the use of the DSO_FLAG_NO_NAME_TRANSLATION flag, (b) be handled in the default way using the default DSO_METHOD's converter (c) overriden per-DSO by setting the override callback (d) a mix of (b) and (c) - eg. implement an override callback that; (i) checks if we're win32 "if(strstr(dso->meth->name, "win32"))..." and if so, convert "blah" into "blah32.dll" (the default is otherwise to make it "blah.dll"). (ii) default to the normal behaviour - eg. we're not on win32, so finish with (return dso->meth->dso_name_converter(dso,NULL)). (e) be retried a number of times by writing a new DSO_METHOD where the "dso_load()" handler will call the converter repeatedly. Then the custom converter could use state information in the DSO to suggest different conversions or paths each time it is invoked.
2000-10-26 17:38:59 +00:00
{ERR_PACK(0,DSO_F_DL_NAME_CONVERTER,0), "DL_NAME_CONVERTER"},
Currently the DSO_METHOD interface has one entry point to bind all "symbols" including functions (of all prototypes( and variables. Whilst casting any function type to another violates ANSI C (I believe), it is a necessary evil in shared-library APIs. However, it is quite conceivable that functions in general and data symbols could very well be represented differently to each other on some systems, as Bodo said; > Since the function/object distinction is a lot more likely to be > important on real-life platforms supporting DSO *and* it can be quite > easily done *and* it will silence compilers that don't like > assignments from void pointers to function pointer variables, why > not do it? I agree. So this change splits the "dso_bind" handler in DSO_METHOD into "dso_bind_var" and "dso_bind_func". Similarly the exported function DSO_bind() has been split in two. I've also put together changes for the various DSO_METHOD implementations, but so far only DSO_dlfcn() has been tested. BTW: The prototype for dso_bind had been a bit strange so I've taken the opportunity to change its shape (in both variations). Also, the README has been updated - particularly with a note about using customised native name-translation for shared libraries (and that you can't do it yet).
2000-06-16 10:45:36 +00:00
{ERR_PACK(0,DSO_F_DL_UNLOAD,0), "DL_UNLOAD"},
{ERR_PACK(0,DSO_F_DSO_BIND_FUNC,0), "DSO_bind_func"},
{ERR_PACK(0,DSO_F_DSO_BIND_VAR,0), "DSO_bind_var"},
This changes the behaviour of the DSO mechanism for determining an appropriate filename translation on the host system. Apart from this point, users should also note that there's a slight change in the API functions too. The DSO now contains its own to-be-converted filename ("dso->filename"), and at the time the DSO loads the "dso->loaded_filename" value is set to the translated form. As such, this also provides an impicit way of determining if the DSO is currently loaded or not. Except, perhaps, VMS .... :-) The various DSO_METHODs have been updated for this mechanism except VMS which is deliberately broken for now, Richard is going to look at how to fit it in (the source comments in there explain "the issue"). Basically, the new callback scheme allows the filename conversion to (a) be turned off altogether through the use of the DSO_FLAG_NO_NAME_TRANSLATION flag, (b) be handled in the default way using the default DSO_METHOD's converter (c) overriden per-DSO by setting the override callback (d) a mix of (b) and (c) - eg. implement an override callback that; (i) checks if we're win32 "if(strstr(dso->meth->name, "win32"))..." and if so, convert "blah" into "blah32.dll" (the default is otherwise to make it "blah.dll"). (ii) default to the normal behaviour - eg. we're not on win32, so finish with (return dso->meth->dso_name_converter(dso,NULL)). (e) be retried a number of times by writing a new DSO_METHOD where the "dso_load()" handler will call the converter repeatedly. Then the custom converter could use state information in the DSO to suggest different conversions or paths each time it is invoked.
2000-10-26 17:38:59 +00:00
{ERR_PACK(0,DSO_F_DSO_CONVERT_FILENAME,0), "DSO_convert_filename"},
Currently the DSO_METHOD interface has one entry point to bind all "symbols" including functions (of all prototypes( and variables. Whilst casting any function type to another violates ANSI C (I believe), it is a necessary evil in shared-library APIs. However, it is quite conceivable that functions in general and data symbols could very well be represented differently to each other on some systems, as Bodo said; > Since the function/object distinction is a lot more likely to be > important on real-life platforms supporting DSO *and* it can be quite > easily done *and* it will silence compilers that don't like > assignments from void pointers to function pointer variables, why > not do it? I agree. So this change splits the "dso_bind" handler in DSO_METHOD into "dso_bind_var" and "dso_bind_func". Similarly the exported function DSO_bind() has been split in two. I've also put together changes for the various DSO_METHOD implementations, but so far only DSO_dlfcn() has been tested. BTW: The prototype for dso_bind had been a bit strange so I've taken the opportunity to change its shape (in both variations). Also, the README has been updated - particularly with a note about using customised native name-translation for shared libraries (and that you can't do it yet).
2000-06-16 10:45:36 +00:00
{ERR_PACK(0,DSO_F_DSO_CTRL,0), "DSO_ctrl"},
This is a set of startup code for the DSO support, it's not yet linked into the build process (an upcoming commit no doubt), and is very much *new* code - what that means is that it compiles ok - usually. It certainly doesn't mean it runs well or even properly yet. Please don't muck round with this unless you're looking to help out and hunt bugs. :-) Currently this code doesn't have any support for controlling the "load" behaviour (eg. paths, filename translations, etc). That'll be handled using DSO_ctrl() and various flags, once we work out a sensible set of flags.
2000-04-04 21:57:11 +00:00
{ERR_PACK(0,DSO_F_DSO_FREE,0), "DSO_free"},
This changes the behaviour of the DSO mechanism for determining an appropriate filename translation on the host system. Apart from this point, users should also note that there's a slight change in the API functions too. The DSO now contains its own to-be-converted filename ("dso->filename"), and at the time the DSO loads the "dso->loaded_filename" value is set to the translated form. As such, this also provides an impicit way of determining if the DSO is currently loaded or not. Except, perhaps, VMS .... :-) The various DSO_METHODs have been updated for this mechanism except VMS which is deliberately broken for now, Richard is going to look at how to fit it in (the source comments in there explain "the issue"). Basically, the new callback scheme allows the filename conversion to (a) be turned off altogether through the use of the DSO_FLAG_NO_NAME_TRANSLATION flag, (b) be handled in the default way using the default DSO_METHOD's converter (c) overriden per-DSO by setting the override callback (d) a mix of (b) and (c) - eg. implement an override callback that; (i) checks if we're win32 "if(strstr(dso->meth->name, "win32"))..." and if so, convert "blah" into "blah32.dll" (the default is otherwise to make it "blah.dll"). (ii) default to the normal behaviour - eg. we're not on win32, so finish with (return dso->meth->dso_name_converter(dso,NULL)). (e) be retried a number of times by writing a new DSO_METHOD where the "dso_load()" handler will call the converter repeatedly. Then the custom converter could use state information in the DSO to suggest different conversions or paths each time it is invoked.
2000-10-26 17:38:59 +00:00
{ERR_PACK(0,DSO_F_DSO_GET_FILENAME,0), "DSO_get_filename"},
{ERR_PACK(0,DSO_F_DSO_GET_LOADED_FILENAME,0), "DSO_get_loaded_filename"},
This is a set of startup code for the DSO support, it's not yet linked into the build process (an upcoming commit no doubt), and is very much *new* code - what that means is that it compiles ok - usually. It certainly doesn't mean it runs well or even properly yet. Please don't muck round with this unless you're looking to help out and hunt bugs. :-) Currently this code doesn't have any support for controlling the "load" behaviour (eg. paths, filename translations, etc). That'll be handled using DSO_ctrl() and various flags, once we work out a sensible set of flags.
2000-04-04 21:57:11 +00:00
{ERR_PACK(0,DSO_F_DSO_LOAD,0), "DSO_load"},
There's an ongoing project to bring some kind of path selection mechanism to the ENGINE framework. This means there there are going to be new functionality for the DSO part, and ultimately some way of merging two file specifications together. This commit places the merging code into the repository. It's currently not used anywhere, and hasn't been tested at all. It may be full of errors, including syntactical ones. Those will be fixed as promptly as possible.
2002-07-15 15:35:40 +00:00
{ERR_PACK(0,DSO_F_DSO_MERGE,0), "DSO_merge"},
This is a set of startup code for the DSO support, it's not yet linked into the build process (an upcoming commit no doubt), and is very much *new* code - what that means is that it compiles ok - usually. It certainly doesn't mean it runs well or even properly yet. Please don't muck round with this unless you're looking to help out and hunt bugs. :-) Currently this code doesn't have any support for controlling the "load" behaviour (eg. paths, filename translations, etc). That'll be handled using DSO_ctrl() and various flags, once we work out a sensible set of flags.
2000-04-04 21:57:11 +00:00
{ERR_PACK(0,DSO_F_DSO_NEW_METHOD,0), "DSO_new_method"},
This changes the behaviour of the DSO mechanism for determining an appropriate filename translation on the host system. Apart from this point, users should also note that there's a slight change in the API functions too. The DSO now contains its own to-be-converted filename ("dso->filename"), and at the time the DSO loads the "dso->loaded_filename" value is set to the translated form. As such, this also provides an impicit way of determining if the DSO is currently loaded or not. Except, perhaps, VMS .... :-) The various DSO_METHODs have been updated for this mechanism except VMS which is deliberately broken for now, Richard is going to look at how to fit it in (the source comments in there explain "the issue"). Basically, the new callback scheme allows the filename conversion to (a) be turned off altogether through the use of the DSO_FLAG_NO_NAME_TRANSLATION flag, (b) be handled in the default way using the default DSO_METHOD's converter (c) overriden per-DSO by setting the override callback (d) a mix of (b) and (c) - eg. implement an override callback that; (i) checks if we're win32 "if(strstr(dso->meth->name, "win32"))..." and if so, convert "blah" into "blah32.dll" (the default is otherwise to make it "blah.dll"). (ii) default to the normal behaviour - eg. we're not on win32, so finish with (return dso->meth->dso_name_converter(dso,NULL)). (e) be retried a number of times by writing a new DSO_METHOD where the "dso_load()" handler will call the converter repeatedly. Then the custom converter could use state information in the DSO to suggest different conversions or paths each time it is invoked.
2000-10-26 17:38:59 +00:00
{ERR_PACK(0,DSO_F_DSO_SET_FILENAME,0), "DSO_set_filename"},
{ERR_PACK(0,DSO_F_DSO_SET_NAME_CONVERTER,0), "DSO_set_name_converter"},
Add a "_up" -> "_up_ref" change to libeay.num that was missing from the recent changes. Also, do the same change to the DSO_up() function.
2001-09-04 20:40:41 +00:00
{ERR_PACK(0,DSO_F_DSO_UP_REF,0), "DSO_up_ref"},
A DSO method for VMS was missing, and I had the code lying around...
2000-09-15 21:22:50 +00:00
{ERR_PACK(0,DSO_F_VMS_BIND_VAR,0), "VMS_BIND_VAR"},
{ERR_PACK(0,DSO_F_VMS_LOAD,0), "VMS_LOAD"},
There's an ongoing project to bring some kind of path selection mechanism to the ENGINE framework. This means there there are going to be new functionality for the DSO part, and ultimately some way of merging two file specifications together. This commit places the merging code into the repository. It's currently not used anywhere, and hasn't been tested at all. It may be full of errors, including syntactical ones. Those will be fixed as promptly as possible.
2002-07-15 15:35:40 +00:00
{ERR_PACK(0,DSO_F_VMS_MERGER,0), "VMS_MERGER"},
A DSO method for VMS was missing, and I had the code lying around...
2000-09-15 21:22:50 +00:00
{ERR_PACK(0,DSO_F_VMS_UNLOAD,0), "VMS_UNLOAD"},
Currently the DSO_METHOD interface has one entry point to bind all "symbols" including functions (of all prototypes( and variables. Whilst casting any function type to another violates ANSI C (I believe), it is a necessary evil in shared-library APIs. However, it is quite conceivable that functions in general and data symbols could very well be represented differently to each other on some systems, as Bodo said; > Since the function/object distinction is a lot more likely to be > important on real-life platforms supporting DSO *and* it can be quite > easily done *and* it will silence compilers that don't like > assignments from void pointers to function pointer variables, why > not do it? I agree. So this change splits the "dso_bind" handler in DSO_METHOD into "dso_bind_var" and "dso_bind_func". Similarly the exported function DSO_bind() has been split in two. I've also put together changes for the various DSO_METHOD implementations, but so far only DSO_dlfcn() has been tested. BTW: The prototype for dso_bind had been a bit strange so I've taken the opportunity to change its shape (in both variations). Also, the README has been updated - particularly with a note about using customised native name-translation for shared libraries (and that you can't do it yet).
2000-06-16 10:45:36 +00:00
{ERR_PACK(0,DSO_F_WIN32_BIND_FUNC,0), "WIN32_BIND_FUNC"},
{ERR_PACK(0,DSO_F_WIN32_BIND_VAR,0), "WIN32_BIND_VAR"},
{ERR_PACK(0,DSO_F_WIN32_LOAD,0), "WIN32_LOAD"},
There's an ongoing project to bring some kind of path selection mechanism to the ENGINE framework. This means there there are going to be new functionality for the DSO part, and ultimately some way of merging two file specifications together. This commit places the merging code into the repository. It's currently not used anywhere, and hasn't been tested at all. It may be full of errors, including syntactical ones. Those will be fixed as promptly as possible.
2002-07-15 15:35:40 +00:00
{ERR_PACK(0,DSO_F_WIN32_MERGER,0), "WIN32_MERGER"},
This changes the behaviour of the DSO mechanism for determining an appropriate filename translation on the host system. Apart from this point, users should also note that there's a slight change in the API functions too. The DSO now contains its own to-be-converted filename ("dso->filename"), and at the time the DSO loads the "dso->loaded_filename" value is set to the translated form. As such, this also provides an impicit way of determining if the DSO is currently loaded or not. Except, perhaps, VMS .... :-) The various DSO_METHODs have been updated for this mechanism except VMS which is deliberately broken for now, Richard is going to look at how to fit it in (the source comments in there explain "the issue"). Basically, the new callback scheme allows the filename conversion to (a) be turned off altogether through the use of the DSO_FLAG_NO_NAME_TRANSLATION flag, (b) be handled in the default way using the default DSO_METHOD's converter (c) overriden per-DSO by setting the override callback (d) a mix of (b) and (c) - eg. implement an override callback that; (i) checks if we're win32 "if(strstr(dso->meth->name, "win32"))..." and if so, convert "blah" into "blah32.dll" (the default is otherwise to make it "blah.dll"). (ii) default to the normal behaviour - eg. we're not on win32, so finish with (return dso->meth->dso_name_converter(dso,NULL)). (e) be retried a number of times by writing a new DSO_METHOD where the "dso_load()" handler will call the converter repeatedly. Then the custom converter could use state information in the DSO to suggest different conversions or paths each time it is invoked.
2000-10-26 17:38:59 +00:00
{ERR_PACK(0,DSO_F_WIN32_NAME_CONVERTER,0), "WIN32_NAME_CONVERTER"},
Currently the DSO_METHOD interface has one entry point to bind all "symbols" including functions (of all prototypes( and variables. Whilst casting any function type to another violates ANSI C (I believe), it is a necessary evil in shared-library APIs. However, it is quite conceivable that functions in general and data symbols could very well be represented differently to each other on some systems, as Bodo said; > Since the function/object distinction is a lot more likely to be > important on real-life platforms supporting DSO *and* it can be quite > easily done *and* it will silence compilers that don't like > assignments from void pointers to function pointer variables, why > not do it? I agree. So this change splits the "dso_bind" handler in DSO_METHOD into "dso_bind_var" and "dso_bind_func". Similarly the exported function DSO_bind() has been split in two. I've also put together changes for the various DSO_METHOD implementations, but so far only DSO_dlfcn() has been tested. BTW: The prototype for dso_bind had been a bit strange so I've taken the opportunity to change its shape (in both variations). Also, the README has been updated - particularly with a note about using customised native name-translation for shared libraries (and that you can't do it yet).
2000-06-16 10:45:36 +00:00
{ERR_PACK(0,DSO_F_WIN32_UNLOAD,0), "WIN32_UNLOAD"},
This is a set of startup code for the DSO support, it's not yet linked into the build process (an upcoming commit no doubt), and is very much *new* code - what that means is that it compiles ok - usually. It certainly doesn't mean it runs well or even properly yet. Please don't muck round with this unless you're looking to help out and hunt bugs. :-) Currently this code doesn't have any support for controlling the "load" behaviour (eg. paths, filename translations, etc). That'll be handled using DSO_ctrl() and various flags, once we work out a sensible set of flags.
2000-04-04 21:57:11 +00:00
{0,NULL}
};
static ERR_STRING_DATA DSO_str_reasons[]=
{
Currently the DSO_METHOD interface has one entry point to bind all "symbols" including functions (of all prototypes( and variables. Whilst casting any function type to another violates ANSI C (I believe), it is a necessary evil in shared-library APIs. However, it is quite conceivable that functions in general and data symbols could very well be represented differently to each other on some systems, as Bodo said; > Since the function/object distinction is a lot more likely to be > important on real-life platforms supporting DSO *and* it can be quite > easily done *and* it will silence compilers that don't like > assignments from void pointers to function pointer variables, why > not do it? I agree. So this change splits the "dso_bind" handler in DSO_METHOD into "dso_bind_var" and "dso_bind_func". Similarly the exported function DSO_bind() has been split in two. I've also put together changes for the various DSO_METHOD implementations, but so far only DSO_dlfcn() has been tested. BTW: The prototype for dso_bind had been a bit strange so I've taken the opportunity to change its shape (in both variations). Also, the README has been updated - particularly with a note about using customised native name-translation for shared libraries (and that you can't do it yet).
2000-06-16 10:45:36 +00:00
{DSO_R_CTRL_FAILED ,"control command failed"},
This changes the behaviour of the DSO mechanism for determining an appropriate filename translation on the host system. Apart from this point, users should also note that there's a slight change in the API functions too. The DSO now contains its own to-be-converted filename ("dso->filename"), and at the time the DSO loads the "dso->loaded_filename" value is set to the translated form. As such, this also provides an impicit way of determining if the DSO is currently loaded or not. Except, perhaps, VMS .... :-) The various DSO_METHODs have been updated for this mechanism except VMS which is deliberately broken for now, Richard is going to look at how to fit it in (the source comments in there explain "the issue"). Basically, the new callback scheme allows the filename conversion to (a) be turned off altogether through the use of the DSO_FLAG_NO_NAME_TRANSLATION flag, (b) be handled in the default way using the default DSO_METHOD's converter (c) overriden per-DSO by setting the override callback (d) a mix of (b) and (c) - eg. implement an override callback that; (i) checks if we're win32 "if(strstr(dso->meth->name, "win32"))..." and if so, convert "blah" into "blah32.dll" (the default is otherwise to make it "blah.dll"). (ii) default to the normal behaviour - eg. we're not on win32, so finish with (return dso->meth->dso_name_converter(dso,NULL)). (e) be retried a number of times by writing a new DSO_METHOD where the "dso_load()" handler will call the converter repeatedly. Then the custom converter could use state information in the DSO to suggest different conversions or paths each time it is invoked.
2000-10-26 17:38:59 +00:00
{DSO_R_DSO_ALREADY_LOADED ,"dso already loaded"},
There's an ongoing project to bring some kind of path selection mechanism to the ENGINE framework. This means there there are going to be new functionality for the DSO part, and ultimately some way of merging two file specifications together. This commit places the merging code into the repository. It's currently not used anywhere, and hasn't been tested at all. It may be full of errors, including syntactical ones. Those will be fixed as promptly as possible.
2002-07-15 15:35:40 +00:00
{DSO_R_EMPTY_FILE_STRUCTURE ,"empty file structure"},
{DSO_R_FAILURE ,"failure"},
A DSO method for VMS was missing, and I had the code lying around...
2000-09-15 21:22:50 +00:00
{DSO_R_FILENAME_TOO_BIG ,"filename too big"},
This is a set of startup code for the DSO support, it's not yet linked into the build process (an upcoming commit no doubt), and is very much *new* code - what that means is that it compiles ok - usually. It certainly doesn't mean it runs well or even properly yet. Please don't muck round with this unless you're looking to help out and hunt bugs. :-) Currently this code doesn't have any support for controlling the "load" behaviour (eg. paths, filename translations, etc). That'll be handled using DSO_ctrl() and various flags, once we work out a sensible set of flags.
2000-04-04 21:57:11 +00:00
{DSO_R_FINISH_FAILED ,"cleanup method function failed"},
There's an ongoing project to bring some kind of path selection mechanism to the ENGINE framework. This means there there are going to be new functionality for the DSO part, and ultimately some way of merging two file specifications together. This commit places the merging code into the repository. It's currently not used anywhere, and hasn't been tested at all. It may be full of errors, including syntactical ones. Those will be fixed as promptly as possible.
2002-07-15 15:35:40 +00:00
{DSO_R_INCORRECT_FILE_SYNTAX ,"incorrect file syntax"},
This is a set of startup code for the DSO support, it's not yet linked into the build process (an upcoming commit no doubt), and is very much *new* code - what that means is that it compiles ok - usually. It certainly doesn't mean it runs well or even properly yet. Please don't muck round with this unless you're looking to help out and hunt bugs. :-) Currently this code doesn't have any support for controlling the "load" behaviour (eg. paths, filename translations, etc). That'll be handled using DSO_ctrl() and various flags, once we work out a sensible set of flags.
2000-04-04 21:57:11 +00:00
{DSO_R_LOAD_FAILED ,"could not load the shared library"},
This changes the behaviour of the DSO mechanism for determining an appropriate filename translation on the host system. Apart from this point, users should also note that there's a slight change in the API functions too. The DSO now contains its own to-be-converted filename ("dso->filename"), and at the time the DSO loads the "dso->loaded_filename" value is set to the translated form. As such, this also provides an impicit way of determining if the DSO is currently loaded or not. Except, perhaps, VMS .... :-) The various DSO_METHODs have been updated for this mechanism except VMS which is deliberately broken for now, Richard is going to look at how to fit it in (the source comments in there explain "the issue"). Basically, the new callback scheme allows the filename conversion to (a) be turned off altogether through the use of the DSO_FLAG_NO_NAME_TRANSLATION flag, (b) be handled in the default way using the default DSO_METHOD's converter (c) overriden per-DSO by setting the override callback (d) a mix of (b) and (c) - eg. implement an override callback that; (i) checks if we're win32 "if(strstr(dso->meth->name, "win32"))..." and if so, convert "blah" into "blah32.dll" (the default is otherwise to make it "blah.dll"). (ii) default to the normal behaviour - eg. we're not on win32, so finish with (return dso->meth->dso_name_converter(dso,NULL)). (e) be retried a number of times by writing a new DSO_METHOD where the "dso_load()" handler will call the converter repeatedly. Then the custom converter could use state information in the DSO to suggest different conversions or paths each time it is invoked.
2000-10-26 17:38:59 +00:00
{DSO_R_NAME_TRANSLATION_FAILED ,"name translation failed"},
{DSO_R_NO_FILENAME ,"no filename"},
Some older code (never committed) wasn't converted to the new format. Corrected.
2002-07-16 08:02:31 +00:00
{DSO_R_NO_FILE_SPECIFICATION ,"no file specification"},
This is a set of startup code for the DSO support, it's not yet linked into the build process (an upcoming commit no doubt), and is very much *new* code - what that means is that it compiles ok - usually. It certainly doesn't mean it runs well or even properly yet. Please don't muck round with this unless you're looking to help out and hunt bugs. :-) Currently this code doesn't have any support for controlling the "load" behaviour (eg. paths, filename translations, etc). That'll be handled using DSO_ctrl() and various flags, once we work out a sensible set of flags.
2000-04-04 21:57:11 +00:00
{DSO_R_NULL_HANDLE ,"a null shared library handle was used"},
This changes the behaviour of the DSO mechanism for determining an appropriate filename translation on the host system. Apart from this point, users should also note that there's a slight change in the API functions too. The DSO now contains its own to-be-converted filename ("dso->filename"), and at the time the DSO loads the "dso->loaded_filename" value is set to the translated form. As such, this also provides an impicit way of determining if the DSO is currently loaded or not. Except, perhaps, VMS .... :-) The various DSO_METHODs have been updated for this mechanism except VMS which is deliberately broken for now, Richard is going to look at how to fit it in (the source comments in there explain "the issue"). Basically, the new callback scheme allows the filename conversion to (a) be turned off altogether through the use of the DSO_FLAG_NO_NAME_TRANSLATION flag, (b) be handled in the default way using the default DSO_METHOD's converter (c) overriden per-DSO by setting the override callback (d) a mix of (b) and (c) - eg. implement an override callback that; (i) checks if we're win32 "if(strstr(dso->meth->name, "win32"))..." and if so, convert "blah" into "blah32.dll" (the default is otherwise to make it "blah.dll"). (ii) default to the normal behaviour - eg. we're not on win32, so finish with (return dso->meth->dso_name_converter(dso,NULL)). (e) be retried a number of times by writing a new DSO_METHOD where the "dso_load()" handler will call the converter repeatedly. Then the custom converter could use state information in the DSO to suggest different conversions or paths each time it is invoked.
2000-10-26 17:38:59 +00:00
{DSO_R_SET_FILENAME_FAILED ,"set filename failed"},
This is a set of startup code for the DSO support, it's not yet linked into the build process (an upcoming commit no doubt), and is very much *new* code - what that means is that it compiles ok - usually. It certainly doesn't mean it runs well or even properly yet. Please don't muck round with this unless you're looking to help out and hunt bugs. :-) Currently this code doesn't have any support for controlling the "load" behaviour (eg. paths, filename translations, etc). That'll be handled using DSO_ctrl() and various flags, once we work out a sensible set of flags.
2000-04-04 21:57:11 +00:00
{DSO_R_STACK_ERROR ,"the meth_data stack is corrupt"},
{DSO_R_SYM_FAILURE ,"could not bind to the requested symbol name"},
{DSO_R_UNLOAD_FAILED ,"could not unload the shared library"},
{DSO_R_UNSUPPORTED ,"functionality not supported"},
{0,NULL}
};
#endif
void ERR_load_DSO_strings(void)
{
static int init=1;
if (init)
{
init=0;
Make all configuration macros available for application by making sure they are available in opensslconf.h, by giving them names starting with "OPENSSL_" to avoid conflicts with other packages and by making sure e_os2.h will cover all platform-specific cases together with opensslconf.h. I've checked fairly well that nothing breaks with this (apart from external software that will adapt if they have used something like NO_KRB5), but I can't guarantee it completely, so a review of this change would be a good thing.
2001-02-19 16:06:34 +00:00
#ifndef OPENSSL_NO_ERR
This is a set of startup code for the DSO support, it's not yet linked into the build process (an upcoming commit no doubt), and is very much *new* code - what that means is that it compiles ok - usually. It certainly doesn't mean it runs well or even properly yet. Please don't muck round with this unless you're looking to help out and hunt bugs. :-) Currently this code doesn't have any support for controlling the "load" behaviour (eg. paths, filename translations, etc). That'll be handled using DSO_ctrl() and various flags, once we work out a sensible set of flags.
2000-04-04 21:57:11 +00:00
ERR_load_strings(ERR_LIB_DSO,DSO_str_functs);
ERR_load_strings(ERR_LIB_DSO,DSO_str_reasons);
#endif
}
}
Reference in a new issue Copy permalink