70f1db321a
So far, all of the SSL backends' private data has been declared as part of the ssl_connect_data struct, in one big #if .. #elif .. #endif block. This can only work as long as the SSL backend is a compile-time option, something we want to change in the next commits. Therefore, let's encapsulate the exact data needed by each SSL backend into a private struct, and let's avoid bleeding any SSL backend-specific information into urldata.h. This is also necessary to allow multiple SSL backends to be compiled in at the same time, as e.g. OpenSSL's and CyaSSL's headers cannot be included in the same .c file. To avoid too many malloc() calls, we simply append the private structs to the connectdata struct in allocate_conn(). This requires us to take extra care of alignment issues: struct fields often need to be aligned on certain boundaries e.g. 32-bit values need to be stored at addresses that divide evenly by 4 (= 32 bit / 8 bit-per-byte). We do that by assuming that no SSL backend's private data contains any fields that need to be aligned on boundaries larger than `long long` (typically 64-bit) would need. Under this assumption, we simply add a dummy field of type `long long` to the `struct connectdata` struct. This field will never be accessed but acts as a placeholder for the four instances of ssl_backend_data instead. the size of each ssl_backend_data struct is stored in the SSL backend-specific metadata, to allow allocate_conn() to know how much extra space to allocate, and how to initialize the ssl[sockindex]->backend and proxy_ssl[sockindex]->backend pointers. This would appear to be a little complicated at first, but is really necessary to encapsulate the private data of each SSL backend correctly. And we need to encapsulate thusly if we ever want to allow selecting CyaSSL and OpenSSL at runtime, as their headers cannot be included within the same .c file (there are just too many conflicting definitions and declarations for that). Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> |
||
|---|---|---|
| .github | ||
| CMake | ||
| docs | ||
| include | ||
| lib | ||
| m4 | ||
| packages | ||
| projects | ||
| scripts | ||
| src | ||
| tests | ||
| winbuild | ||
| .dir-locals.el | ||
| .gitattributes | ||
| .gitignore | ||
| .mailmap | ||
| .travis.yml | ||
| CHANGES | ||
| CMakeLists.txt | ||
| COPYING | ||
| GIT-INFO | ||
| MacOSX-Framework | ||
| Makefile.am | ||
| Makefile.dist | ||
| README | ||
| README.md | ||
| RELEASE-NOTES | ||
| acinclude.m4 | ||
| appveyor.yml | ||
| buildconf | ||
| buildconf.bat | ||
| configure.ac | ||
| curl-config.in | ||
| libcurl.pc.in | ||
| maketgz | ||
README.md
Curl is a command-line tool for transferring data specified with URL syntax. Find out how to use curl by reading the curl.1 man page or the MANUAL document. Find out how to install Curl by reading the INSTALL document.
libcurl is the library curl is using to do its job. It is readily available to be used by your software. Read the libcurl.3 man page to learn how!
You find answers to the most frequent questions we get in the FAQ document.
Study the COPYING file for distribution terms and similar. If you distribute curl binaries or other binaries that involve libcurl, you might enjoy the LICENSE-MIXING document.
Contact
If you have problems, questions, ideas or suggestions, please contact us by posting to a suitable mailing list.
All contributors to the project are listed in the THANKS document.
Website
Visit the curl web site for the latest news and downloads.
Git
To download the very latest source off the Git server do this:
git clone https://github.com/curl/curl.git
(you'll get a directory named curl created, filled with the source code)
Notice
Curl contains pieces of source code that is Copyright (c) 1998, 1999 Kungliga Tekniska Högskolan. This notice is included here to comply with the distribution terms.