Re: [Qemu-devel] [6324] Return -errno on write failure (Gleb Natapov)

[François Revol]

> > > So BeOS is not ANSI C !
> >
> > And so, well, what ?
>
> You were complaining, in your original message, that the POSIX people
> had changed their specification.  However POSIX has always been
> supposed to follow C89 and later C99 on this subject.  C89 has always
> said that errno values are positive.

It doesn't change the fact they did change their text at one point.

> Before C89 there was no detailed standard for C at all; errno was
> defined by the context of its invention - ie, Unix.

Unix was just taken as a defacto standard and standardized into it.
But why would it be better than others ? (appart author relationship
with C itself)

> It seems amazing that an operating system written in the 1990s can
> manage to be non-complaint on such a basic point.  It's not like C89
> is some kind of weird Unix-specific thing.  It was written to
> encompass all of MS-DOS, Apple and IBM mainframes (as well as Unix of
> course).

BeOS is not so new, and C89 was probably not widespread at the time,
just see how long it got to gcc to conform...
http://en.wikipedia.org/wiki/BeOS

There is also the fact that at least theorically one has to pay for it,
unlike RFCs. It's interesting to see free software people insisting on
Microsoft or others for free of charge specs on protocols yet abide by
paid standards.

> > It won't change any time soon.
>
> Maybe users of such badly defective operating systems should live
> with
> the costs of the bug.  If it were just a single place to make a
> workaround, there would be no argument; qemu has many such
> workarounds.  But the current proposal is to change lots of code
> throughout qemu.

There I don't want to even try to argue anymore.
non-conformant != defective.

I could also say C89 is defective in its design by not taking the
cleanest approach, since having EDOM < 0 in the first place removes a
lot of potential bugs by not forgetting the - everywhere.

BeOS has been created this way. Saying it's defective is both wrong and
insulting.
I don't feel like answering the rest either...

> But returning -errno to indicate an error is a very convenient
> practice.  It is deservedly widely used, not just in qemu.  To do

I'm still wondering why this convenient way of doing has not been used
for decades outside Unix kernels themselves until recently...

> things another way would make much of the code much more verbose.

It might look convenient but exposes to missing - everywhere too...

> Why should the rest of the world have to bear that cost - in the form
> of increased effort in maintenance, increased bug rates,
> incompatibility of patches made against different versions of qemu,
> and so on ?

I'd say calling a macro of whatever could also make it more obvious and
could bring more attention to a potential source of bug.

> Instead, developers using BeOS should probably provide some kind of
> compatibility shim so that correct programs can work properly.
> Failing that you should maintaining the intrusive patch yourselves
> rather than imposing it on the rest of us.

BeOS probably not, it's closed source.
As for Haiku, well, feel free to send a patch but I don't see how one
can come up with a sensible way of doing it considering those are used
everywhere.

And I still think it's the cleanest way, regardless standards.

We are not alone doing that, there is Minix also, though they OTOH
change the signness of theirs depending on the context (kernel vs
user), which IMO is quite ugly and error prone. At least they conform
to ANSI C at user level... but not kernel.

> > Besides, there is no reason a language stantard should dictate such
> > a
> > runtime thing...
>
> errno is defined in C89 and C99 along with the rest of the C standard
> library.  So if have an excessively narrow view of what a `language
> standard' is then ANSI C is a `language and library standard'.

Either way, after seeing how the drafts I found talks about it I don't
see why I would comply to it, it's like "oh EDOM is positive, but errno
is assigned a non zero value on error, oh but it must be assigned to
EDOM in that case, which is non-zero, but oh, errno should or must or
I'm not sure what I'm writing anymore but possibly it's positive".
I do hope the final one is fixed.

At least depending how you read it sometimes you might think despite
EDOM and ERANGE should be >0 it doesn't mean errno would always be >0.

And again, in POSIX, there is a single place where the signedness is
explained, and this place has been "fixed" to comply with C99 at some
point.

Not counting all the "implementation defined" cases where we would
really like to know what to do.

> > And for what I've seen from it, it's not consistent with itself,
> > saying
> > non-zero on a line, positive on the next one.
>
> It says `non-zero' for emphasis, to ensure that the reader will
> interpret it as strictly positive rather than just non-negative.  You
> will note of course that positive numbers are positive and also
> non-zero, so there is no contradiction.  Negative numbers are non-
> zero
> but not positive so not permitted.

One could also just say "positive and non-zero" or "strictly positive".
In any case it brings contradiction by trying to wave another
contradiction.

> > Btw, was it available freely at the time ? I mean don't expect
> > people
> > to comply with something you have to pay for. That's what you get.
> > (hint, POSIX drafts)
>
> Are you telling me that Be Inc couldn't afford a copy of the
> specification for the C programming language while they were writing
> their operating system ?

I did not work at Be, mail them via IPOT if you will...

> If BeOS had been a Free operating system then someone would probably
> have pointed this error out to them sooner.

The headers were available in the SDK download for free for a decade.

> > It's not like any other OS I've seen doesn't violate some standard.
>
> The workarounds for other don't aren't intrusive and incompatible-
> across-versions internal API changes in the form of textually large
> patches.

As I said it's not intrusive, it's just fastidious to do once.
And it does not change any API or ABI on other OSes.

A function that returned -EINVAL in linux before would still return -
EINVAL.
It is transparent to other OSes, and just ensures correct signedness/
non overflow on BeOS and Haiku.

> > Still, everything has been fine for a decade and suddenly people
> > start
> > doing this kind of tricks out of the blue.
>
> Nonsense.  People have been passing -errno in application code for
> decades.  Evidently not in code you've previously encountered.

And I did encounter lot of code... maybe not enough.

> >  It's not like considering errno can be !=0 is orthogonal to the
> > standard, so supporting BeOS itself would't make the code itself
> > violate ANSI C.
>
> But it would make the code longer and more clumsy and more
> complicated.  That increases the expected number of bugs.

It's also possible to define QEINVAL and friends as [-]EINVAL.
There,
return -EINVAL;
becomes
return QEINVAL;

No single byte more when returning constants, it just doesn't work for
errno itself...
It does remove the possibility of missing the - OTH.

It's what OSS did.
Not my prefered but it works as well.

François.