469,356 Members | 2,033 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,356 developers. It's quick & easy.

Casting the return value of malloc() ?

Hi,

I have often wondered if casting the return value of malloc() (or
friends) actually helps anything, recent threads here suggest that it
does not .. so I hope to find out.

For instance :

char *tmp = NULL;

tmp = (char *) malloc(1024);

Is there any pointing in casting the return value of malloc? I see
many people do that, but not test the result such as :

if (tmp == (char *) NULL)
.. some code about malloc() failing ...

Is there any point in casting it?

Cheers,
--Tim
Oct 2 '08
101 3705
Ian Collins said:
Richard Heathfield wrote:
>Ian Collins said:
>>Richard Heathfield wrote:
ja*********@verizon.net said:
vipps...@gmail.com wrote:
>Unless the implementation defines __cplusplus ;-)
That's not permitted for a conforming implementation ot C99
(6.10.8p5).
True, but of little relevance for the time being.

Now now Richard, some of us do use platforms where the native compiler
is C99.

Sure - and there are some people who do fly on the Space Shuttle.

There's rather a lot more Solaris and AIX developers than space shuttle
passengers.
Nevertheless, C99 users are a vanishingly small percentage of the C
programming population. The analogy is, I think, a reasonable one.
>
>>Try putting #define __cplusplus before #include <stdio.hand see how
far your compiler gets.

No, I can't do that, because __cplusplus starts with two consecutive
underscores, which means it's reserved for the implementation.

You can't, but you might be a compiler implementer who's tempted to add
the define to one of your implementation's headers. Doing so would be a
great way to limit sales.
Well, I'm not - and in any case, because C99 forbids __cplusplus and
because I program in the common subset of C89 and C99, I couldn't define
__cplusplus even if I were an implementor.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Oct 9 '08 #51
Ian Collins wrote:
>
.... snip ...
>
How often does C share system or standard library headers with
COBOL? Try putting #define __cplusplus before #include <stdio.h>
and see how far your compiler gets.
That identifier is reserved for the implementation.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.
Oct 9 '08 #52
Richard Heathfield wrote:
Ian Collins said:
>Richard Heathfield wrote:
>>Ian Collins said:

Richard Heathfield wrote:
ja*********@verizon.net said:
>vipps...@gmail.com wrote:
>>Unless the implementation defines __cplusplus ;-)
>That's not permitted for a conforming implementation ot C99
>(6.10.8p5).
True, but of little relevance for the time being.
>
Now now Richard, some of us do use platforms where the native compiler
is C99.
Sure - and there are some people who do fly on the Space Shuttle.
There's rather a lot more Solaris and AIX developers than space shuttle
passengers.

Nevertheless, C99 users are a vanishingly small percentage of the C
programming population. The analogy is, I think, a reasonable one.
I think the ratio is somewhat less than 100000000:1, which is about
right for shuttle passengers in the global population.

--
Ian Collins.
Oct 9 '08 #53
CBFalconer wrote:
Ian Collins wrote:
.... snip ...
>How often does C share system or standard library headers with
COBOL? Try putting #define __cplusplus before #include <stdio.h>
and see how far your compiler gets.

That identifier is reserved for the implementation.
The lost quote from James was "I think that was permitted in C90, but
I'm not sure. It was never good QoI, at least not at any time since the
birth of C++."

QoI applies to the implementation.

--
Ian Collins.
Oct 9 '08 #54
Ian Collins said:
Richard Heathfield wrote:
>Ian Collins said:
>>Richard Heathfield wrote:
Ian Collins said:

Richard Heathfield wrote:
>ja*********@verizon.net said:
>>vipps...@gmail.com wrote:
>>>Unless the implementation defines __cplusplus ;-)
>>That's not permitted for a conforming implementation ot C99
>>(6.10.8p5).
>True, but of little relevance for the time being.
>>
Now now Richard, some of us do use platforms where the native
compiler is C99.
Sure - and there are some people who do fly on the Space Shuttle.
There's rather a lot more Solaris and AIX developers than space shuttle
passengers.

Nevertheless, C99 users are a vanishingly small percentage of the C
programming population. The analogy is, I think, a reasonable one.
I think the ratio is somewhat less than 100000000:1, which is about
right for shuttle passengers in the global population.
However much you try to avoid the issue, there aren't very many people
using C99 implementations.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Oct 9 '08 #55
Nick Keighley <ni******************@hotmail.comwrote:
On 8 Oct, 09:38, Richard Heathfield <r...@see.sig.invalidwrote:
Ian Collins said:
Nick Keighley wrote:
>Well written C compiles with C++. That is a fact.
^^^^^^^^^^^^
Ahem.
And they are "well-written" constructs, too.

Nick, are you really saying that adding a cast to a call to a function
returning void * is either badly-written C or legal C++?

er, no.

char *fred = (char*)malloc(42);

is not particularly good C but it will compile with C++.
^^^^^^^^^^^^^^^^^^^^^
Ahem.

Contradiction?

Richard
Oct 9 '08 #56
Richard Heathfield wrote:
ja*********@verizon.net said:
>vipps...@gmail.com wrote:
....
>>Unless the implementation defines __cplusplus ;-)
....
>It
was never good QoI, at least not at any time since the birth of C++.

