strdup

[Christopher Benson-Manica]

According to a recent c.l.c++ flame war, the semi-ubiquitous-but-not-ANSI
strdup() function actually violates the C standard, because it is illegally
named. If this is true, what standard naming rule(s) does it violate?

 

[Mike Wahler]

According to a recent c.l.c++ flame war,

I wouldn't call that a 'flame war', but a few folks
disagreeing, and some learning.

the semi-ubiquitous-but-not-ANSI
strdup() function actually violates the C standard, because it is illegally
named.

Yes, it violates a reserved name constraint.

If this is true, what standard naming rule(s) does it violate?

<begin quote>

ISO/IEC 9899:1999 (E)

[...]

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.

<end quote>

This does imply to me that the identifers 'str', 'mem',
and 'wcs' are allowed. Anyone care to confirm or deny?

-Mike

-Mike

 

[Christopher Benson-Manica]

I wouldn't call that a 'flame war', but a few folks
disagreeing, and some learning.

Some people "learning" more than others

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.

So, in essence, this is saying that at some point the Standard may choose to
specify a standard strdup() function? Come to think of it, since strdup() is
widely used, why isn't it standard? It isn't implementation-specific (like,
say, htonl and such)...

 

[Andreas Kahari]

According to a recent c.l.c++ flame war, the semi-ubiquitous-but-not-ANSI
strdup() function actually violates the C standard, because it is illegally
named. If this is true, what standard naming rule(s) does it violate?

Sections 7.26.10 and 7.26.11 of the C99 standard says that in
the future, functions that begin with "str" might be added to
the <stdlib.h> and <string.h> headers.

The rationale for 7.26 ends with "Users are advised that failure
to take heed of the points mentioned herein is considered
undesirable for a conforming program".

 

[Mike Wahler]

Some people "learning" more than others

Yep.

So, in essence, this is saying that at some point the Standard may choose to
specify a standard strdup() function?

It may choose to specify *any* external identifier which
begins with 'str' and a lowercase letter.

strdup, strthis, strthat, struptrouble, etc.

Come to think of it, since strdup() is
widely used, why isn't it standard?

You'll have to ask the committee members about that.
Such questions about 'why' etc. should be asked at
comp.std.c. Here we only discuss the language as it
is, not as it 'should be'.

It isn't implementation-specific

Yes, by definition, any function not specified by the
standard is implementation-specific. The fact that
many implementations might behave the same way doesn't
matter. In the case of 'strdup()' it's also a constraint
violation.

(like,
say, htonl and such)...

Those functions are by definition implementation-specific
as well.

E.g. I could write a 'htonl()' function which draws
pictures of naked women and emails them to your
pastor, and that would be perfectly legal according
to the standard (but probably not according to the
human laws of many jurisdictions. )

It doesn't matter if everyone else's 'htonl()' function
did something else.


-Mike

 

[Default User]

Mike Wahler wrote:

[strdup()]

Yes, by definition, any function not specified by the
standard is implementation-specific. The fact that
many implementations might behave the same way doesn't
matter. In the case of 'strdup()' it's also a constraint
violation.

I think he means that strdup() wouldn't require implementation-specific
stuff to be implemented, which would prevent the committee from
including it.




Brian Rodenborn

 

[Kevin Easton]

According to a recent c.l.c++ flame war, the semi-ubiquitous-but-not-ANSI
strdup() function actually violates the C standard, because it is illegally
named. If this is true, what standard naming rule(s) does it violate?

It's illegal for user code to define a function with that identifier -
but your C implementation is allowed to do so.

- Kevin

 

[Jack Klein]

I wouldn't call that a 'flame war', but a few folks
disagreeing, and some learning.


Yes, it violates a reserved name constraint.

[snip]

Actually it is unclear to me whether an implementation that provides a
function named strdup() is conforming unless it provides a mechanism
for disabling the visibility of such a function.

But since the word "constraint" is conspicuously absent from this
section of the standard, it most certainly is not a constraint
violation.

Actually I posted a question about very issue, using strdup() as an
example, to comp.std.c yesterday. If there are any replies, they
haven't reached my ISP's news server yet.

The question is exactly to whom these names are reserved, to the
"implementation" for whatever use it cares to make of them, or
strictly for "future additions to the standard".

Since the use of an identifier with any of the reserved patterns and
external linkage in a program invokes undefined behavior, no strictly
conforming program can ever determine whether its implementation
defines such a non-standard function.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++ ftp://snurse-l.org/pub/acllc-c++/faq

 

[Jack Klein]

It's illegal for user code to define a function with that identifier -
but your C implementation is allowed to do so.

I would love to see your reasoning for coming to that conclusion based
on the actual wording of the standard. I have always found it
ambiguous.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++ ftp://snurse-l.org/pub/acllc-c++/faq

 

[Kevin Easton]

I would love to see your reasoning for coming to that conclusion based
on the actual wording of the standard. I have always found it
ambiguous.

As you mention in your reply, a strictly conforming program can't tell
whether or not the implementation does define such a function, so the
"the implementation is free to provide extensions as long as they don't
affect the meaning of any strictly conforming program" rule comes into
play.

- Kevin.

 

[Jack Klein]

As you mention in your reply, a strictly conforming program can't tell
whether or not the implementation does define such a function, so the
"the implementation is free to provide extensions as long as they don't
affect the meaning of any strictly conforming program" rule comes into
play.

- Kevin.

Of course!

So glad I, er you, thought of that!

Thanks.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++ ftp://snurse-l.org/pub/acllc-c++/faq

 

[Simon Biber]

It may choose to specify *any* external identifier which
begins with 'str' and a lowercase letter.

strdup, strthis, strthat, struptrouble, etc.

strou(strup()) even.


IMHO strdup is a bad design with low cohesion, as it has two
separate sequential functions - <stdlib.h>'s malloc and
<string.h>'s strcpy. There is a competing desire to leave all
memory allocation functions in <stdlib.h>, and to leave all

Yes, by definition, any function not specified by the
standard is implementation-specific. The fact that
many implementations might behave the same way doesn't
matter. In the case of 'strdup()' it's also a constraint
violation.

Constraint violation? 7.1.3 just says undefined behaviour:
"If the program declares or defines an identifier in a context
in which it is reserved (other than as allowed by 7.1.4), or
defines a reserved identifier as a macro name, the behavior
is undefined."