By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
455,127 Members | 1,211 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 455,127 IT Pros & Developers. It's quick & easy.

strdup

P: n/a
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)cyberspace.org |
Nov 13 '05 #1
Share this Question
Share on Google+
11 Replies


P: n/a
"Christopher Benson-Manica" <at***@nospam.cyberspace.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
Nov 13 '05 #2

P: n/a
Mike Wahler <mk******@mkwahler.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)cyberspace.org |
Nov 13 '05 #3

P: n/a
In article <bk**********@chessie.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
Nov 13 '05 #4

P: n/a
"Christopher Benson-Manica" <at***@nospam.cyberspace.org> wrote in message
news:bk**********@chessie.cirr.com...
Mike Wahler <mk******@mkwahler.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
Nov 13 '05 #5

P: n/a
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
Nov 13 '05 #6

P: n/a
Christopher Benson-Manica <at***@nospam.cyberspace.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

Nov 13 '05 #7

P: n/a
On Fri, 19 Sep 2003 20:11:59 GMT, "Mike Wahler"
<mk******@mkwahler.net> wrote in comp.lang.c:
"Christopher Benson-Manica" <at***@nospam.cyberspace.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.learn.c-c++ ftp://snurse-l.org/pub/acllc-c++/faq
Nov 13 '05 #8

P: n/a
On Fri, 19 Sep 2003 23:08:59 GMT, Kevin Easton
<kevin@-nospam-pcug.org.au> wrote in comp.lang.c:
Christopher Benson-Manica <at***@nospam.cyberspace.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.learn.c-c++ ftp://snurse-l.org/pub/acllc-c++/faq
Nov 13 '05 #9

P: n/a
Jack Klein <ja*******@spamcop.net> wrote:
On Fri, 19 Sep 2003 23:08:59 GMT, Kevin Easton
<kevin@-nospam-pcug.org.au> wrote in comp.lang.c:
Christopher Benson-Manica <at***@nospam.cyberspace.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.

Nov 13 '05 #10

P: n/a
On Sat, 20 Sep 2003 05:07:21 GMT, Kevin Easton
<kevin@-nospam-pcug.org.au> wrote in comp.lang.c:
Jack Klein <ja*******@spamcop.net> wrote:
On Fri, 19 Sep 2003 23:08:59 GMT, Kevin Easton
<kevin@-nospam-pcug.org.au> wrote in comp.lang.c:
Christopher Benson-Manica <at***@nospam.cyberspace.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.


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
Nov 13 '05 #11

P: n/a
"Mike Wahler" <mk******@mkwahler.net> wrote:
It may choose to specify *any* external identifier which
begins with 'str' and a lowercase letter.

strdup, strthis, strthat, struptrouble, etc.
strou(strup()) even. :-)

"Christopher Benson-Manica" <at***@nospam.cyberspace.org> wrote:
Come to think of it, since strdup() is
widely used, why isn't it standard?


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
string manipulation functions in <string.h>. The best solution
is to regard it as something the users must handle themselves.
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."

--
Simon.
Nov 13 '05 #12

This discussion thread is closed

Replies have been disabled for this discussion.