also, EINVAL doesn't seem like a great error code for this
condition. it's not an input parameter that's causing the
error, but rather that the required output format cannot express
the data to be returned. I think solaris uses EOVERFLOW for
this kind of situation, and ERANGE doesn't seem
In article 20121210195346.ga8...@apb-laptoy.apb.alt.za,
Alan Barrett a...@cequrux.com wrote:
also, EINVAL doesn't seem like a great error code for this
condition. it's not an input parameter that's causing the
error, but rather that the required output format cannot express
the data to be
On Mon, Dec 10, 2012 at 09:53:46PM +0200, Alan Barrett wrote:
also, EINVAL doesn't seem like a great error code for this
condition. it's not an input parameter that's causing the
error, but rather that the required output format cannot express
the data to be returned. I think solaris uses
On Mon, Dec 10, 2012 at 09:23:15PM +, David Laight wrote:
Then people get upset because they say function foo() isn't allowed
to set errno to 'bar'.
It is rather a shame that posix tries to list all errno a function
can return, not just those for explicit 'likely' (ie normal)
Then people get upset because they say function foo() isn't allowed
to set errno to 'bar'.
Then how do you sanely write error handling routines? The error
returns form part of the interface and should be documented as such.
There are two kinds of error returns.
There are error returns which
