|
Message-ID: <20140405093115.GK3034@port70.net> Date: Sat, 5 Apr 2014 11:31:15 +0200 From: Szabolcs Nagy <nsz@...t70.net> To: musl@...ts.openwall.com Subject: Re: build with clang-3.4 warnings report * Jens Gustedt <jens.gustedt@...ia.fr> [2014-04-05 11:04:58 +0200]: > This seems to come from the bogus handling of EDQUOT by mips: > > /* mips has one error code outside of the 8-bit range due to a > * historical typo, so we just remap it. */ > > This remapping seems only to have been done correctly for the strerror > function itself but not for the array declaration. > > An equivalent patch for that line would be > > #define E(a,b) (unsigned char)((EDQUOT==1133 && (a)==EDQUOT) ? 109 : a), > > but which makes it only apparent how bogus this is. the cast should be fine 1133%256 == 109 and 109 is an unused errno number on mips (this is why the mips bug can be worked around and yes it's ugly but at least it does not penalize other archs) > To "repair" the mips problem I would just do > > I think the real bug is here > > #define E(a,b) ((unsigned char)a), > > this is a typical case of someone using a cast to burry a > problem, black magic, "casting a spell". you forgot to write what would you do :) the cast hides a compiler warning about the >UCHAR_MAX errno (making the warning visible makes sense, however i highly doubt there ever will be another broken errno) > As this bug shows, the whole technique of searching the error string > in strerror is somehow fragile. > > The whole thing could be avoided by using designated initializers and > eliminating the whole errid array right away. Designated initializers > should be present in all decent versions of gcc. Do you want me to > prepare a patch? how? strerror is size optimized (there are various ways to do strerror, but i could not improve on rich's code)
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.