Re: Implicition declarations of functions and bugs
Steve Greenland <steveg@moregruel.net> writes:
> On 12-Mar-06, 04:22 (CST), Bastian Blank <waldi@debian.org> wrote:
>> On Sat, Mar 11, 2006 at 01:43:34AM +0100, Samuel Thibault wrote:
>> > This is a warning and not an error, because using one's own strdup()
>> > function (that would take ints) is perfectly legal.
>>
>> No, it is not. At least not with a compiler in hosted mode. In this
>> mode, the compiler is allowed to have any knowledge about the standard
>> library builtin.
>
> Not if the relevant header hasn't been included. No "#include
> <string.h>", no compiler messing with "strdup()."
You are misinformed. First, note that strdup() is not in the
standard C library, but it is in the reserved str* name space.
Declaring strdup() with external linkage *always* yields
undefined behavior. Declaring strdup() with internal linkage
yields undefined behavior if <string.h> is included. Read the
standard:
7.1.3 Reserved identifiers
[...]
- All identifiers with external linkage in any of the
following subclauses (including the future library
directions) are always reserved for use as identifiers
with external linkage.154)
- Each identifier with file scope listed in any of the
following subclauses (including the future library
directions) is reserved for use as a macro name and as an
identifier with file scope in the same name space if any
of its associated headers is included.
[...]
7.26 Future library directions
1 The following names are grouped under individual headers for
convenience. All external names described below are
reserved no matter what headers are included by the program.
[...]
7.26.11 String handling <string.h>
1 Function names that begin with str, mem, or wcs and a lowercase
letter may be added to the declarations in the <string.h>
header.
--
"Writing is easy.
All you do is sit in front of a typewriter and open a vein."
--Walter Smith
Reply to: