Re: One warning less - memchr

[Greg McGary <greg at mcgary dot org>]

Andreas Jaeger <aj@suse.de> writes:

> could you please check your builds that you don't introduce new
> warnings into the code?

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

> 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.

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

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

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

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

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

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

Greg