Why is it not good QoI? It is not the job of any programming language to
avoid treading on the toes of another language.
QoI means doing more than the minimum requirement; it means actually
being useful to the user. Code which is written to compile under either
C or C++, achieving that portability with the help of checks for
__cplusplus, is a reality, however much you personally may disapprove of
it. A C90 compiler that predefines __cplusplus is going to cause
problems for such code, and the fact that it was legal for the
implementation to do so won't make it's justifiably angry customers any
happier about that fact.

... Would we criticise an
implementation's QoI for using the identifier ENVIRONMENT (which is
reserved, like __cplusplus) just because it clashes with COBOL?
COBOL is not sufficiently similar to C to encourage the writing of code
that is meaningfully compilable in both languages. I don't remember
enough about COBOL to be sure whether it's possible to use the same kind
of commenting tricks that allow you to write a Fortran program that also
compiles as a C program - but in any event that's not what I'm talking
about.

For C and C++, it's possible to write a program where code which is not
inside a comment, in either language, and which survives conditional
compilation in both languages, constitutes the majority of a significant
program, and gets compiled with essentially the same interpretation in
both languages. That's not possible for C and COBOL.

The ENVIRONMENT keyword was not defined by COBOL for the specific
purpose of allowing a program compilable by both languages to determine
which language it was being compiled for. Also, it is far more plausible
that a C implementation would have a legitimate non-malicious reason to
use ENVIRONMENT, than it is for __cplusplus.

For all these reasons, I wouldn't dream of criticizing a C
implementation that made use of an ENVIRONMENT identifier; I would
criticize any C90 compiler that used a legal loophole to justify
predefining a __cplusplus macro.
Oct 9 '08 #57
James Kuyper said:

<snip>
QoI means doing more than the minimum requirement; it means actually
being useful to the user.
The most useful thing a C compiler could do on encountering __cplusplus
would be to #error That's C++. This is a C compiler. Duh.
Code which is written to compile under either
C or C++, achieving that portability with the help of checks for
__cplusplus, is a reality, however much you personally may disapprove of
it.
If the code is legal C and legal C++, it will either be bad C, bad C++, or
both. Daft idea. Silly to pander to daft ideas. Harumph, etc.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Oct 9 '08 #58
Richard Heathfield <rj*@see.sig.invalidwrites:
The most useful thing a C compiler could do on encountering __cplusplus
would be to #error That's C++. This is a C compiler. Duh.
That's the most stupidiest thing a C compiler could do.

#ifdef __cplusplus
extern "C" {
#endif

....

#ifdef __cplusplus
}
#endif

is something which is very sensible to put on headers designed to be used
in C (while providing the implementation of the functions there declared)
as well as in C++ (which use that code).

While the interest of compiling function definition in C as well as in C++
is debatable -- I think it is sometimes usefull and my estimation of the
number of cases where it is seems to be somewhere between your estimation
and James' -- having common headers for both languages is usefull.

Yours,

--
Jean-Marc
Oct 9 '08 #59
In article <JN******************************@bt.com>,
Richard Heathfield <rj*@see.sig.invalidwrote:
>QoI means doing more than the minimum requirement; it means actually
being useful to the user.
>The most useful thing a C compiler could do on encountering __cplusplus
would be to #error That's C++. This is a C compiler. Duh.
Surely the point of __cplusplus is to allow code to be conditionalised
for the two languages.
>If the code is legal C and legal C++, it will either be bad C, bad C++, or
both. Daft idea. Silly to pander to daft ideas. Harumph, etc.
A header file conditionalised for inclusion in both C and C++ is
certainly ugly, but I don't think it's necessarily a daft idea to
write such header files. It seems like a design flaw that C++
routinely requires such conditionalisation though.

-- Richard
--
Please remember to mention me / in tapes you leave behind.
Oct 9 '08 #60
Richard Heathfield wrote:
James Kuyper said:

<snip>
>QoI means doing more than the minimum requirement; it means actually
being useful to the user.

The most useful thing a C compiler could do on encountering __cplusplus
would be to #error That's C++. This is a C compiler. Duh.
Not if it's being used to determine whether to conditionally include C
code or C++ code, by someone who wants the compiler to compile it as C
code. The only "useful" thing about treating it as a #error is that it
informs the user that he's selected the wrong C compiler for this purpose.
>Code which is written to compile under either
C or C++, achieving that portability with the help of checks for
__cplusplus, is a reality, however much you personally may disapprove of
it.

If the code is legal C and legal C++, it will either be bad C, bad C++, or
both. Daft idea. Silly to pander to daft ideas. Harumph, etc.
I disagree that it's daft. Whether or not it's daft, it's moderately
popular. Even if it were daft, the simple fact that it is also popular
is sufficient to make predefinition of __cplusplus bad QoI.
Oct 9 '08 #61
Jean-Marc Bourguet said:
Richard Heathfield <rj*@see.sig.invalidwrites:
>The most useful thing a C compiler could do on encountering __cplusplus
would be to #error That's C++. This is a C compiler. Duh.

That's the most stupidiest thing a C compiler could do.
Clearly, opinions differ.
>
#ifdef __cplusplus
extern "C" {
#endif

...

#ifdef __cplusplus
}
#endif

