aboutsummaryrefslogtreecommitdiffstats
path: root/crypto/dso/dso_lib.c
Commit message (Collapse)AuthorAgeFilesLines
* Fix two possible leaksFdaSilvaYY2016-02-271-0/+1
| | | | | | | Backport of 98637bd Reviewed-by: Kurt Roeckx <kurt@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org>
* Remove the "eay" c-file-style indicatorsRichard Levitte2015-12-181-1/+1
| | | | | | | Since we don't use the eay style any more, there's no point tryint to tell emacs to use it. Reviewed-by: Ben Laurie <ben@openssl.org>
* Code style: space after 'if'Viktor Dukhovni2015-04-161-1/+1
| | | | Reviewed-by: Matt Caswell <gitlab@openssl.org>
* Run util/openssl-format-source -v -c .Matt Caswell2015-01-221-377/+341
| | | | Reviewed-by: Tim Hudson <tjh@openssl.org>
* Remove dead code. (Coverity ID 2)Ben Laurie2008-12-271-7/+0
|
* More type-checking.Ben Laurie2008-06-041-2/+2
|
* Some error code cleanups (SSL lib. used SSL_R_... codes reserved for alerts)Bodo Möller2006-01-081-2/+2
|
* "Relax" prototype and rename DSO_global_lookup_func to DSO_global_lookup.Andy Polyakov2006-01-021-9/+1
|
* Oops! Remove junk...Andy Polyakov2005-12-311-1/+0
|
* Add DSO_global_lookup_func implementation. See commentary in dso_lib.cAndy Polyakov2005-12-301-0/+21
| | | | for further details.
* When the return type of the function is int, it's better to return anRichard Levitte2005-06-091-1/+1
| | | | | in than NULL, especially when an error is signalled with a negative value.
* New function, DSO_pathbyaddr, to find pathname for loaded shared objectAndy Polyakov2005-06-051-0/+12
| | | | | by an address within it. Tested on Linux, Solaris, IRIX, Tru64, Darwin, HP-UX, Win32, few BSD flavors...
* Use BUF_strlcpy() instead of strcpy().Richard Levitte2003-12-271-2/+2
| | | | | | | Use BUF_strlcat() instead of strcat(). Use BIO_snprintf() instead of sprintf(). In some cases, keep better track of buffer lengths. This is part of a large change submitted by Markus Friedl <markus@openbsd.org>
* Some older code (never committed) wasn't converted to the new format.Richard Levitte2002-07-161-2/+2
| | | | Corrected.
* There's an ongoing project to bring some kind of path selectionRichard Levitte2002-07-151-1/+28
| | | | | | | | | | | 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.
* 'flags' should only be set inside DSO_load() if constructing a new DSOGeoff Thorpe2001-11-221-7/+6
| | | | | object - otherwise we overwrite any flags that had been previously set in the DSO before calling DSO_load().
* Add a "_up" -> "_up_ref" change to libeay.num that was missing from theGeoff Thorpe2001-09-041-2/+2
| | | | recent changes. Also, do the same change to the DSO_up() function.
* avoid memory leakBodo Möller2000-11-031-1/+1
|
* DSO_load() should also work when it is passed a NULL - a new DSO is createdGeoff Thorpe2000-10-301-3/+3
| | | | | | automatically, however some code was still referring to the original pointer rather than the internal one (and thus to NULL instead of the created pointer).
* This changes the behaviour of the DSO mechanism for determining anGeoff Thorpe2000-10-261-16/+134
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Time to get rid of some rather silly code duplication - some DSO_ctrl()Geoff Thorpe2000-10-081-0/+16
| | | | commands are common to all DSO_METHODs, hence handle them at the top.
* Use sk_*_new_null() instead of sk_*_new(NULL), since that takes careRichard Levitte2000-09-171-2/+2
| | | | | of complaints from the compiler about data pointers and function pointers not being compatible with each other.
* Currently the DSO_METHOD interface has one entry point to bind allGeoff Thorpe2000-06-161-6/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | "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).
* There have been a number of complaints from a number of sources that namesRichard Levitte2000-06-011-4/+4
| | | | | | | | | like Malloc, Realloc and especially Free conflict with already existing names on some operating systems or other packages. That is reason enough to change the names of the OpenSSL memory allocation macros to something that has a better chance of being unique, like prepending them with OPENSSL_. This change includes all the name changes needed throughout all C files.
* This change facilitates name translation for shared libraries. TheGeoff Thorpe2000-04-191-1/+33
| | | | | | | | | | | | | technique used is far from perfect and alternatives are welcome. Basically if the translation flag is set, the string is not too long, and there appears to be no path information in the string, then it is converted to whatever the standard should be for the DSO_METHOD in question, eg; blah --> libblah.so on *nix, and blah --> blah.dll on win32. This change also introduces the DSO_ctrl() function that is used by the name translation stuff.
* Constification, and a silly mistake in the comments.Geoff Thorpe2000-04-061-2/+2
|
* This is a set of startup code for the DSO support, it's not yet linked intoGeoff Thorpe2000-04-041-0/+251
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.
generated by cgit v1.2.3 (git 2.39.1) at 2024-07-15 05:03:25 +0000