C99 Question

[Vijay Kumar R Zanvar]

Hi,

Which section of C99 says that return value
of malloc(3) should not be casted?

Thanks.

--
Vijay Kumar R Zanvar
My Home Page - http://www.geocities.com/vijoeyz/

[Clark Cox]

In article <bt**********@n ews.tudelft.nl> ,
Sidney Cadot <si****@jigsaw. nl> wrote:

Clark Cox wrote:

The alternative you suggest is often simply not possible. For example,
my current project involves a library that needs to link to Matlab and
IDL, which cannot reliably be made to work with C++ compiled code - they
only support C plugins.

That's exactly what 'extern "C"' is for.

extern "C" is for letting a C++ compiler use C-type linkage, allowing
use of a C library from within C++ (but /not/ the other way round, which
would be needed for your suggestion to work).

[mildly-OT]
extern "C" *does* work in both directions (i.e. you can write C++
code that is callable from C code and vice versa):

//C++ code in file file1.cpp:
extern "C"
{
int foo(int i)
{
return i+1;
}
}

/*C code in file file2.c:*/
#include <stdio.h>

extern int foo(int);

int main()
{
printf("%d\n", foo(1));
return 0;
}
[/mildly-OT]

[Chris Torek]

[in <news:bt******* ***@news.tude lft.nl>, Sidney Cadot wrote:]

... Most properly written C code compiles flawlessly in C++,
except for a very small number of cases.

Chris Torek wrote:

Either you have a different definition of "properly written" than
I do, or your experience differs quite a bit from mine. Using
gcc's "-x c++" to compile .c files as C++ code, I find that *most*
of the (C) code I deal with fails to compile -- yet, in most cases, it
seems "properly written" to me.

In article <bt**********@n ews.tudelft.nl>
Sidney Cadot <si****@jigsaw. nl> writes:In your experience, what are the most important reasons for this to fail?
I do not know about "most important", and it is not something I
do often, but here is another trivial example of code that compiles
as C but not as C++. One might use something like this as a
"patchable constant" for ROMs, for embedded-system code:

% cat t1.c
const int n = 3;
% cat t2.c
#include <stdio.h>

extern const int n;

int main(void) {
printf("n = %d\n", n);
return 0;
}
% cc -o t t[12].c && ./t
n = 3
% cc -x c++ -o t t[12].c && ./t
/tmp/ccmoKUzh.o: In function `main':
/tmp/ccmoKUzh.o(.tex t+0xa): undefined reference to `n'

Another problem that comes up, albeit rarely, is the change in
sizeof 'a' (1 in C++, sizeof(int) in C). This one, like my earlier
example, usually results in silent breakage instead of compile-time
failure.
[scope rules example]

Ouch, that's messy.
Indeed.
In all objectivity though: wouldn't you agree that most C programmers
(even moderately able ones) would expect sizeof(struct A) to refer to
the first definition? I know I would.
I am not sure whether I would say that -- it is hard to tell without
actually doing a statistical sample. :-)
To me, this example says: C has some pretty non-intuitive rules with
regard to type resolution; avoid shadowing type names to avoid confusion.
This *is* a good rule.
Now for one question that I hesitate to ask: would you have cought this
issue earlier on in your development cycle if you had done a C++ test
compile & run every couple of weeks or so? (Perhaps that's not possible
because your code is too "non-C++" for that to be an option).

The code was never intended to be used with C++, and in fact, the
bones of it were written either before cfront existed, or -- at
the latest -- when C++ was "whatever cfront accepts". But in the
late 1990s, someone decided they wanted to import some of it into
a C++ program and, well. :-)
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) [phone]
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.

[Bjarne Stroustrup]

Chris Torek <no****@torek.n et> wrote in message news:<bt******* *@enews3.newsgu y.com>...

[in <news:bt******* ***@news.tude lft.nl>, Sidney Cadot wrote:]

... Most properly written C code compiles flawlessly in C++,
except for a very small number of cases.
Chris Torek wrote: Either you have a different definition of "properly written" than
I do, or your experience differs quite a bit from mine. Using
gcc's "-x c++" to compile .c files as C++ code, I find that *most*
of the (C) code I deal with fails to compile -- yet, in most cases, it
seems "properly written" to me.
In article <bt**********@n ews.tudelft.nl>
Sidney Cadot <si****@jigsaw. nl> writes:

In your experience, what are the most important reasons for this to fail?
I do not know about "most important", and it is not something I
do often, but here is another trivial example of code that compiles
as C but not as C++. One might use something like this as a
"patchable constant" for ROMs, for embedded-system code:

% cat t1.c
const int n = 3;
% cat t2.c
#include <stdio.h>

extern const int n;

int main(void) {
printf("n = %d\n", n);
return 0;
}
% cc -o t t[12].c && ./t
n = 3
% cc -x c++ -o t t[12].c && ./t
/tmp/ccmoKUzh.o: In function `main':
/tmp/ccmoKUzh.o(.tex t+0xa): undefined reference to `n'