is something which is very sensible to put on headers designed to be used
in C (while providing the implementation of the functions there declared)
as well as in C++ (which use that code).
In C89, it can result in a diagnostic message and the failure of the
translation. And opening oneself up to that problem is pretty stupid too.

If you want to use a header in C and yet have access to that header in C++,
it's trivial to do without breaking either language's rules:

/* C header - cheader.h */

#ifndef H_CHEADER
#define H_CHEADER 1
int foo(void); /* or whatever */
#endif

/* C++ header - cppheader.h */
#ifndef H_CPPHEADER
#define H_CPPHEADER 1
extern "C"
{
#include "cheader.h"
}
#endif

<snip>

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Oct 9 '08 #62
In article <9M******************************@bt.com>,
Richard Heathfield <rj*@see.sig.invalidwrote:
>In C89, it can result in a diagnostic message and the failure of the
translation. And opening oneself up to that problem is pretty stupid too.
Do you know of any real implementations where this is true? So much
widely-used software uses #ifdef __cplusplus that I would have thought
that rejecting it would be a serious barrier to sales.

-- Richard
--
Please remember to mention me / in tapes you leave behind.
Oct 9 '08 #63
Richard Heathfield wrote:
James Kuyper said:

<snip>
>QoI means doing more than the minimum requirement; it means
actually being useful to the user.

The most useful thing a C compiler could do on encountering
__cplusplus would be to #error That's C++. This is a C compiler.
Not so. We want the universal use in the header file. I.e:

#ifdef __cplusplus
extern "C"
{
#endif
... normal header file ...
#ifdef __cplusplus
}
#endif

and now the module is callable from C and C++.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.
Oct 9 '08 #64
CBFalconer said:
Richard Heathfield wrote:
>James Kuyper said:

<snip>
>>QoI means doing more than the minimum requirement; it means
actually being useful to the user.

The most useful thing a C compiler could do on encountering
__cplusplus would be to #error That's C++. This is a C compiler.

Not so. We want the universal use in the header file.
No, we don't. We want a clear delineation between the two languages.
I.e:

#ifdef __cplusplus
extern "C"
{
#endif
... normal header file ...
#ifdef __cplusplus
}
#endif

and now the module is callable from C and C++.
At the cost of introducing a syntax error into the C code, protected by the
flimsiest of defences.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Oct 9 '08 #65
Richard Tobin said:
In article <9M******************************@bt.com>,
Richard Heathfield <rj*@see.sig.invalidwrote:
>>In C89, it can result in a diagnostic message and the failure of the
translation. And opening oneself up to that problem is pretty stupid too.

Do you know of any real implementations where this is true?
Do you know that one won't be released tomorrow, with such fantastic
compensating advantages that everyone flocks to it despite its strident
approach to __cplusplus?

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Oct 9 '08 #66
In article <w6******************************@bt.com>,
Richard Heathfield <rj*@see.sig.invalidwrote:
>>>In C89, it can result in a diagnostic message and the failure of the
translation. And opening oneself up to that problem is pretty stupid too.
>Do you know of any real implementations where this is true?
>Do you know that one won't be released tomorrow, with such fantastic
compensating advantages that everyone flocks to it despite its strident
approach to __cplusplus?
I'm pretty sure of that, yes. Certainly sure enough not to worry
about using __cplusplus.

-- Richard
--
Please remember to mention me / in tapes you leave behind.
Oct 9 '08 #67
Richard Heathfield wrote:
CBFalconer said:
Richard Heathfield wrote:
James Kuyper said:

<snip>

QoI means doing more than the minimum requirement; it means
actually being useful to the user.

The most useful thing a C compiler could do on encountering
__cplusplus would be to #error That's C++. This is a C compiler.
Not so. We want the universal use in the header file.

No, we don't. We want a clear delineation between the two languages.
Both of you are use "we"; I'm not sure who "we" is in each case, but
it's clear that the two of you are using the terms to describe non-
overlapping sets of people. Why don't the two of you both go back to
"I", unless you are willing to define who "we" are, with sufficiently
precision to clearly exclude the other person?

I have no objection to a "clear delineation between the two
languages", but for me a "clear delineation" means that it's easy for
code which has been written to compile using either language to
determine which language it is being compiled for, which is obviously
incompatible with the meaning that you attach to that phrase.
Oct 9 '08 #68
ja*********@verizon.net said:
Richard Heathfield wrote:
>CBFalconer said:
<snip>
Not so. We want the universal use in the header file.

No, we don't. We want a clear delineation between the two languages.

Both of you are use "we"; I'm not sure who "we" is in each case,
Clearly it's intended to mean "all the bright people". How accurately it is
being used is another matter. :-)
I have no objection to a "clear delineation between the two
languages", but for me a "clear delineation" means that it's easy for
code which has been written to compile using either language to
determine which language it is being compiled for, which is obviously
incompatible with the meaning that you attach to that phrase.
For me, it means use a C++ compiler to compile C++ code, and use a C
compiler to compile C code.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Oct 9 '08 #69
Richard Heathfield <rj*@see.sig.invalidwrites:
ja*********@verizon.net said:
[...]
>I have no objection to a "clear delineation between the two
languages", but for me a "clear delineation" means that it's easy for
code which has been written to compile using either language to
determine which language it is being compiled for, which is obviously
incompatible with the meaning that you attach to that phrase.

