Berndt <wulf@ping.net.au> wrote on Sun, 2 Mar 2003 at 22:59:47 +1030
in <200303021229.h22CTx315016@gw.ping.net.au>:

> > > STANDARDS
> > >      The memmem() function is an extension to ANSI X3.159-1989 (``ANSI C'').
> > 
> > An "extension"? Is this function mentioned in any standard or is it just
> > a linux thing?
> 
> It's not part of the standard and hence I consider it an extension of the
> string.h family of functions described by ANSI X3.159-1989 and
> ANSI/ISO 9899-1990.

As I think Julio makes clear, the wording is sufficiently vague to
produce confusion. I don't think it's appropriate to use the word
extension if the object of the preposition is the standard (though if
you said "NetBSD-specific extension", that would be ok I guess).  I
guess I would be most happy with "memmem() is not a standardized
function," with an indication of it's glibc origins under HISTORY.

It looks like the linux/glibc version has this to say:

| CONFORMING TO
| 
|       This function is a GNU extension. 
| 
| BUGS
| 
|       This function was broken in Linux libraries up to and including
| libc 5.0.9; there the `needle' and `haystack' arguments were
| interchanged, and a pointer to the end of the first occurrence of
| needle was returned. Since libc 5.0.9 is still widely used, this is a
| dangerous function to use. Both old and new libc's have the bug that
| if needle is empty haystack-1 (instead of haystack) is returned. And
| glibc (2.0.5) makes it worse, and returns a pointer to the last byte
| of `haystack'. Hopefully this will be fixed. For the time being,
| memmem() should not be used with an empty `needle'.

There should also be a HISTORY indicating that it first appeared in
glibc (if in fact that's where it first appeared).

Something along the lines of getopt_long(3)'s IMPLEMENTATION
DIFFERENECS section may also be appropriate, especially addressing our
interaction with the above bug.


Also, what is the status of X3.159? Are they continuing to meet and
are they discussing functions like this? Is there any indication
whether this is compatible with their future direction?

--jhawk

p.s.: you're missing the 'by' section of the copyright.