diff options
author | Yang Tse <yangsita@gmail.com> | 2013-01-03 03:53:06 +0100 |
---|---|---|
committer | Yang Tse <yangsita@gmail.com> | 2013-01-03 05:50:26 +0100 |
commit | 13606bbfdeaa3bac193e1f39a05a9c9b5f15d1b5 (patch) | |
tree | 2213bc5bee29121d23b34de0346ee1324295c379 /docs/INTERNALS | |
parent | 8f0171bdd498f5febfb9bc93c234c30287227e74 (diff) |
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.
Diffstat (limited to 'docs/INTERNALS')
-rw-r--r-- | docs/INTERNALS | 107 |
1 files changed, 54 insertions, 53 deletions
diff --git a/docs/INTERNALS b/docs/INTERNALS index acd05e219..1868a18c4 100644 --- a/docs/INTERNALS +++ b/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 |