For me, it means use a C++ compiler to compile C++ code, and use a C
compiler to compile C code.
For you, and for most *but not all* C and/or C++ programmers who know
what they're doing.

But, for example, the C++ standard requires support for the C standard
headers; "#include <stdlib.h>" is valid C++ ( "#include <cstdlib>" is
usually preferred, but both are valid). In a typical implementation,
it makes sense to have a single "/usr/include/stdlib.h" file that's
usable by either C or C++ code, using the __cplusplus symbol to
differentiate. Yes, you could do it with two separate files, but then
you'd have to have either a different naming scheme or a different
header search path for the C and C++ compilers. Why add that
complication when it's not necessary? And why not allow authors of C
libraries to make their headers usable for C++ programmers as well?

Sure, the C90 standard doesn't forbid a C implementation to predefine
__cplusplus -- but a compiler that did so would be exhibiting a DS9K
level of perversity (or a serious configuration error in a combined C
and C++ implementation that had better be fixed before the product
sees the light of day). Henry Spencer's warning goes both ways: if
the compiler lies to me, I will get my revenge. It would take a
deliberate blindness to anything outside ISO/IEC 9899:1990 to pretend
that a C compiler that predefines __cplusplus isn't lying.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Oct 9 '08 #70
Richard Heathfield wrote:
CBFalconer said:
>Richard Heathfield wrote:
>>James Kuyper said:

<snip>

QoI means doing more than the minimum requirement; it means
actually being useful to the user.
The most useful thing a C compiler could do on encountering
__cplusplus would be to #error That's C++. This is a C compiler.
Not so. We want the universal use in the header file.

No, we don't. We want a clear delineation between the two languages.
>I.e:

#ifdef __cplusplus
extern "C"
{
#endif
... normal header file ...
#ifdef __cplusplus
}
#endif

and now the module is callable from C and C++.

At the cost of introducing a syntax error into the C code, protected by the
flimsiest of defences.
Tell that to just about every platform's standard library writers and
give then a good laugh.

--
Ian Collins.
Oct 9 '08 #71
Richard Heathfield wrote:
>
If the code is legal C and legal C++, it will either be bad C, bad C++, or
both. Daft idea. Silly to pander to daft ideas. Harumph, etc.
This is your blinkered view, not fact. Some of us have good technical
reasons to compile some of our C with a C++ compiler.

--
Ian Collins.
Oct 9 '08 #72

"Keith Thompson" <ks***@mib.orgwrote in message
>In a typical implementation,
it makes sense to have a single "/usr/include/stdlib.h" file that's
usable by either C or C++ code, using the __cplusplus symbol to
differentiate. Yes, you could do it with two separate files, but then
you'd have to have either a different naming scheme or a different
header search path for the C and C++ compilers.
But why should the C be uglified with a C++ construct?

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

Oct 9 '08 #73
Malcolm McLean wrote:
>
"Keith Thompson" <ks***@mib.orgwrote in message
>In a typical implementation,
it makes sense to have a single "/usr/include/stdlib.h" file that's
usable by either C or C++ code, using the __cplusplus symbol to
differentiate. Yes, you could do it with two separate files, but then
you'd have to have either a different naming scheme or a different
header search path for the C and C++ compilers.
But why should the C be uglified with a C++ construct?
Because library writers want their headers to be useful?

How often do you read system headers?

--
Ian Collins.
Oct 9 '08 #74
"Malcolm McLean" <re*******@btinternet.comwrites:
"Keith Thompson" <ks***@mib.orgwrote in message
>>In a typical implementation,
it makes sense to have a single "/usr/include/stdlib.h" file that's
usable by either C or C++ code, using the __cplusplus symbol to
differentiate. Yes, you could do it with two separate files, but then
you'd have to have either a different naming scheme or a different
header search path for the C and C++ compilers.
But why should the C be uglified with a C++ construct?
For the reasons I stated above.

Implementations of the standard C headers are already quite ugly on
most systems.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Oct 9 '08 #75
Richard Heathfield wrote:
CBFalconer said:
>Richard Heathfield wrote:
>>James Kuyper said:

<snip>

QoI means doing more than the minimum requirement; it means
actually being useful to the user.

The most useful thing a C compiler could do on encountering
__cplusplus would be to #error That's C++. This is a C compiler.

Not so. We want the universal use in the header file.

No, we don't. We want a clear delineation between the two languages.
>I.e:
#ifdef __cplusplus
extern "C"
{
#endif
... normal header file ...
#ifdef __cplusplus
}
#endif

and now the module is callable from C and C++.

At the cost of introducing a syntax error into the C code,
protected by the flimsiest of defences.
No. Protected by the fact that the C standard (the present one,
for C99) specifies that the implementation must not define
__cplusplus. I believe that that name was picked only after
considering as many C compilers as possible, and it was determined
that the requirement would not conflict in any known extant C90
compilers.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.
Oct 10 '08 #76
Keith Thompson wrote:
"Malcolm McLean" <re*******@btinternet.comwrites:
>"Keith Thompson" <ks***@mib.orgwrote:
>>In a typical implementation, it makes sense to have a single
"/usr/include/stdlib.h" file that's usable by either C or C++
code, using the __cplusplus symbol to differentiate. Yes, you
could do it with two separate files, but then you'd have to
have either a different naming scheme or a different header
search path for the C and C++ compilers.