As in so many other cases, you get the identical result in C and C++
by adding a bit of information. In this case, adding an "extern" in
t1.c to tell C++ that "n" can be used elsewhere solves the problem.
Another problem that comes up, albeit rarely, is the change in
sizeof 'a' (1 in C++, sizeof(int) in C). This one, like my earlier
example, usually results in silent breakage instead of compile-time
failure.
[scope rules example]

Ouch, that's messy.

Indeed.

In all objectivity though: wouldn't you agree that most C programmers
(even moderately able ones) would expect sizeof(struct A) to refer to
the first definition? I know I would.

I am not sure whether I would say that -- it is hard to tell without
actually doing a statistical sample. :-)

To me, this example says: C has some pretty non-intuitive rules with
regard to type resolution; avoid shadowing type names to avoid confusion.

This *is* a good rule.

Now for one question that I hesitate to ask: would you have cought this
issue earlier on in your development cycle if you had done a C++ test
compile & run every couple of weeks or so? (Perhaps that's not possible
because your code is too "non-C++" for that to be an option).

The code was never intended to be used with C++, and in fact, the
bones of it were written either before cfront existed, or -- at
the latest -- when C++ was "whatever cfront accepts". But in the
late 1990s, someone decided they wanted to import some of it into
a C++ program and, well. :-)

I, at least, never defined C++ as "whet Cfront accepted".

- Bjarne Stroustrup; http://www.research.att.com/~bs

[Sidney Cadot]

Clark Cox wrote:

In article <bt**********@n ews.tudelft.nl> ,
Sidney Cadot <si****@jigsaw. nl> wrote:

Clark Cox wrote:
extern "C" is for letting a C++ compiler use C-type linkage, allowing
use of a C library from within C++ (but /not/ the other way round, which
would be needed for your suggestion to work).

extern "C" *does* work in both directions (i.e. you can write C++
code that is callable from C code and vice versa):

The fact that it happens to work on some compiler suites (gcc, for
example) doesn't help much. My library needs to work on AIX, SGI, HP-UX,
Solaris, an some more, with their various proprietary compiler suites.

7.5 of the C++ standard states:

"9. Linkage from C++ to objects defined in other languages and to
objects defined in C++ from other languages is implementation-defined
and language-dependent. Only where the object layout strategies of two
language implementations are similar enough can such linkage be achieved."

This effectively disqualifies C++ as an implementation language for my
project, since we have to link to IDL/Matlab (both written in C) on all
these platforms.
Best regards,

Sidney

[Clark Cox]

In article <bt**********@n ews.tudelft.nl> ,
Sidney Cadot <si****@jigsaw. nl> wrote:

Clark Cox wrote:

In article <bt**********@n ews.tudelft.nl> ,
Sidney Cadot <si****@jigsaw. nl> wrote:

Clark Cox wrote:
extern "C" is for letting a C++ compiler use C-type linkage, allowing
use of a C library from within C++ (but /not/ the other way round, which
would be needed for your suggestion to work).

extern "C" *does* work in both directions (i.e. you can write C++
code that is callable from C code and vice versa):

The fact that it happens to work on some compiler suites (gcc, for
example) doesn't help much. My library needs to work on AIX, SGI, HP-UX,
Solaris, an some more, with their various proprietary compiler suites.

7.5 of the C++ standard states:

"9. Linkage from C++ to objects defined in other languages and to
objects defined in C++ from other languages is implementation-defined
and language-dependent. Only where the object layout strategies of two
language implementations are similar enough can such linkage be achieved."

This effectively disqualifies C++ as an implementation language for my
project, since we have to link to IDL/Matlab (both written in C) on all
these platforms.

extern "C" is by defintion implementation defined in either
direction, but where it works, it works in both directions. Extern "C"
tells the C++ compiler to use C calling and naming conventions, whether
you are applying it to a function whose implementation is in C, or a
function whose implementation is in C++.
Check out the comp.lang.c++ FAQ:
http://www.parashift.com/c++-faq-lit...c-and-cpp.html

Pay attention to question 32.6 "How can I create a C++ function
f(int,char,floa t) that is callable by my C code?"

[P.J. Plauger]

"Sidney Cadot" <si****@jigsaw. nl> wrote in message
news:bt******** **@news.tudelft .nl...

extern "C" *does* work in both directions (i.e. you can write C++
code that is callable from C code and vice versa):

The fact that it happens to work on some compiler suites (gcc, for
example) doesn't help much. My library needs to work on AIX, SGI, HP-UX,
Solaris, an some more, with their various proprietary compiler suites.

7.5 of the C++ standard states:

"9. Linkage from C++ to objects defined in other languages and to
objects defined in C++ from other languages is implementation-defined
and language-dependent. Only where the object layout strategies of two
language implementations are similar enough can such linkage be achieved."

This effectively disqualifies C++ as an implementation language for my
project, since we have to link to IDL/Matlab (both written in C) on all
these platforms.

Every one of the platforms you list above has at least one combined
C/C++ compiler. If *any* such combo has linkage or layout problems
between their C and C++ personae, I don't know about it. And I'd be
astonished to encounter such problems.

You may contrive other reasons to disqualify C++ for your project,
but this particular one is terminally lame.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com

