Hi Bruce,
* Bruce Evans <b...@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 <e...@80386.nl> WWW: http://80386.nl/
pgpGOOWfplqVX.pgp
Description: PGP signature
