Re: memchr bug? Request for enlightenment (lowercase 'e')

[<michael donahue nist gov>]

Chris Eleveld writes:
>	Actually this may not be.  You allocate 9 bytes.  Memchr is probably
>implemented using full word or longword fetches.  As such it can be optimized
>to 3 32bit fetches and bit shifts.  Or even 2 64 bit on an alpha.  Since you
>lied and siad your buffer was 79 bytes long.  If on the other hand you used
>9 instead of 79 you could call this a bug.

I believe you are right about the longword fetches.  I'm a little
surprised I haven't see this on other platforms, though.

As regards the length of the buffer, the point is that this call may be
buried inside a utility routine where I don't know the length of the
incoming buffer.  I have code similar to the printf example; I don't
recall seeing an admonition about buffer sizes in the printf docs.  In
fact, the Linux fprintf man page says:

   If a precision is given, no null character need be present; if the
   precision is not specified, or is greater than the size of the array,
   the array must contain a terminating NUL character.

The memchr man page states:

   The memchr() function scans the first n bytes of the memory area
   pointed to by s for the character c.  The first byte to match c
   (interpreted as an unsigned character) stops the operation.

This seems unclear.  Does it scan n bytes, or does it stop at a match?
Or is that left undefined?

For myself, I can code around this as necessary, but if it is
technically a bug in memchr(), it should be fixed for portability
reasons.

Just my $0.02,

-m

-- 
Michael J. Donahue
National Institute of Standards and Technology
Mathematical & Computational Sciences Division
100 Bureau Dr Stop 8910
Gaithersburg, MD 20899-8910
email: michael.donahue@nist.gov
voice: (301) 975-5424
  fax: (301) 990-4127
  web: http://math.nist.gov/~MDonahue/