Re: build with clang-3.4 warnings report

[Szabolcs Nagy <nsz@port70.net>]

* Jens Gustedt <jens.gustedt@inria.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)