ifdefs

[Your Uncle]

# ifdef __cplusplus
extern "C" {
# endif

int * get_an_int(void);
int * pass_pointer_triv(int *);


# ifdef __cplusplus
}
# endif


#include <stdio.h>
#include <stdlib.h>

int main(void)
{
int *rt, *qt;
qt = get_an_int();
rt = pass_pointer_triv(qt);
printf ("t is %d\n", *rt);
free(rt);
return 0;
}

int * get_an_int(void)
{
int t;
int * pt;
pt = malloc (sizeof*pt);
t = 41;
pt[0] = t;
return pt;
}

int * pass_pointer_triv(int *a)
{
int t;
t = (*a) ++;
printf("t is %d\n", t);
return a;
}
/* end source */
This compiles and behaves, as it is a lot of machinery that doesn't do a
whole lot yet. My question goes to the ifdefing. What am I doing there
outside of making myself look stupid down the hall? furunculus

 

[Richard Heathfield]

Your Uncle said:

# ifdef __cplusplus
extern "C" {
# endif

int * get_an_int(void);
int * pass_pointer_triv(int *);


# ifdef __cplusplus
}
# endif

int * pt;
pt = malloc (sizeof*pt);
t = 41;
pt[0] = t;

If malloc failed, the behaviour of this assignment is undefined.

This compiles and behaves, as it is a lot of machinery that doesn't do a
whole lot yet. My question goes to the ifdefing. What am I doing there
outside of making myself look stupid down the hall?

Nothing whatsoever, as far as comp.lang.c is concerned. The #ifdefs,
#endifs, and the stuff in between them are all of no consequence and can be
omitted without affecting the semantics of your C program in any way.

 

[Walter Roberson]

# ifdef __cplusplus
extern "C" {
# endif

int * get_an_int(void);
int * pass_pointer_triv(int *);

# ifdef __cplusplus
}
# endif [...]

This compiles and behaves, as it is a lot of machinery that doesn't do a
whole lot yet. My question goes to the ifdefing. What am I doing there
outside of making myself look stupid down the hall?

If you were to happen to compile the code under a C++ compiler, those
#ifdef's would be activated, providing some code for use with C++ that
would not be inserted if you compiled under C.

The exact meaning of those constructs under C++ is a question for
a C++ newsgroup, not a C newsgroup, but as a quick summary: those
constructs tell C++ that the routines within the { } pair are to
use "C linkage" instead of "C++ linkage". Which -mostly- means that
those routines, when compiled under C++, will NOT have the hidden "this"
parameter.

#include <stdio.h>
#include <stdlib.h>

int * pass_pointer_triv(int *a)
{
int t;
t = (*a) ++;
printf("t is %d\n", t);
return a;
}

Just to check: did you intend that pass_pointer_triv have
the side effect of incrementing that integer at the location
pointed to, and that that increment be done *after* the value
to be printed was determined? e.g., that (say) 5 would be
printed but afterwards the pointer would point to the value 6 ?

 

[Your Uncle]

# ifdef __cplusplus
extern "C" {
# endif

int * get_an_int(void);
int * pass_pointer_triv(int *);

# ifdef __cplusplus
}
# endif [...]

This compiles and behaves, as it is a lot of machinery that doesn't do a
whole lot yet. My question goes to the ifdefing. What am I doing there
outside of making myself look stupid down the hall?

If you were to happen to compile the code under a C++ compiler, those
#ifdef's would be activated, providing some code for use with C++ that
would not be inserted if you compiled under C.

The exact meaning of those constructs under C++ is a question for
a C++ newsgroup, not a C newsgroup, but as a quick summary: those
constructs tell C++ that the routines within the { } pair are to
use "C linkage" instead of "C++ linkage". Which -mostly- means that
those routines, when compiled under C++, will NOT have the hidden "this"
parameter.

I refuse to believe that linkage between c and c++ is OT in either forum,
given that it isn't a preamble to some silly holy war. The OP lacks the
requisite bloodlust.

Just to check: did you intend that pass_pointer_triv have
the side effect of incrementing that integer at the location
pointed to, and that that increment be done *after* the value
to be printed was determined? e.g., that (say) 5 would be
printed but afterwards the pointer would point to the value 6 ?

I got the return I was looking for on my own silly implementation. cheers,
f

 

[Walter Roberson]

Your Uncle said:

