naming functions and variables str*

[John Smith]

I understand that C identifiers beginning with str are reserved for
future implementations. Do variable and function names beginning with
str in my existing code, which is for my own use only, constitute a
functional bug or a potential for undefined behaviour? Does "future
implementation" mean a formal revision of the current standard?

JS

[Walter Roberson]

In article <kIU6e.983315$8l.628412@pd7tw1no>,
John Smith <JS****@mail.net> wrote:

I understand that C identifiers beginning with str are reserved for
future implementations. Do variable and function names beginning with
str in my existing code, which is for my own use only, constitute a
functional bug or a potential for undefined behaviour?

If new str* are added to the standard (possibly as an addendum
rather than a formal revision), and they happen to overlap your names,
then there is the potential that if you recompiled your code with
a compiler that had the new functions, that you could run into
symbol overlaps; that could result in anything from a compile
error for mismatched prototypes, to a refusal to link, to the
code not doing what you wanted because the wrong function was called.

The idea is future-proofing: if you avoid str* now then you
don't have to change your code later.
--
Entropy is the logarithm of probability -- Boltzmann

[pete]

Walter Roberson wrote:

In article <kIU6e.983315$8l.628412@pd7tw1no>,
John Smith <JS****@mail.net> wrote:

I understand that C identifiers beginning with str are reserved for
future implementations. Do variable and function names beginning with
str in my existing code, which is for my own use only, constitute a
functional bug or a potential for undefined behaviour?

If new str* are added to the standard (possibly as an addendum
rather than a formal revision), and they happen to overlap your names,
then there is the potential that if you recompiled your code with
a compiler that had the new functions, that you could run into
symbol overlaps; that could result in anything from a compile
error for mismatched prototypes, to a refusal to link, to the
code not doing what you wanted because the wrong function was called.

The idea is future-proofing: if you avoid str* now then you
don't have to change your code later.

Function names that begin with str and a lowercase letter
are reserved.
char *str_cpy(char *s1, const char *s2);
is fine.

--
pete

[CBFalconer]

Walter Roberson wrote:

John Smith <JS****@mail.net> wrote:

I understand that C identifiers beginning with str are reserved for
future implementations. Do variable and function names beginning
with str in my existing code, which is for my own use only,
constitute a functional bug or a potential for undefined behaviour?

If new str* are added to the standard (possibly as an addendum
rather than a formal revision), and they happen to overlap your
names, then there is the potential that if you recompiled your code
with a compiler that had the new functions, that you could run into
symbol overlaps; that could result in anything from a compile error
for mismatched prototypes, to a refusal to link, to the code not
doing what you wanted because the wrong function was called.

The idea is future-proofing: if you avoid str* now then you
don't have to change your code later.

It's more than that. Those names are reserved for the
implementation. So an implementor can provide a functions
strblah(...) which does whatever he wishes, place it in the
library, and call it from his internal operations. If you replace
it you can cause well known standard library functions to fail.
You gotta know the territory.

I will concede in advance that such an event is unlikely, and would
probably result in negative comments about the implementation
quality.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson

[Mark L Pappin]

CBFalconer <cb********@yahoo.com> writes:

Walter Roberson wrote:

The idea is future-proofing: if you avoid str* now then you
don't have to change your code later.

It's more than that. Those names are reserved for the
implementation. So an implementor can provide a functions
strblah(...) which does whatever he wishes, place it in the
library, and call it from his internal operations. If you replace
it you can cause well known standard library functions to fail.
You gotta know the territory.

I will concede in advance that such an event is unlikely, and would
probably result in negative comments about the implementation
quality.

I don't know ... I'm kind of keen on compilers flagging as much
non-sanctioned behaviour as they can, and reserved identifiers seem to
be an easier thing to catch than [the general case of] i = i++.
(Quietly breaking when such an identifier is used is, however,
sub-optimal.)

mlp

[John Smith]

CBFalconer wrote:

Walter Roberson wrote:

John Smith <JS****@mail.net> wrote:

