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?

--
Christopher Benson-Manica | Jumonji giri, for honour.
ataru(at)cybers pace.org |

[Mike Wahler]

"Christophe r Benson-Manica" <at***@nospam.c yberspace.org> wrote in message
news:bk******** **@chessie.cirr .com...

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]

Mike Wahler <mk******@mkwah ler.net> spoke thus:

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)...

--
Christopher Benson-Manica | Jumonji giri, for honour.
ataru(at)cybers pace.org |

[Andreas Kahari]

In article <bk**********@c hessie.cirr.com >, Christopher Benson-Manica wrote:

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".
--
Andreas Kähäri

[Mike Wahler]

"Christophe r Benson-Manica" <at***@nospam.c yberspace.org> wrote in message
news:bk******** **@chessie.cirr .com...

Mike Wahler <mk******@mkwah ler.net> spoke thus:

I wouldn't call that a 'flame war', but a few folks
disagreeing, and some learning. :-)
Some people "learning" more than others ;)

Yep. :-)

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?
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()]

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.

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]

Christopher Benson-Manica <at***@nospam.c yberspace.org> wrote:

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]

On Fri, 19 Sep 2003 20:11:59 GMT, "Mike Wahler"
<mk******@mkwah ler.net> wrote in comp.lang.c:

"Christophe r Benson-Manica" <at***@nospam.c yberspace.org> wrote in message
news:bk******** **@chessie.cirr .com...

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.

[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.l earn.c-c++ ftp://snurse-l.org/pub/acllc-c++/faq

[Jack Klein]

On Fri, 19 Sep 2003 23:08:59 GMT, Kevin Easton
<[e-mail]> wrote in comp.lang.c:

Christopher Benson-Manica <at***@nospam.c yberspace.org> wrote:

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.

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.l earn.c-c++ ftp://snurse-l.org/pub/acllc-c++/faq

[Kevin Easton]

Jack Klein <ja*******@spam cop.net> wrote:

On Fri, 19 Sep 2003 23:08:59 GMT, Kevin Easton
<[e-mail]> wrote in comp.lang.c:

Christopher Benson-Manica <at***@nospam.c yberspace.org> wrote:

> 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.

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.