build: make use of 93 lib/*.c renamed files
93 *.c source files renamed to use our standard naming scheme. This change affects 77 files in libcurl's source tree.
This commit is contained in:
Yang Tse
107
docs/INTERNALS
107
docs/INTERNALS
@@ -117,15 +117,15 @@ Library
|
||||
There are plenty of entry points to the library, namely each publicly defined
|
||||
function that libcurl offers to applications. All of those functions are
|
||||
rather small and easy-to-follow. All the ones prefixed with 'curl_easy' are
|
||||
put in the lib/easy.c file.
|
||||
put in the lib/curl_easy.c file.
|
||||
|
||||
curl_global_init_() and curl_global_cleanup() should be called by the
|
||||
application to initialize and clean up global stuff in the library. As of
|
||||
today, it can handle the global SSL initing if SSL is enabled and it can init
|
||||
the socket layer on windows machines. libcurl itself has no "global" scope.
|
||||
|
||||
All printf()-style functions use the supplied clones in lib/mprintf.c. This
|
||||
makes sure we stay absolutely platform independent.
|
||||
All printf()-style functions use the supplied clones in lib/curl_mprintf.c.
|
||||
This makes sure we stay absolutely platform independent.
|
||||
|
||||
curl_easy_init() allocates an internal struct and makes some initializations.
|
||||
The returned handle does not reveal internals. This is the 'SessionHandle'
|
||||
@@ -140,17 +140,17 @@ Library
|
||||
|
||||
curl_easy_perform() does a whole lot of things:
|
||||
|
||||
It starts off in the lib/easy.c file by calling Curl_perform() and the main
|
||||
work then continues in lib/url.c. The flow continues with a call to
|
||||
It starts off in the lib/curl_easy.c file by calling Curl_perform() and the
|
||||
main work then continues in lib/curl_url.c. The flow continues with a call to
|
||||
Curl_connect() to connect to the remote site.
|
||||
|
||||
o Curl_connect()
|
||||
|
||||
... analyzes the URL, it separates the different components and connects to
|
||||
the remote host. This may involve using a proxy and/or using SSL. The
|
||||
Curl_resolv() function in lib/hostip.c is used for looking up host names
|
||||
(it does then use the proper underlying method, which may vary between
|
||||
platforms and builds).
|
||||
Curl_resolv() function in lib/curl_hostip.c is used for looking up host
|
||||
names (it does then use the proper underlying method, which may vary
|
||||
between platforms and builds).
|
||||
|
||||
When Curl_connect is done, we are connected to the remote site. Then it is
|
||||
time to tell the server to get a document/file. Curl_do() arranges this.
|
||||
@@ -165,15 +165,15 @@ Library
|
||||
Curl_do() makes sure the proper protocol-specific function is called. The
|
||||
functions are named after the protocols they handle. Curl_ftp(),
|
||||
Curl_http(), Curl_dict(), etc. They all reside in their respective files
|
||||
(ftp.c, http.c and dict.c). HTTPS is handled by Curl_http() and FTPS by
|
||||
Curl_ftp().
|
||||
(curl_ftp.c, curl_http.c and curl_dict.c). HTTPS is handled by Curl_http()
|
||||
and FTPS by Curl_ftp().
|
||||
|
||||
The protocol-specific functions of course deal with protocol-specific
|
||||
negotiations and setup. They have access to the Curl_sendf() (from
|
||||
lib/sendf.c) function to send printf-style formatted data to the remote
|
||||
host and when they're ready to make the actual file transfer they call the
|
||||
Curl_Transfer() function (in lib/transfer.c) to setup the transfer and
|
||||
returns.
|
||||
lib/curl_sendf.c) function to send printf-style formatted data to the
|
||||
remote host and when they're ready to make the actual file transfer they
|
||||
call the Curl_Transfer() function (in lib/curl_transfer.c) to setup the
|
||||
transfer and returns.
|
||||
|
||||
If this DO function fails and the connection is being re-used, libcurl will
|
||||
then close this connection, setup a new connection and re-issue the DO
|
||||
@@ -187,13 +187,13 @@ Library
|
||||
|
||||
o Transfer()
|
||||
|
||||
Curl_perform() then calls Transfer() in lib/transfer.c that performs the
|
||||
entire file transfer.
|
||||
Curl_perform() then calls Transfer() in lib/curl_transfer.c that performs
|
||||
the entire file transfer.
|
||||
|
||||
During transfer, the progress functions in lib/progress.c are called at a
|
||||
frequent interval (or at the user's choice, a specified callback might get
|
||||
called). The speedcheck functions in lib/speedcheck.c are also used to
|
||||
verify that the transfer is as fast as required.
|
||||
During transfer, the progress functions in lib/curl_progress.c are called
|
||||
at a frequent interval (or at the user's choice, a specified callback
|
||||
might get called). The speedcheck functions in lib/curl_speedcheck.c are
|
||||
also used to verify that the transfer is as fast as required.
|
||||
|
||||
o Curl_done()
|
||||
|
||||
@@ -241,11 +241,11 @@ Library
|
||||
HTTP(S)
|
||||
|
||||
HTTP offers a lot and is the protocol in curl that uses the most lines of
|
||||
code. There is a special file (lib/formdata.c) that offers all the multipart
|
||||
post functions.
|
||||
code. There is a special file (lib/curl_formdata.c) that offers all the
|
||||
multipart post functions.
|
||||
|
||||
base64-functions for user+password stuff (and more) is in (lib/base64.c) and
|
||||
all functions for parsing and sending cookies are found in (lib/cookie.c).
|
||||
base64-functions for user+password stuff (and more) is in (lib/curl_base64.c)
|
||||
and all functions for parsing and sending cookies in (lib/curl_cookie.c).
|
||||
|
||||
HTTPS uses in almost every means the same procedure as HTTP, with only two
|
||||
exceptions: the connect procedure is different and the function used to read
|
||||
@@ -253,8 +253,8 @@ Library
|
||||
the source by the use of Curl_read() for reading and Curl_write() for writing
|
||||
data to the remote server.
|
||||
|
||||
http_chunks.c contains functions that understands HTTP 1.1 chunked transfer
|
||||
encoding.
|
||||
curl_http_chunks.c contains functions that understands HTTP 1.1 chunked
|
||||
transfer encoding.
|
||||
|
||||
An interesting detail with the HTTP(S) request, is the Curl_add_buffer()
|
||||
series of functions we use. They append data to one single buffer, and when
|
||||
@@ -264,7 +264,7 @@ Library
|
||||
FTP
|
||||
|
||||
The Curl_if2ip() function can be used for getting the IP number of a
|
||||
specified network interface, and it resides in lib/if2ip.c.
|
||||
specified network interface, and it resides in lib/curl_if2ip.c.
|
||||
|
||||
Curl_ftpsendf() is used for sending FTP commands to the remote server. It was
|
||||
made a separate function to prevent us programmers from forgetting that they
|
||||
@@ -273,41 +273,42 @@ Library
|
||||
|
||||
Kerberos
|
||||
|
||||
The kerberos support is mainly in lib/krb4.c and lib/security.c.
|
||||
The kerberos support is mainly in lib/curl_krb4.c and lib/curl_security.c.
|
||||
|
||||
TELNET
|
||||
|
||||
Telnet is implemented in lib/telnet.c.
|
||||
Telnet is implemented in lib/curl_telnet.c.
|
||||
|
||||
FILE
|
||||
|
||||
The file:// protocol is dealt with in lib/file.c.
|
||||
The file:// protocol is dealt with in lib/curl_file.c.
|
||||
|
||||
LDAP
|
||||
|
||||
Everything LDAP is in lib/ldap.c and lib/openldap.c
|
||||
Everything LDAP is in lib/curl_ldap.c and lib/curl_openldap.c
|
||||
|
||||
GENERAL
|
||||
|
||||
URL encoding and decoding, called escaping and unescaping in the source code,
|
||||
is found in lib/escape.c.
|
||||
is found in lib/curl_escape.c.
|
||||
|
||||
While transferring data in Transfer() a few functions might get used.
|
||||
curl_getdate() in lib/parsedate.c is for HTTP date comparisons (and more).
|
||||
curl_getdate() in lib/curl_parsedate.c is for HTTP date comparisons (and
|
||||
more).
|
||||
|
||||
lib/getenv.c offers curl_getenv() which is for reading environment variables
|
||||
in a neat platform independent way. That's used in the client, but also in
|
||||
lib/url.c when checking the proxy environment variables. Note that contrary
|
||||
to the normal unix getenv(), this returns an allocated buffer that must be
|
||||
free()ed after use.
|
||||
lib/curl_getenv.c offers curl_getenv() which is for reading environment
|
||||
variables in a neat platform independent way. That's used in the client,
|
||||
but also in lib/curl_url.c when checking the proxy environment variables.
|
||||
Note that contrary to the normal unix getenv(), this returns an allocated
|
||||
buffer that must be free()ed after use.
|
||||
|
||||
lib/netrc.c holds the .netrc parser
|
||||
lib/curl_netrc.c holds the .netrc parser
|
||||
|
||||
lib/timeval.c features replacement functions for systems that don't have
|
||||
lib/curl_timeval.c features replacement functions for systems that don't have
|
||||
gettimeofday() and a few support functions for timeval conversions.
|
||||
|
||||
A function named curl_version() that returns the full curl version string is
|
||||
found in lib/version.c.
|
||||
found in lib/curl_version.c.
|
||||
|
||||
Persistent Connections
|
||||
======================
|
||||
@@ -411,10 +412,10 @@ API/ABI
|
||||
Client
|
||||
======
|
||||
|
||||
main() resides in src/main.c together with most of the client code.
|
||||
main() resides in src/tool_main.c together with most of the client code.
|
||||
|
||||
src/tool_hugehelp.c is automatically generated by the mkhelp.pl perl script
|
||||
to display the complete "manual" and the src/urlglob.c file holds the
|
||||
to display the complete "manual" and the src/tool_urlglob.c file holds the
|
||||
functions used for the URL-"globbing" support. Globbing in the sense that
|
||||
the {} and [] expansion stuff is there.
|
||||
|
||||
@@ -423,10 +424,10 @@ Client
|
||||
control after the curl_easy_perform() it cleans up the library, checks status
|
||||
and exits.
|
||||
|
||||
When the operation is done, the ourWriteOut() function in src/writeout.c may
|
||||
be called to report about the operation. That function is using the
|
||||
curl_easy_getinfo() function to extract useful information from the curl
|
||||
session.
|
||||
When the operation is done, the ourWriteOut() function in
|
||||
src/tool_writeout.c may be called to report about the operation. That
|
||||
function is using the curl_easy_getinfo() function to extract useful
|
||||
information from the curl session.
|
||||
|
||||
Recent versions may loop and do all this several times if many URLs were
|
||||
specified on the command line or config file.
|
||||
@@ -434,12 +435,12 @@ Client
|
||||
Memory Debugging
|
||||
================
|
||||
|
||||
The file lib/memdebug.c contains debug-versions of a few functions. Functions
|
||||
such as malloc, free, fopen, fclose, etc that somehow deal with resources
|
||||
that might give us problems if we "leak" them. The functions in the memdebug
|
||||
system do nothing fancy, they do their normal function and then log
|
||||
information about what they just did. The logged data can then be analyzed
|
||||
after a complete session,
|
||||
The file lib/curl_memdebug.c contains debug-versions of a few functions.
|
||||
Functions such as malloc, free, fopen, fclose, etc that somehow deal with
|
||||
resources that might give us problems if we "leak" them. The functions in
|
||||
the memory tracking system do nothing fancy, they do their normal function
|
||||
and then log information about what they just did. The logged data can then
|
||||
be analyzed after a complete session,
|
||||
|
||||
memanalyze.pl is the perl script present in tests/ that analyzes a log file
|
||||
generated by the memory tracking system. It detects if resources are
|
||||
|
||||
@@ -541,8 +541,8 @@ to provide the data to send.
|
||||
|
||||
19.1 http-style HEAD output for ftp
|
||||
|
||||
#undef CURL_FTP_HTTPSTYLE_HEAD in lib/ftp.c to remove the HTTP-style headers
|
||||
from being output in NOBODY requests over ftp
|
||||
#undef CURL_FTP_HTTPSTYLE_HEAD in lib/curl_ftp.c to remove the HTTP-style
|
||||
headers from being output in NOBODY requests over ftp
|
||||
|
||||
19.2 combine error codes
|
||||
|
||||
|
||||
Reference in New Issue
Block a user