But why should the C be uglified with a C++ construct?

For the reasons I stated above.

Implementations of the standard C headers are already quite ugly
on most systems.
I see no C++ construct in:

#ifdef __cplusplus
/* something */
#endif

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.
Oct 10 '08 #77
Ian Collins wrote:
Richard Heathfield wrote:
>If the code is legal C and legal C++, it will either be bad C,
bad C++, or both. Daft idea. Silly to pander to daft ideas.
Harumph, etc.

This is your blinkered view, not fact. Some of us have good
technical reasons to compile some of our C with a C++ compiler.
Why? A C compiler is smaller, and more accurate for compiling C
code. No C++ compiler is needed.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.
Oct 10 '08 #78
CBFalconer wrote:
Ian Collins wrote:
>Richard Heathfield wrote:
>>If the code is legal C and legal C++, it will either be bad C,
bad C++, or both. Daft idea. Silly to pander to daft ideas.
Harumph, etc.
This is your blinkered view, not fact. Some of us have good
technical reasons to compile some of our C with a C++ compiler.

Why? A C compiler is smaller, and more accurate for compiling C
code. No C++ compiler is needed.
As I've posted before; I use C++ simulations of hardware to test driver
code. I use typedefs to integer types for registers when compiling in C
for target hardware and C++ classes when compiling as C++ on my
development host. The C++ classes are used to simulate the hardware
behaviour and interface with the test harness when the registers are
read from or written to.

If there was a way to do this in C, I would use C, but there isn't. The
utility of the technique more than justifies the compromises in the C code.

--
Ian Collins
Oct 10 '08 #79
Richard Heathfield wrote:
....
Do you know that one won't be released tomorrow, with such fantastic
compensating advantages that everyone flocks to it despite its strident
approach to __cplusplus?
I'd expect such a "strident approach" to be anti-correlated with the
attitudes needed to produce a compiler with "fantastic compensating
advantages".
Oct 10 '08 #80
CBFalconer said:
Richard Heathfield wrote:
>CBFalconer said:
<snip>
>>>
and now the module is callable from C and C++.

At the cost of introducing a syntax error into the C code,
protected by the flimsiest of defences.

No. Protected by the fact that the C standard (the present one,
for C99)
Chortle chortle chortle, chuckle chuckle, etc etc. Ha and, in fact, ha.
Etc, etc. </smile>

Furrfu, Chuck!

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Oct 10 '08 #81
On 9 Oct, 21:06, Ian Collins <ian-n...@hotmail.comwrote:
Richard Heathfield wrote:
If the code is legal C and legal C++, it will either be bad C, bad C++,or
both. Daft idea. Silly to pander to daft ideas. Harumph, etc.

This is your blinkered view, not fact. *Some of us have good technical
reasons to compile some of our C with a C++ compiler.
hallelujah!
Richard is inhabiting a bizzare parallel universe on this one

--
Nick Keighley

Oct 10 '08 #82
Ian Collins said:
Richard Heathfield wrote:
>>
If the code is legal C and legal C++, it will either be bad C, bad C++,
or both. Daft idea. Silly to pander to daft ideas. Harumph, etc.
This is your blinkered view, not fact.
NO, sir! It's my blinkered view, AND fact! :-)
Some of us have good technical
reasons to compile some of our C with a C++ compiler.
I've never heard a convincing reason for doing this - including P J
Plauger's reason. But of course I respect your choice. And so, it appears,
do implementers!

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Oct 10 '08 #83
Richard Heathfield wrote:
Ian Collins said:
>Richard Heathfield wrote:
>>If the code is legal C and legal C++, it will either be bad C, bad C++,
or both. Daft idea. Silly to pander to daft ideas. Harumph, etc.
This is your blinkered view, not fact.

NO, sir! It's my blinkered view, AND fact! :-)
>Some of us have good technical
reasons to compile some of our C with a C++ compiler.

I've never heard a convincing reason for doing this - including P J
Plauger's reason. But of course I respect your choice. And so, it appears,
do implementers!
What isn't convincing about my main reason?

--
Ian Collins
Oct 10 '08 #84
James Kuyper said:
Richard Heathfield wrote:
...
>Do you know that one won't be released tomorrow, with such fantastic
compensating advantages that everyone flocks to it despite its strident
approach to __cplusplus?

I'd expect such a "strident approach" to be anti-correlated with the
attitudes needed to produce a compiler with "fantastic compensating
advantages".
Just you wait, James - you'll eat your words when I finally release my
amazing super-duper C compiler... any century now.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Oct 10 '08 #85
Nick Keighley said:
On 9 Oct, 21:06, Ian Collins <ian-n...@hotmail.comwrote:
>Richard Heathfield wrote:
If the code is legal C and legal C++, it will either be bad C, bad
C++, or both. Daft idea. Silly to pander to daft ideas. Harumph, etc.

This is your blinkered view, not fact. Some of us have good technical
reasons to compile some of our C with a C++ compiler.

hallelujah!
Richard is inhabiting a bizzare parallel universe on this one
It's much sunnier over here. JOIN US!

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Oct 10 '08 #86
Ian Collins said:
Richard Heathfield wrote:
>Ian Collins said:
>>Richard Heathfield wrote:
If the code is legal C and legal C++, it will either be bad C, bad
C++, or both. Daft idea. Silly to pander to daft ideas. Harumph, etc.

