How likely is a function starting with an underscore to cause undefined behavior?

[Jim Langston]

I know that functions starting with an underscore, or two underscores, are
reserved by the compiler/c++ and should not be used by the user and may
cause undefined behavior. My question is, how likely is it to actually
cause undefined behavior?

The reason I'm asking is I'm using a game engine where the sockets code is
not working correctly on my computer, but seems to work correctly on
everyone elses. I am not compiling the dll myself, but using the same one
that everyone else is using.

Well, the developer of the engine has released the one .cpp file that
contains the socket code, and I see he is using a number of functions
preceeded by an underscore. I have posted requesting that he rename the
functions to remove the underscore explaining that it is reserved.

But I want to know if I should keep looking in the code to try to find the
problem, or if him renaming the functions might fix it. Unfortunately, I
only have one file from the .dll so I can't recompile it to test, and since
the problem doesn't happen on his machine, he can't test. Not the best
debugging scenario around for sure.

Has anyone ever experienced any undefined behavior being caused by a
function name being preceeded by an underscore or two? Most of his actually
have 2 underscores in front such as:
int __get_free_ws_player()

 

[Ben Pope]

I know that functions starting with an underscore, or two underscores, are
reserved by the compiler/c++ and should not be used by the user and may
cause undefined behavior.

Actually, it's identifiers starting with an underscore follwed by an
upper case letter, or starting with two underscores.

My question is, how likely is it to actually
cause undefined behavior?

How likely? That's undefined. One possible outcome of undefined is
"exactly what you expected".

The reason I'm asking is I'm using a game engine where the sockets code is
not working correctly on my computer, but seems to work correctly on
everyone elses. I am not compiling the dll myself, but using the same one
that everyone else is using.

Well, it's possible that it will do what you expected on one platform,
and do something unexpected on another platform. Platform is usually
considered to be the compiler and libraries used. I suppose it's
possible for it to cause problems at runtime. It is undefined.

Ben Pope

 

[Axter]

Actually, it's identifiers starting with an underscore follwed by an
upper case letter, or starting with two underscores.

Strictly speaking, a leading underscore followed by a digit or
lower-case letter is legal in your own namespaces (but never in the
global namespace or ::std): 17.4.3.1.2/1 [lib.global.names].
However, articles in the comp.std.c++ newsgroup have warned that some
compilers do improperly use such identifiers for their own purposes.

My advice is to steer clear of using leading underscore names
completely. It doesn't add benifits to your code, and it makes your
code less portable.

A lose-lose senerio.

 

[Bob Hairgrove]

However, articles in the comp.std.c++ newsgroup have warned that some
compilers do improperly use such identifiers for their own purposes.

Improperly? What about section 17.4.3.1.2?

My advice is to steer clear of using leading underscore names
completely. It doesn't add benifits to your code, and it makes your
code less portable.

And it is in violation of section 17.4.3.1.2.

 

[Phlip]

A lose-lose senerio.

A reminder: We treat the term "undefined behavior" as unholy and unclean. We
should work to a Sane Subset that stays so far within defined behavior that
its definity is totally obvious.

Undefined behavior could mean anything, from the program working correctly,
to compiler diagnostic (likely for some _ abuse), to the nearest toilet
exploding.

 

[Jakob Bieling]

Actually, it's identifiers starting with an underscore follwed by an
upper case letter, or starting with two underscores.

Hmm, I vaguely remember that *any* identifier with two consecutive
underscores is reserved .. ?

regards

 

[Ben Pope]

Hmm, I vaguely remember that *any* identifier with two consecutive
underscores is reserved .. ?

I dunno, maybe. I's ugly anyway, I don't do it.

Ben Pope

 

[Jakob Bieling]

I dunno, maybe. I's ugly anyway, I don't do it.

Right, me neither. Just thought I'd mention it for others .. if it
is correct, but I think it is.

regards

 

[Ben Pope]

Right, me neither. Just thought I'd mention it for others .. if it is
correct, but I think it is.

I think you're right.

Ben Pope

 

[Gavin Deane]

I think you're right.

I know he's right
17.4.3.1.2
Each name that contains a double underscore (_ _) or begins with an
underscore followed by an uppercase letter (2.11) is reserved to the
implementation for any use.