[Arthur J. O'Dwyer]

On Sat, 3 Jan 2004, P.J. Plauger wrote:

"Sidney Cadot" <si****@jigsaw. nl> wrote...

extern "C" *does* work in both directions (i.e. you can write C++
code that is callable from C code and vice versa):

The fact that it happens to work on some compiler suites (gcc, for
example) doesn't help much. My library needs to work on AIX, SGI, HP-UX,
Solaris, an some more, with their various proprietary compiler suites. [...] This effectively disqualifies C++ as an implementation language for my
project, since we have to link to IDL/Matlab (both written in C) on all
these platforms.

Every one of the platforms you list above has at least one combined
C/C++ compiler. If *any* such combo has linkage or layout problems
between their C and C++ personae, I don't know about it. And I'd be
astonished to encounter such problems.

You may contrive other reasons to disqualify C++ for your project,
but this particular one is terminally lame.

This may be terminally naive of me, and it's certainly off-topic,
but couldn't the problem be that those compilers that compile both C
and C++, do not produce object formats compatible with the object
formats supported by IDL/Matlab? Presumably Mr. Cadot does not
have either C or C++ source code for Matlab's libraries...

-Arthur

[Sidney Cadot]

P.J. Plauger wrote:

"Sidney Cadot" <si****@jigsaw. nl> wrote in message
news:bt******** **@news.tudelft .nl...

extern "C" *does* work in both directions (i.e. you can write C++
code that is callable from C code and vice versa):
The fact that it happens to work on some compiler suites (gcc, for
example) doesn't help much. My library needs to work on AIX, SGI, HP-UX,
Solaris, an some more, with their various proprietary compiler suites.

7.5 of the C++ standard states:

"9. Linkage from C++ to objects defined in other languages and to
objects defined in C++ from other languages is implementation-defined
and language-dependent. Only where the object layout strategies of two
language implementations are similar enough can such linkage be achieved."

This effectively disqualifies C++ as an implementation language for my
project, since we have to link to IDL/Matlab (both written in C) on all
these platforms.

Every one of the platforms you list above has at least one combined
C/C++ compiler. If *any* such combo has linkage or layout problems
between their C and C++ personae, I don't know about it. And I'd be
astonished to encounter such problems.

You may contrive other reasons to disqualify C++ for your project,
but this particular one is terminally lame.

I do not have regular access to all the platforms we have to support,
much less so to all platforms with all used versions of Matlab and IDL
(ranging from +/- 5 years old, to current). We distribute the library as
source code; the user (or his sysadmin) has to compile it. The
installation process /has/ to be as simple as configure/make/make install.

Using C++ would imply that

(1) I'd have to know the C compilers with which the particular versions
of Matlab/IDL on the user system was compiled, and act appropriately on
different combibations.

(2) The user would need to have the (possibly old) C/C++ compiler suite
on his system, in many cases.

(3) The old C/C++ compiler suite needs to support dynamic linking of
C++ code to binary-only libraries (that's how matlab and IDL work).

Implementing it in C++ would be a maintenance nightmare, bound to end in
many more disgruntled users (because they couldn't get the damn thing to
work) than we currently have. I'd be busier special-casing for weird
combinations than anything else - there'd be little time left to improve
the library functionality.

One further note is that both Matlab and IDL do not officially support
linking to C++ code (although, yes, it can be done, for newer versions,
if one is careful).

Due to all these real-life constraints, we opted for the conservative
approach by sticking to C. Some special-casing still needs to be done,
but this is along the dimension of Matlab/IDL versions (which change
APIs between versions now and then).

Frankly, I'm pleasantly surprised that it works for so many users
without a hitch, when using C, given the many combinations of Matlab/IDL
versions and OS'es our library works for.

Your calling this "contrived" reason "particular ly lame" suggests to me
that I failed to make the context of the problems we faced not clear
enough. I hope this helps.

Best regards,

Sidney

[Sidney Cadot]

Arthur J. O'Dwyer wrote:

Every one of the platforms you list above has at least one combined
C/C++ compiler. If *any* such combo has linkage or layout problems
between their C and C++ personae, I don't know about it. And I'd be
astonished to encounter such problems.

You may contrive other reasons to disqualify C++ for your project,
but this particular one is terminally lame.

This may be terminally naive of me, and it's certainly off-topic,
but couldn't the problem be that those compilers that compile both C
and C++, do not produce object formats compatible with the object
formats supported by IDL/Matlab? Presumably Mr. Cadot does not
have either C or C++ source code for Matlab's libraries...

I don't. Floating even farther off-topic, I work in a commercial setting
where we have a product to deliver. We cannot afford to have too many
unpleasant surprises; if the Matlab and IDL docs (and newsgroups)
consistently state that one should not attempt to write plugins using
C++, that's all there is to it as far as I am concerned.

Best regards,
Sidney

[E. Robert Tisdale]

Clark Cox wrote:

Extern "C" tells the C++ compiler
to use C calling and naming conventions

No!
Extern "C" only *helps* with linkage.
There is *no* ANSI/ISO C++ interoperabilit y standard
which governs function calling protocol.
Different compilers may pass and return values in different registers or
in different order on the program stack.
Built-in data types may have different sizes.