[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.