This is your blinkered view, not fact.

NO, sir! It's my blinkered view, AND fact! :-)
>>Some of us have good technical
reasons to compile some of our C with a C++ compiler.

I've never heard a convincing reason for doing this - including P J
Plauger's reason. But of course I respect your choice. And so, it
appears, do implementers!
What isn't convincing about my main reason?
Well, I certainly wouldn't do it that way. If I have understood you
correctly, you're using one set of code for development, and a very
different set of code (and indeed a different language!) for testing.
Okay, I'm not going to say it was a bad decision, but it does go against
what I would consider to be good test design principles.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Oct 10 '08 #87
Richard Heathfield wrote:
Ian Collins said:
>Richard Heathfield wrote:
>>Ian Collins said:

Richard Heathfield wrote:
If the code is legal C and legal C++, it will either be bad C, bad
C++, or both. Daft idea. Silly to pander to daft ideas. Harumph, etc.
>
This is your blinkered view, not fact.
NO, sir! It's my blinkered view, AND fact! :-)

Some of us have good technical
reasons to compile some of our C with a C++ compiler.
I've never heard a convincing reason for doing this - including P J
Plauger's reason. But of course I respect your choice. And so, it
appears, do implementers!
What isn't convincing about my main reason?

Well, I certainly wouldn't do it that way. If I have understood you
correctly, you're using one set of code for development, and a very
different set of code (and indeed a different language!) for testing.
Not different code, same code, different types for some bits of hardware
along the lines of:

#if defined __cplusplus

struct StatusRegister
{
/* Handle writes
*/
StatusRegister& operator=( uint8_t );

/* Handle reads
*/
operator uint8_t() const;
};

#else

typedef uint8_t StatusRegister;

#endif

Although in practice I'd split the header into C and C++ versions.

All the rest of the code is unchanged. I adopted this technique to
avoid having code littered with ugly #ifded TEST block I've seen
elsewhere. I believe the code under test should be the code used in
production and that the code should be as free of conditional compiles
as possible. I hate conditional compile blocks, they destroy the flow
when reeding code.
Okay, I'm not going to say it was a bad decision, but it does go against
what I would consider to be good test design principles.
There's more than one level of testing. My unit tests don't use C++ for
the target code. Hardware registers are just a block of memory shared
by the target code and the test harness. The C++ trickery is used for
simulations.

--
Ian Collins
Oct 10 '08 #88
On 10 Oct, 09:35, Richard Heathfield <r...@see.sig.invalidwrote:
Ian Collins said:
Some of us have good technical
reasons to compile some of our C with a C++ compiler.

I've never heard a convincing reason for doing this - including P J
Plauger's reason. But of course I respect your choice. And so, it appears,
do implementers!
Here's one more reason (whether convincing or not, I don't know
but suspect you will find "not"). Choice and flexibility are
good things. I have seen run-time throughput of a program drop
as much as 10% merely by changing "-std=c89" to "-std=c99".
In all of the cases where this sort of thing happened, it
was easy enough to add more compiler flags to make the
performance difference negligible; my point is that I was
only able to perform those comparisons because the code
conformed to both standards. If I were so inclined, it
might prove interesting to compile the code as C++ and
compare the performance. If the code does not compile as
C++, then one can't even perform such an experiment.

Oct 12 '08 #89
On Oct 10, 12:29*pm, Richard Heathfield <r...@see.sig.invalidwrote:
Ian Collins said:
<snip>

[using C++ to emulate hardware]
Well, I certainly wouldn't do it that way. If I have understood you
correctly, you're using one set of code for development, and a very
different set of code (and indeed a different language!) for testing.
Okay, I'm not going to say it was a bad decision, but it does go against
what I would consider to be good test design principles.
I believe he's talking about using C++ to emulate hardware.
This means a large chunk of the software can be tested
without specialist hardware. And with superior debugging
facilities.

With really specialised hardware the hardware may not exist
when the software development starts.

