www.libssh2.org | Daily snapshots | Mailing list archive | Docs | Examples | github

Archive Index This month's Index

Subject: Re: breaking the ABI (was Re: 'watch' libssh2 on github)

Re: breaking the ABI (was Re: 'watch' libssh2 on github)

From: Will Cosgrove <will_at_panic.com>
Date: Thu, 12 Mar 2015 16:31:02 -0700

> On Thu, 12 Mar 2015, Will Cosgrove wrote:
>> In kmdhgGPsha1kex_state_t, I changed the following:
> Ok, but I don't see how any of those changes cause any breaking change. They're internal and hidden from users so unless I'm missing something they're totally fine and benign.
>> As for the known_hosts error values, in the future I would strongly encourage the use of unique error codes going forward. Writing end-user applications rely on unique error codes to generate meaningful user error strings to present to the user.
> But they're different error codes, they're not in a single number range.

They are in a single range across the project, look at _FX_ and _KNOWNHOST_ errors. For example:


These types of collisions are not great, IMHO.

> I will agree though that it is generally more convenient for everyone to keep the error codes in the same range even for different functions.

> However, I don't think exposing our return codes will be helpful to very many users...

We’re not literally showing these codes to end-users, we are translating them to user friendly error strings. For a concrete example, we have a function like errorMessageFromCode(int code), the _code_ is the code coming from any o’l libssh function call. As you might guess, inside that function is a switch statement on the various Libssh error values. Switch statements need unique values, thus the original pull request. There is value in having unique codes, much more so than having them in the same range across files.


libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel
Received on 2015-03-13

the libssh2 team