I understand that C identifiers beginning with str are reserved for
future implementations. Do variable and function names beginning
with str in my existing code, which is for my own use only,
constitute a functional bug or a potential for undefined behaviour?
If new str* are added to the standard (possibly as an addendum
rather than a formal revision), and they happen to overlap your
names, then there is the potential that if you recompiled your code
with a compiler that had the new functions, that you could run into
symbol overlaps; that could result in anything from a compile error
for mismatched prototypes, to a refusal to link, to the code not
doing what you wanted because the wrong function was called.

The idea is future-proofing: if you avoid str* now then you
don't have to change your code later.

It's more than that. Those names are reserved for the
implementation. So an implementor can provide a functions
strblah(...) which does whatever he wishes, place it in the
library, and call it from his internal operations. If you replace
it you can cause well known standard library functions to fail.

This is the kind of thing I was concerned about. I suppose one can
examine the implementation's headers to find out if this is the case.
You gotta know the territory.

I will concede in advance that such an event is unlikely, and would
probably result in negative comments about the implementation
quality.

[Ian Pilcher]

CBFalconer wrote:

It's more than that. Those names are reserved for the
implementation. So an implementor can provide a functions
strblah(...) which does whatever he wishes, place it in the
library, and call it from his internal operations. If you replace
it you can cause well known standard library functions to fail.
You gotta know the territory.

I will concede in advance that such an event is unlikely, and would
probably result in negative comments about the implementation
quality.

Not necessarily. SuS includes strdup, so an application-defined
function of that name could very easily cause a conflict, without
inviting negative comments.

--
================================================== ======================
Ian Pilcher i.*******@comcast.net
================================================== ======================

[CBFalconer]

Ian Pilcher wrote:

CBFalconer wrote:

It's more than that. Those names are reserved for the
implementation. So an implementor can provide a functions
strblah(...) which does whatever he wishes, place it in the
library, and call it from his internal operations. If you replace
it you can cause well known standard library functions to fail.
You gotta know the territory.

I will concede in advance that such an event is unlikely, and would
probably result in negative comments about the implementation
quality.

Not necessarily. SuS includes strdup, so an application-defined
function of that name could very easily cause a conflict, without
inviting negative comments.

The smarter implementor will create __strdup, and put a #define in
the appropriate header file (possibly with guards for pedantic
conformity etc.) such as:

#define strdup __strdup

and the problem goes away when the appropriate header is not
included.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson

[Ian Pilcher]

CBFalconer wrote:

The smarter implementor will create __strdup, and put a #define in
the appropriate header file (possibly with guards for pedantic
conformity etc.) such as:

#define strdup __strdup

and the problem goes away when the appropriate header is not
included.

Good point, however ...

strdup is declared in <string.h>. Any translation unit that makes use
of an application-defined strdup it likely to also make use of other
functions declared in this header.

Either way, the reasons for not using str... names are good.

--
================================================== ======================
Ian Pilcher i.*******@comcast.net
================================================== ======================

[those who know me have no need of my name]

in comp.lang.c i read:

I suppose one can examine the implementation's headers to find out if this
is the case.

every one of them you use? will you even remember to check each new
implementation as you begin using it? will you check every implementation
each time it is updated? yes, that's the scope of the issue -- save
yourself the hassle, stay away from str*, and is*, mem*, to* and wcs*. is*
surprises lots of people (e.g., int isactive();). but there is hope, the
reservation is only when the identifier has external linkage and the prefix
is followed by a lowercase letter, so an underscore gets you back into the
safe zone without much disruption. in theory an uppercase letter will too,
but external identifiers aren't required to be case sensitive so it might
also bite you -- stick with the underscore.

also an initial E if followed by an uppercase letter or a decimal digit.

also an initial LC, SIG or SIG_ if followed by an uppercase letter.

and also, of course, those with an initial underscore.

see <http://oakroadsystems.com/tech/c-predef.htm> for a more involved
discussion of the issues.

--
a signature