Hi Daniel, Gisle, and all,

The renaming of lib/*.h which already were not named curl_*.h to
curl_*.h, and renaming lib/*.c which already were not named curl_*.c
has at least the following intended benefits over the non-renamed
sources:

Relative to the header files...

1) We are able to guarantee to a higher degree that the headers being
included are actually libcurl ones.
2) Specifically, renaming setup.h and setup_once.h to curl_setup.h and
curl_setup_once.h was needed to break bidirectional interdependency on
c-ares files when building with c-ares in-tree. This change alone
modified same big number of files.
3) Points above are in preparation of at-some-future point splitting
of curl_setup_once.h into two headers, one that is required to be
included in libcurl's sources before other libcurl headers and another
one that has to be included nearly last although not for the same
reasons an curl_memdebug.h
4) When human reading libcurl's code it is much easier to know if a
header is a libcurl header or not.
5) Script testing of conditions relative to positioning or presence of
libcurl's headers in source files will become less error prone.
6) When referencing the name of a libcurl header file either on the
mailing list or wherever it becomes obvious that it is a libcurl one.

Relative to the source files...

1) Point 6 of above applies equally to source files.
2) When debugging libcurl or apps that use it with debuggers that are
capable of showing the name of the source file it is much easier to
know if one is stepping in libcurl's code or elsewhere.
3) On core dumps, and fatal happenings which trace the source file
name of where the problem has been triggered, it becomes much easier
for not expert souls to figure out if it is a libcurl problem or not.
4) Also makes naming of *.c files equal to respective *.h one.

I know that those not affected by any of the benefits mentioned above
will only see this as a 'cosmetic change', but it isn't.

@Gisle

From your message http://curl.haxx.se/mail/lib-2013-01/0012.html I'm
unable to fully understand if Metaware+Pharlap-DOS-extender was
capable of working before this commit, or if support for it was
already broken.

-- 
-=[Yang]=-
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html