cURL / Mailing Lists / curl-library / Single Mail


Obsolete error codes

From: Dan Fandrich <>
Date: Mon, 27 Aug 2007 13:52:35 -0700

The libcurl API now defines 81 different error codes from the curl_easy_*
series of functions. That's a lot of error codes! It turns out that
there are many duplicate and unused error codes in the bunch. Most
of the duplicates are there because the original codes had a specific
protocol in the name and a similar error needed to be returned by a
new protocol. For example, the error codes


all mean the same thing--that a remote resource was not found. Since there
is never a need to distinguish between them (only one of the codes could
possibly be returned for any handle handle, depending on the URL),
they should all be replaced by a single code. But that's undesirable
for backward compatibility reasons.

I propose changing the codes in two steps. The first step could be done
right now and will preserve 100% backward compatibility (essentially).
That would consist of renaming some errors to take the protocols out of the
names and make them suitable for more general use. Macros to define
the old names in terms of the new ones would be added to preserve
compatibility, but they would be added in a CURL_NO_OLDIES section
so people can easily see if their programs are relying on the old names and
fix them. Some time in the future (or maybe never) the old names would
go away. Unused error codes would be removed as well at this stage
(without leaving a "hole" in the error code list, of course).

At the next SONAME bump, when compatibility guarantees are no longer valid,
the libcurl code would be changed to remove references to the duplicate
errors and replace them with the generic error codes. This is a minor
compatibility burp, and many programs would still continue to operate just
fine expecting the old error codes even if they weren't recompiled (which
they are forced to do by the SONAME change, except when distros (like
Debian) just symlink the old name to the new).

These are the codes I would want to see renamed immediately:


These are the codes I would like to see removed, as they are unused. Removal
would consist of replacing the code with a name like CURLE_OBSOLETE50 and
creating macros with these old names to the new ones. (A few of these
look like they ought to be supported in the code--maybe they were removed


At the next SONAME bump, I'd like to see the following options combined,
i.e. references to the first name replaced by the second.


Similarly, there are a few curl_easy_setopt options I'd like to see renamed
for similar reasons. This could be done now, with backward-compatible names


* These last two options aren't currently used by protocols other than
FTP, but it's conceivable that they could be in the future.

What is the consensus of the list on this proposal?

>>> Dan

--              The web change of address service
          Let webmasters know that your web site has moved
Received on 2007-08-28