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

extern "C" issues

P: n/a
Hi All,

I am a newbie to C++ and I'm trying to figure this out. Can you please
help?

We have 3rd party library that's written in c++. We don't have the
source for it. ldd on that shared library indicates that it depends on
libstdc++. It has a printf() like function called

void xxx_print (char *format, ...)

The executable I built has to source files file_1.cpp and file_2.cpp.

In file_1.cpp, I had this line.

extern void xxx_print (char *format, ...);

In file_2.cpp, I had this line (accidentally)

extern "C" void xxx_print (char *format, ...);

When I ran the executable, the moment xxx_print statement was executed
in any function in file_2.cpp, the process died with exit code 127.
gdb didn't catch anything -- said it's because of GDB's internal
error.

I took off extern "C" (actually, included the header file) and all is
well now. I know that extern "C" is for linking against C code to take
care of name-mangling issues but in this case I had no issues building
and everything is fine as long as no xxx_print is done in file_2.cpp.
All xxx_print statements in file_1.cpp work fine.

I don't know what is messed up. Eventhough the problem is solved I
wanted to understand this better. Your help is greatly appreciated.

Thanks,
B

Feb 21 '07 #1
Share this Question
Share on Google+
2 Replies


P: n/a
* Bharath:
>
I am a newbie to C++ and I'm trying to figure this out. Can you please
help?

We have 3rd party library that's written in c++. We don't have the
source for it. ldd on that shared library indicates that it depends on
libstdc++. It has a printf() like function called

void xxx_print (char *format, ...)

The executable I built has to source files file_1.cpp and file_2.cpp.

In file_1.cpp, I had this line.

extern void xxx_print (char *format, ...);

In file_2.cpp, I had this line (accidentally)

extern "C" void xxx_print (char *format, ...);

When I ran the executable, the moment xxx_print statement was executed
in any function in file_2.cpp, the process died with exit code 127.
gdb didn't catch anything -- said it's because of GDB's internal
error.

I took off extern "C" (actually, included the header file) and all is
well now. I know that extern "C" is for linking against C code to take
care of name-mangling issues but in this case I had no issues building
and everything is fine as long as no xxx_print is done in file_2.cpp.
All xxx_print statements in file_1.cpp work fine.

I don't know what is messed up. Eventhough the problem is solved I
wanted to understand this better. Your help is greatly appreciated.
It's funny your linker didn't complain.

Perhaps the library provides various overloads of the function name,
i.e. different functions of the same name (it's a C++ library).

Anyway, 'extern "C"' may do more than provide simplified C-compatible
name mangling: it may also influence the machine code level calling
convention, how arguments are passed.

To avoid such problems, if possible use the library's own header files
instead of providing DIY declarations of the library functions used.

Even better advice might be to not use that particular library, because
"..." is unsafe, indicating a low-quality library, and having the format
string passed as 'char*' rather than 'char const*' also indicates a
low-quality library (although that might just be your declaration).

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Feb 21 '07 #2

P: n/a
On Feb 20, 7:41 pm, "Alf P. Steinbach" <a...@start.nowrote:
* Bharath:


I am a newbie to C++ and I'm trying to figure this out. Can you please
help?
We have 3rd party library that's written in c++. We don't have the
source for it. ldd on that shared library indicates that it depends on
libstdc++. It has a printf() like function called
void xxx_print (char *format, ...)
The executable I built has to source files file_1.cpp and file_2.cpp.
In file_1.cpp, I had this line.
extern void xxx_print (char *format, ...);
In file_2.cpp, I had this line (accidentally)
extern "C" void xxx_print (char *format, ...);
When I ran the executable, the moment xxx_print statement was executed
in any function in file_2.cpp, the process died with exit code 127.
gdb didn't catch anything -- said it's because of GDB's internal
error.
I took off extern "C" (actually, included the header file) and all is
well now. I know that extern "C" is for linking against C code to take
care of name-mangling issues but in this case I had no issues building
and everything is fine as long as no xxx_print is done in file_2.cpp.
All xxx_print statements in file_1.cpp work fine.
I don't know what is messed up. Eventhough the problem is solved I
wanted to understand this better. Your help is greatly appreciated.

It's funny your linker didn't complain.

Perhaps the library provides various overloads of the function name,
i.e. different functions of the same name (it's a C++ library).

Anyway, 'extern "C"' may do more than provide simplified C-compatible
name mangling: it may also influence the machine code level calling
convention, how arguments are passed.

To avoid such problems, if possible use the library's own header files
instead of providing DIY declarations of the library functions used.

Even better advice might be to not use that particular library, because
"..." is unsafe, indicating a low-quality library, and having the format
string passed as 'char*' rather than 'char const*' also indicates a
low-quality library (although that might just be your declaration).

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?- Hide quoted text -

- Show quoted text -
Thanks. That helps.

B

Feb 21 '07 #3

This discussion thread is closed

Replies have been disabled for this discussion.