Gavin Deane

 

[Axter]

I know he's right
17.4.3.1.2
Each name that contains a double underscore (_ _) or begins with an
underscore followed by an uppercase letter (2.11) is reserved to the
implementation for any use.

That is not complete.
Here's the full section pulled from the official C++ standard:
**************************************************************************************************
17.4.3.1.2 Global Names
1 Certain sets of names and functions signature are always reserved to
the implementation:
-- Each name that contains a double underscore (_ _) or begins with
an
underscore followed by an uppercase letter (2.11) is reserved to the
implementation for any use.
-- Each name that begins with an underscore is reserved to the
implementation for use as a name in the global namespace.
**************************************************************************************************

Notice the last paragraph is talking about any name that begins with an
underscore.

If you have a draft version of the standard, it may or may not have the
full definition.
I recommend you get the official standard for a complete discription.

 

[Kai-Uwe Bux]

Jim Langston wrote:

[snip]

Has anyone ever experienced any undefined behavior being caused by a
function name being preceeded by an underscore or two?

Not me.

Most of his actually have 2 underscores in front such as:
int __get_free_ws_player()

You could write a little test program that uses exactly those function names
from his file and see if the resulting undefined behavior matches your
expectations. This might give you a clue as to wether your implementation
is actually using those names for something hidden.


Best

Kai-Uwe Bux

 

[Noah Roberts]

I know that functions starting with an underscore, or two underscores, are
reserved by the compiler/c++ and should not be used by the user and may
cause undefined behavior. My question is, how likely is it to actually
cause undefined behavior?

Well, assuming you are declaring a name with an underscore at such a
point where it is reserved for implementation use then your program is
ill-formed. That being the case the behavior of this program, if it
even compiles, is ALWAYS undefined.

What you mean is how likely is this to cause undesired behavior? Not
very. Your program either compiles or it doesn't. A name resolution
conflict is going to result in a compilation error; your linker
wouldn't accept the library either. You need to keep looking for the
problem.

 

[Gavin Deane]

That is not complete.
Here's the full section pulled from the official C++ standard:
**************************************************************************************************
17.4.3.1.2 Global Names
1 Certain sets of names and functions signature are always reserved to
the implementation:
-- Each name that contains a double underscore (_ _) or begins with
an
underscore followed by an uppercase letter (2.11) is reserved to the
implementation for any use.
-- Each name that begins with an underscore is reserved to the
implementation for use as a name in the global namespace.
**************************************************************************************************

Notice the last paragraph is talking about any name that begins with an
underscore.

The context I retained in my post was only discussing whether double
underscores were definitely reserved for the implementation or not. So
I quoted the part of the standard relevant to that discussion. Perhaps
I could have made it more clear that I wasn't quoting the entirety of
17.4.3.1.2

If you have a draft version of the standard, it may or may not have the
full definition.
I recommend you get the official standard for a complete discription.

My quote came form the 1998 standard. I haven't got the 2003 version
yet, but I'd be surprised if this is an area that has changed.

Gavin Deane

 

[Michiel.Salters]

Has anyone ever experienced any undefined behavior being caused by a
function name being preceeded by an underscore or two?

Yes, and it was very tricky as the name was used as a macro by the
implementation.

HTH,
Michiel Salters

 

[Axter]

Well, assuming you are declaring a name with an underscore at such a
point where it is reserved for implementation use then your program is
ill-formed. That being the case the behavior of this program, if it
even compiles, is ALWAYS undefined.

What you mean is how likely is this to cause undesired behavior? Not
very. Your program either compiles or it doesn't. A name resolution
conflict is going to result in a compilation error; your linker
wouldn't accept the library either. You need to keep looking for the
problem.

I have seen example code that shows under the right condition, you will
not get a compile error if you're using variable names reserved for the
implementation.
It would silently compile your code, with no compile errors, but the
compiled code would not result in intended logic.

 

[AnalogFile]

Improperly? What about section 17.4.3.1.2?

He is right. He's referring to non global namespaces.
Those implementations that use identifiers with leading underscore
followed by lowercase or digit in a non global non std namespace do it
improperly.

And it is in violation of section 17.4.3.1.2.

Not.

namespace my {

void _foo(); // legal

};