One warning less - memchr

[Andreas Jaeger]

>>>>> Greg McGary writes:

Greg> Andreas Jaeger <aj@suse.de> writes:
>> could you please check your builds that you don't introduce new
>> warnings into the code?

Greg> generic/memchr.c isn't compiled for ix86, so I didn't see it.  I could
Greg> do one of two things: (1) do cross-builds of more targets, say
Greg> PowerPC, MIPS and SPARC in order to catch non-ix86 warnings, or (2)
Greg> rely on others to catch the non-ix86 warnings.  Do you consider cases
Greg> like this to be enough of a burden on you that I should do #1?

I think it's enough for you to test this on ix86.  Btw. I'm currently
setting up automatic builds of glibc on PowerPC, Sparc, Alpha, i686 -
this should give everybody the chance to spot these problems directly.

>> I've fixed the follwoing one now:
>> ../sysdeps/generic/memchr.c:61: warning: function declaration isn't a prototype
>> 
>> The patch has been committed to CVS.
>> 
>> Andreas
>> 
>> 2000-07-18  Andreas Jaeger  <aj@suse.de>
>> 
>> * include/string.h: Add prototype for __memchr.

Greg> I would have fixed it by making memchr's declarator be a prototype in
Greg> memchr.c.


Greg> I had purposely left this undeclared.  Declaring it defeats my purpose
Greg> in making the alias to begin with.  I want to be able to use the
Greg> unbounded __memchr in bounded code, which might also use the bounded
Greg> memchr.  By declaring a prototype in include/string.h, gcc will think
Greg> that __memchr has bounded pointers as well, so my uses in CHECK_STRING
Greg> won't behave as desired.

I fixed it the way we do it in general in glibc.  If you have problems
with it, just send a new patch.  But what you're doing looks like a
special case to me.  Do you only want to use __memchr this way?  In
that case please document it properly.

Greg> OTOH, it seems overly sneaky to require that __memchr remain
Greg> undeclared in order for CHECK_STRING to function properly.

Greg> I have a couple other ideas on how to work around this:

Greg> 1) In bp-checks.h, use #define to shunt the decl of __memchr aside,
Greg>    so that it remains unbounded.  This also seems too sneaky, and will
Greg>    break any code that explicitly uses __memchr in a normally.

Greg> 2) Create another BP-specific alias.  The one I had originally was
Greg>    __ubp_memchr.  I think this is the least troublesome way to go.

Andreas
-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.rhein-neckar.de