svn commit: r229368 - in head: lib/libc lib/libc/arm/string lib/libc/i386/string lib/libc/mips/string lib/libc/string lib/libstand sys/boot/userboot/libstand

[Ed Schouten]

Hi Bruce,

* Bruce Evans <brde at optusnet.com.au>, 20120103 16:49:
> This breaks the Standard C namespace.  When they are in the same object
> file, there is no way to get the standard name without getting the
> nonstandard name.  So the following C-standard-conforming C program
> now gets a linkage error (multiple definition of `index'), at least with
> static linkage:
> 
>     #include <string.h>
>     int index;
>     void foo(const char *p) { return strchr(p, '1'); }

Though I sympathize, this problem is not just limited to strchr(). There
are other portions of the C library that use index() as well. For
example, if you use <ttyent.h>, ttyslot(), one of the exec*() functions
or the NIS functions, you already get index() linked into your binary.

> [...] and the C
> standard might require memcpy and memmove to have different addresses.

I just skimmed through the standard, and if I haven't overlooked
anything, no such requirement is made. Also, I can imagine a compiler
with good support for link-time optimisation can already merge equal
pieces of code together, making it even harder to reason about
inequality of function addresses.

Still, I am willing to address the issues you raised. index() and
rindex() aren't that important nowadays and I have a patchset ready in
my home directory that converts almost all apps in the base system to
use strchr() anyway.

As I don't feel like polluting the MI strchr() implementations with
index()/rindex() support, would it be okay if I implement index() and
rindex() as simple C functions that call into strchr() and strrchr()?

-- 
 Ed Schouten <ed at 80386.nl>
 WWW: http://80386.nl/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 834 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/svn-src-head/attachments/20120103/c9883ac8/attachment.pgp