From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LOzDr-0003BW-O1 for qemu-devel@nongnu.org; Mon, 19 Jan 2009 13:51:43 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LOzDq-00038X-9s for qemu-devel@nongnu.org; Mon, 19 Jan 2009 13:51:42 -0500 Received: from [199.232.76.173] (port=37410 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LOzDq-00038F-37 for qemu-devel@nongnu.org; Mon, 19 Jan 2009 13:51:42 -0500 Received: from smtp6-g21.free.fr ([212.27.42.6]:33350) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LOzDp-0002rD-03 for qemu-devel@nongnu.org; Mon, 19 Jan 2009 13:51:41 -0500 Received: from smtp6-g21.free.fr (localhost [127.0.0.1]) by smtp6-g21.free.fr (Postfix) with ESMTP id 9D372E0814E for ; Mon, 19 Jan 2009 19:51:37 +0100 (CET) Received: from laptop (vaf26-2-82-244-111-82.fbx.proxad.net [82.244.111.82]) by smtp6-g21.free.fr (Postfix) with ESMTP id A3691E081AE for ; Mon, 19 Jan 2009 19:51:34 +0100 (CET) In-Reply-To: <18804.26133.917740.497581@mariner.uk.xensource.com> Subject: Re: [Qemu-devel] [6324] Return -errno on write failure (Gleb Natapov) From: "=?utf-8?q?Fran=C3=A7ois?= Revol" Date: Mon, 19 Jan 2009 19:52:03 +0100 CET Message-Id: <7523661163-BeMail@laptop> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org > > > So BeOS is not ANSI C ! > > > > And so, well, what =3F > > 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 =3F (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 !=3D 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 =3F 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 =3F 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 =3F 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 !=3D0 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=C3=A7ois.