Nothing whatsoever, as far as comp.lang.c is concerned. The #ifdefs,
#endifs, and the stuff in between them are all of no consequence and can be
omitted without affecting the semantics of your C program in any way.

Just to be a pest ;-)


-Potentially- something in the C implementation could define
__cplusplus [I think -- "reserved for any use" allows implementation
use, right?]. It'd be a strange thing to do, but if it happened
then the semantics of the C program would indeed be affected. ;-)

 

[Walter Roberson]

I refuse to believe that linkage between c and c++ is OT in either forum,
given that it isn't a preamble to some silly holy war.

Well, what I should perhaps have said is,
"The exact meaning of those constructs under C++ is a question for
a C++ newsgroup, not this newsgroup, but as a quick summary:"

The -existance- of C++ is effectively off-topic for comp.lang.c .
There might be other C newsgroups that deal with C++ as well as C,
but comp.lang.c doesn't.

Discussing the linkage between C and C++ requires a good knowledge of
C++ linkage, which is not something that is specified in any C
standard.

Indeed, the details of C linkage are not specified in any
C standard, so comp.lang.c doesn't even deal with with linking
C to C, beyond the various restrictions on variable names, the
meaning of "extern", and the implied promise of the C standard that
the implementation will provide *some* linkage mechanism.

In C++, does declaring a function to have C linkage change the
default promotions for that function? You can't talk about
the linkage between C and C++ until you can answer that question,
and you can't answer that question without knowing the details of
C++'s promotion rules, which are different from C's, and C++'s
promotion rules are not specified by the C standards.

Thus in order to discuss the linkage between C and C++ one would have
to enter into a detailed cross-comparison of C and C++ language
features. Which we are not going to do. And if you "refuse to believe"
that, then you will likely find the experience akin to that
of a Flat Earth Society member attending an Astronomy convention.

 

[Guest]

# ifdef __cplusplus
extern "C" {
# endif

int * get_an_int(void);
int * pass_pointer_triv(int *);

# ifdef __cplusplus
}
# endif [...]

This compiles and behaves, as it is a lot of machinery that doesn't do a
whole lot yet. My question goes to the ifdefing. What am I doing there
outside of making myself look stupid down the hall?

If you were to happen to compile the code under a C++ compiler, those
#ifdef's would be activated, providing some code for use with C++ that
would not be inserted if you compiled under C.

The exact meaning of those constructs under C++ is a question for
a C++ newsgroup, not a C newsgroup, but as a quick summary: those
constructs tell C++ that the routines within the { } pair are to
use "C linkage" instead of "C++ linkage". Which -mostly- means that
those routines, when compiled under C++, will NOT have the hidden "this"
parameter.

I'm pretty sure C++ non-member functions never have a hidden "this"
parameter. It is indeed OT here regardless, so a C++ group, as you
suggested, would clear it up properly.

 

[Roberto Waltman]

# ifdef __cplusplus
extern "C" {
# endif

int * get_an_int(void);
int * pass_pointer_triv(int *);

# ifdef __cplusplus
}
# endif

[...]

The exact meaning of those constructs under C++ is a question for
a C++ newsgroup, not a C newsgroup, but as a quick summary: those
constructs tell C++ that the routines within the { } pair are to
use "C linkage" instead of "C++ linkage". Which -mostly- means that
those routines, when compiled under C++, will NOT have the hidden "this"
parameter.

<OT>
Not in this case. "this" would used in C++ functions declared as class
methods.
This is definitively implementation dependent, but in most cases the
"extern C" modifier means that the function names will not be
modified, ("mangled",) to provide type-safe linkage using a
conventional linker.

I.e., if __cplusplus is not defined, the object file will use the
following symbols for each function:

int * get_an_int(void); ---> _get_an_int
int * pass_pointer_triv(int *); ---> _pass_pointer_triv

If __cplusplus is defined, g++ (3.2.2/Linux) will generate the
following:

int * get_an_int(void); ---> _Z10get_an_intv
int * pass_pointer_triv(int *); ---> _Z17pass_pointer_trivPi

</OT>

 

[Roberto Waltman]

I wrote:

Not in this case. "this" would used in C++ functions declared as class
methods.
This is definitively implementation dependent, but in most cases the
"extern C" modifier means that the function names will not be
modified, ("mangled",) to provide type-safe linkage using a
conventional linker.

I.e., if __cplusplus is not defined, the object file will use the
following symbols for each function:

int * get_an_int(void); ---> _get_an_int
int * pass_pointer_triv(int *); ---> _pass_pointer_triv

