qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Ian Jackson
Subject: Re: [Qemu-devel] [6324] Return -errno on write failure (Gleb Natapov)
Date: Mon, 19 Jan 2009 11:37:57 +0000

François Revol writes ("Re: [Qemu-devel] [6324] Return -errno on write failure 
(Gleb Natapov)"):
> [Ian Jackson:]
> > 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.

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

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).

> 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.

But returning -errno to indicate an error is a very convenient
practice.  It is deservedly widely used, not just in qemu.  To do
things another way would make much of the code much more verbose.

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 ?

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.



The rest of your article is full of pointless railing against
standards, but lest I be accused of not having answers:

> 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'.

> 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.

> 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 ?

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

> 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.

> 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.

>  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.

Ian.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]