Some peripherals may be expensive, power hungry physically large
or massive (I've worked with power amplifiers that filled a room).
--
Nick Keighley
Oct 12 '08 #90
Nick Keighley wrote:
On Oct 10, 12:29 pm, Richard Heathfield <r...@see.sig.invalidwrote:
>Ian Collins said:

<snip>

[using C++ to emulate hardware]
>Well, I certainly wouldn't do it that way. If I have understood you
correctly, you're using one set of code for development, and a very
different set of code (and indeed a different language!) for testing.
Okay, I'm not going to say it was a bad decision, but it does go against
what I would consider to be good test design principles.

I believe he's talking about using C++ to emulate hardware.
This means a large chunk of the software can be tested
without specialist hardware. And with superior debugging
facilities.

With really specialised hardware the hardware may not exist
when the software development starts.

Some peripherals may be expensive, power hungry physically large
or massive (I've worked with power amplifiers that filled a room).
In my case it was power supplies that can fill a room - with smoke if
you drive them incorrectly!

--
Ian Collins
Oct 12 '08 #91
On Sat, 4 Oct 2008 19:13:48 +0100, "Malcolm McLean"
<re*******@btinternet.comwrote:
<snip>
Now one good question is why use C at all when C++ is a near as makes no
difference a superset of it? However let's say that we decide that we want
to discourage people from using object-orientation, because of certain
drawbacks we see in the methodogy. A politically effective way of doing this
is to ban C++.

OK, so here's a fragment of our C program

void encrypt(unsigned char *data, size_t len)
{
int i;
May be unsafe/wrong depending on range of size_t.
for(i=0;i<len;i++)
data ^= 0xCC;
Constraint violation. Presumably you meant data[i].
}

A few weeks later, the terrible news come through. Our encryption has been
compromised. We need a beter method, and fast.
weeks? sci.crypt can do that for you in barely a minute or two.
So we dust off our Sedgewick and realise that there is somethign called the
RSA cryptosystem. This is very much better, and it is not too difficult to
implment, as long as you have a huge integer library. Well we've got one,
but it's in C++.

No problem. Change the file extension to .cpp, and drop in

void encrypt(unsigned char *data, size_t len)
{
bignum prime1(13);
bignum prime2(17);
bignum unfactorisable = prime1 * prime2;
Those numbers aren't nearly big enough to be secure. More to the
point, no numbers representable as integer literals (even long long)
on any likely implementation will be. Plus the 'naive' RSA encryption
primitive often shown in textbooks, just data up pubexpt mod modulus,
can be insecure in other ways. And even after you get a good design,
_coding_ secure crypto code in most environments requires techniques
not commonly used, or known, for ordinary code. So you are almost
always better off using an established crypto library, which are
available for both C and C++ among others, than writing your own.

In short, not a very good example for your case. <G>
/* (etc) */
}

Now we're back in business. Nothing else needs to be changed. We've dropped
in an emergency C++ bignum library and the code is now C++ and won't compile
under C, but that is small price for turning out our improved encryption on
time.
See above.
- formerly david.thompson1 || achar(64) || worldnet.att.net
Oct 13 '08 #92
On Oct 10, 10:06*am, Ian Collins <ian-n...@hotmail.comwrote:
Richard Heathfield wrote:
If the code is legal C and legal C++, it will either be bad C, bad C++,or
both. Daft idea. Silly to pander to daft ideas. Harumph, etc.

This is your blinkered view, not fact. *Some of us have good technical
reasons to compile some of our C with a C++ compiler.
And those reasons are?

Oct 14 '08 #93
Old Wolf wrote:
On Oct 10, 10:06 am, Ian Collins <ian-n...@hotmail.comwrote:
>Richard Heathfield wrote:
>>If the code is legal C and legal C++, it will either be bad C, bad C++, or
both. Daft idea. Silly to pander to daft ideas. Harumph, etc.
This is your blinkered view, not fact. Some of us have good technical
reasons to compile some of our C with a C++ compiler.

And those reasons are?
If you read my responses elsewhere (my last couple of responses to
Richard H.) in this thread, you'll see.

--
Ian Collins
Oct 14 '08 #94
On Oct 14, 4:24*pm, Ian Collins <ian-n...@hotmail.comwrote:
Old Wolf wrote:
On Oct 10, 10:06 am, Ian Collins <ian-n...@hotmail.comwrote:
Richard Heathfield wrote:
>If the code is legal C and legal C++, it will either be bad C, bad C++, or
both. Daft idea. Silly to pander to daft ideas. Harumph, etc.
This is your blinkered view, not fact. *Some of us have good technical
reasons to compile some of our C with a C++ compiler.
And those reasons are?

If you read my responses elsewhere (my last couple of responses to
Richard H.) in this thread, you'll see.
I guess you are referring to the following:
The first C code I ever built C as C++ as a device driver. In C,
hardware registers were typedefs to an integer type. In C++ the
register types were classes that simulated the hardware behaviour when
read a written. I still use this technique today for testing drivers.
Well: the first sentence doesn't even make sense,
so I don't know what you're talking about there.
From the rest of the paragraph it sounds like you
are taking the idea of a macro kludge to the extreme.
Instead of a
#define something some_debug_thing

you compile the source in a different language
where 'something' means 'some_debug_thing' !

I have a pretty dim view of a test environment
where you aren't even using the same language
as the live environment. Certainly qualifies
as 'stupid' in my book (Your mileage varies, obviously).
We also compiled application code as C++ to get stricter type checking,
but C compilers and lint have improved considerably in this area.
Also stupid. C has type checking rules. You should
conform to C type checking rules when writing C.
I suspect people who make this claim are just writing
dreadful code in the first place.

Oct 14 '08 #95
Old Wolf wrote:
On Oct 14, 4:24 pm, Ian Collins <ian-n...@hotmail.comwrote:
>Old Wolf wrote:
>>On Oct 10, 10:06 am, Ian Collins <ian-n...@hotmail.comwrote:
Richard Heathfield wrote:
If the code is legal C and legal C++, it will either be bad C, bad C++, or
both. Daft idea. Silly to pander to daft ideas. Harumph, etc.
This is your blinkered view, not fact. Some of us have good technical
reasons to compile some of our C with a C++ compiler.
And those reasons are?
If you read my responses elsewhere (my last couple of responses to
Richard H.) in this thread, you'll see.

I guess you are referring to the following:
>The first C code I ever built C as C++ as a device driver. In C,
hardware registers were typedefs to an integer type. In C++ the
register types were classes that simulated the hardware behaviour when
read a written. I still use this technique today for testing drivers.

Well: the first sentence doesn't even make sense,
so I don't know what you're talking about there.
From the rest of the paragraph it sounds like you
are taking the idea of a macro kludge to the extreme.
Instead of a
#define something some_debug_thing

you compile the source in a different language
where 'something' means 'some_debug_thing' !
Well it's pretty clear you either you don't understand the concept of a
simulation.
I have a pretty dim view of a test environment
where you aren't even using the same language
as the live environment. Certainly qualifies
as 'stupid' in my book (Your mileage varies, obviously).
You obviously don't understand testing. If you'd read the part you
snipped you'd have seen how we did our testing.
>We also compiled application code as C++ to get stricter type checking,
but C compilers and lint have improved considerably in this area.

Also stupid. C has type checking rules. You should
conform to C type checking rules when writing C.
I suspect people who make this claim are just writing
dreadful code in the first place.
Your English comprehension is either lacking of you are being
deliberately obtuse. Note the past tense.

--
Ian Collins
Oct 14 '08 #96
On 14 Oct, 08:03, Ian Collins <ian-n...@hotmail.comwrote:
Old Wolf wrote:
On Oct 14, 4:24 pm, Ian Collins <ian-n...@hotmail.comwrote:
Old Wolf wrote:
On Oct 10, 10:06 am, Ian Collins <ian-n...@hotmail.comwrote:
Richard Heathfield wrote:
>>>If the code is legal C and legal C++, it will either be bad C, bad C++, >>>or both. Daft idea. Silly to pander to daft ideas. Harumph, etc.
[...] you are taking the idea of a macro kludge to the extreme.
<snip>
[...] Certainly qualifies
as 'stupid' in my book (Your mileage varies, obviously).
Also stupid.
[...]
I suspect people who make this claim are just writing
dreadful code in the first place.
it's the attitude that "someone who doesn't do it the same way as me
is stupid" that gets up my nose. Unless he's trolling.

--
Nick Keighley
Oct 14 '08 #97
Ian Collins wrote:
>>
Well it's pretty clear you either you don't understand the concept of a
simulation.
You might want to work on your english - the above doesn't entirely make
sense. Remove the word "either" and it does.
>I have a pretty dim view of a test environment
where you aren't even using the same language
as the live environment.
You obviously don't understand testing.
huh? When you're developing road-safety harnesses for people carriers,
you don't test them out on APVs and Big Dippers.
>>We also compiled application code as C++ to get stricter type checking,
but C compilers and lint have improved considerably in this area.

Also stupid. C has type checking rules. You should
conform to C type checking rules when writing C.
Your English comprehension is either lacking of you are being
deliberately obtuse. Note the past tense.
So just to be clear, you're stating that you *used* to have good reason
to compile C as C++, but not any more?

Just trying to ensure the use of past tense is deobfuscated.
Oct 14 '08 #98
Mark McIntyre wrote:
Ian Collins wrote:
>>>
Well it's pretty clear you either you don't understand the concept of a
simulation.

You might want to work on your english - the above doesn't entirely make
sense. Remove the word "either" and it does.
English should be capitalised. The second "you" should also go.
>>I have a pretty dim view of a test environment
where you aren't even using the same language
as the live environment.
You obviously don't understand testing.

huh? When you're developing road-safety harnesses for people carriers,
you don't test them out on APVs and Big Dippers.
So how do you test the device drivers in that code before you have the
hardware? How do you simulate the behaviour of the system without
trashing a large number of people carriers?
>>>We also compiled application code as C++ to get stricter type checking,
but C compilers and lint have improved considerably in this area.

Also stupid. C has type checking rules. You should
conform to C type checking rules when writing C.
Your English comprehension is either lacking of you are being
deliberately obtuse. Note the past tense.

So just to be clear, you're stating that you *used* to have good reason
to compile C as C++, but not any more?
I said "We *also* compiled". Our reason was much the same as K&R's, our
C compiler didn't check prototypes correctly. Running that dogs
breakfast of a code base through the C++ compiler flushed out a lot of
bugs. The same would not have been true for well written code!

The code in question had been written by a novice who had just
discovered enums. He used them as function parameters without checking
them for valid values. He then passed inappropriate integer values to
these functions. Even today's C compilers would pass this code, but C++
compilers will not. The c++ compiler made a good "enum lint".

--
Ian Collins
Oct 14 '08 #99
Mark McIntyre wrote:
Ian Collins wrote:
>>
Well it's pretty clear you either you don't understand the
concept of a simulation.

You might want to work on your english - the above doesn't
entirely make sense. Remove the word "either" and it does.
In other words you want him to clearly write:

"Well it's pretty clear you you don't understand the
concept of a simulation."

:-)

BTW, English is always capitalized.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.
Oct 15 '08 #100

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

231 posts views Thread by Brian Blais | last post: by
33 posts views Thread by hermit_crab67 | last post: by
35 posts views Thread by ytrama | last post: by
14 posts views Thread by Mirko | last post: by
8 posts views Thread by Neha | last post: by
17 posts views Thread by sophia.agnes | last post: by
32 posts views Thread by alex.j.k2 | last post: by
reply views Thread by zhoujie | last post: by
reply views Thread by suresh191 | last post: by
1 post views Thread by Marylou17 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.