If __cplusplus is defined, g++ (3.2.2/Linux) will generate the
following:

int * get_an_int(void); ---> _Z10get_an_intv
int * pass_pointer_triv(int *); ---> _Z17pass_pointer_trivPi

That is wrong. Trying again...

* Using a C compiler __cplusplus is not (should not be?) defined and
the extern "C" is ignored.

* Using a C++ compiler, __cplusplus is defined, and the extern "C"
causes the compiler to process the declarations as before. (This
allows calling them from C code.)

* Using a C++ compiler *without* the #ifdefs produces the "mangled"
symbols, usable from C++ but not directly callable from C.

 

[Your Uncle]

Well, what I should perhaps have said is,
"The exact meaning of those constructs under C++ is a question for
a C++ newsgroup, not this newsgroup, but as a quick summary:"

Thus in order to discuss the linkage between C and C++ one would have
to enter into a detailed cross-comparison of C and C++ language
features. Which we are not going to do. And if you "refuse to believe"
that, then you will likely find the experience akin to that
of a Flat Earth Society member attending an Astronomy convention.

The choice of spacio-temporal origin is arbitrary. Why, since lines were
curved for Euclid, would the adjective "flat" not suffice for him? Thanks
for posting something that needed to be snipped. cheers, f

 

[Keith Thompson]

Just to be a pest ;-)


-Potentially- something in the C implementation could define
__cplusplus [I think -- "reserved for any use" allows implementation
use, right?]. It'd be a strange thing to do, but if it happened
then the semantics of the C program would indeed be affected. ;-)

In C90, theoretically, yes.

In C99, the compiler is specifically forbidden to define the
__cplusplus macro.

 

[Default User]

Walter Roberson wrote:

I'm pretty sure C++ non-member functions never have a hidden "this"
parameter. It is indeed OT here regardless, so a C++ group, as you
suggested, would clear it up properly.

You're correct. The "C linkage" means that the symbol won't have
name-mangling, which is an implementation-specific C++ technique for
resolving overloaded symbols. Usually this means incorporating the
argument types in the symbol name. C doesn't have overloading, so the
function names aren't usually mangled.



Brian

 

[Ian Collins]

Harald van Dijk wrote:





You're correct. The "C linkage" means that the symbol won't have
name-mangling, which is an implementation-specific C++ technique for
resolving overloaded symbols. Usually this means incorporating the
argument types in the symbol name. C doesn't have overloading, so the
function names aren't usually mangled.

Shouldn't that be "function names aren't mangled."? I can't think of
any instances where they are, except maybe truncation on some old systems.

 

[Default User]

Default User wrote:
Shouldn't that be "function names aren't mangled."? I can't think of
any instances where they are, except maybe truncation on some old
systems.

I don't believe there's anything in the Standard that would preclude
name-mangling. I could be wrong. I usually hedge a bit, otherwise if
you say "never" someone will point out the compiler on the Rinky-Dink
Jr. used a sort of name-mangling.



Brian

 

[Ian Collins]

Ian Collins wrote:





I don't believe there's anything in the Standard that would preclude
name-mangling. I could be wrong. I usually hedge a bit, otherwise if
you say "never" someone will point out the compiler on the Rinky-Dink
Jr. used a sort of name-mangling.

I thought so I don't remember seeing any reference to name mangling in
the standard, just checking.

Cheers,

 

[Keith Thompson]

I don't believe there's anything in the Standard that would preclude
name-mangling. I could be wrong. I usually hedge a bit, otherwise if
you say "never" someone will point out the compiler on the Rinky-Dink
Jr. used a sort of name-mangling.

It's not uncommon for external symbols to have a '_' prepended, or to
be truncated (to 31 characters or more in C99, 6 or more in C90), or
to be mapped to upper or lower case (C90 only). Whether this
constitutes "mangling" is another question.

 

[Your Uncle]

It's not uncommon for external symbols to have a '_' prepended, or to
be truncated (to 31 characters or more in C99, 6 or more in C90), or
to be mapped to upper or lower case (C90 only). Whether this
constitutes "mangling" is another question.

The other guys mentioned "mangling" first. As I read it, I recounted Mr.
Sosman's anecdote about a prolific employee.
[possibly unfair snip]

We must do something. This is something. Therefore, we must do this.

My guess is that you know 42 volumes on linking c to the other guys. I
don't have an errant syllogism to motivate a response. cheers, f