C/C++ guidelines

[Joachim Schmitz]

On Sun, 16 Sep 2007 12:29:17 +0200, "Peter J. Holzer"

Concerning...

Consider:

#include <stdio.h>

int main(void)
{
char *p = (char *) malloc(10);

return 0;
}

lcc-win32: "Missing prototype for 'malloc'.
Pelles C : "Missing prototype for 'malloc'".
gcc : "implicit declaration of function 'malloc'".


So at least the compilers *I* use issue useful warnings.

dropping the cast would produce at least 1 _additional_ diagnostic on your
and at least 1 diagnostic _on every other_ compiler.

Usually the missing prototype is a warning (which you elect to can ignore)
and the type mismatch an error (which you can't ignore)

 

[Peter J. Holzer]

Actually, I already found that habit (casting malloc's return value)
described as _good coding practice_.

I think it is bad coding practice. To me a cast is a big red warning
sign saying "I'm doing something here which isn't quite kosher, but I
know what I'm doing, trust me". When code is littered with a lot of such
warning signs, you get used to them and don't notice the places which
are really fishy.

Also, as I already wrote, if you get into the habit of plastering casts
everywhere in your code, whether they are necessary or not, you *will*
hide bugs. Consider:

int **p1, *p2, i;
/* lots of code here */
p2 = (int *)p1; /* oops */
i = *p2;

The line marked "oops" should probably be "p2 = *p1" or "p2 = p1" or
something like that, and the compiler would normally warn about that
simple error, but because of the cast it doesn't.

hp

 

[=?iso-2022-kr?q?=1B=24=29CHarald_van_D=0E=29=26=0F]

a diagnostic is not required by the standared for an implicit declared
function

It is not in C90, but it is in C99.

 

[Peter J. Holzer]

If you would like a helper function such as:

static inline int *alloc_int(void) {
return malloc(sizeof(int));
}

but are implementing it as a macro:

#define alloc_int() malloc(sizeof(int))

That's not the same. The function returns an (int *), but the macro
returns a (void *). In this case the cast is necessary, if the macro is
supposed to be a replacement for the function.

not casting the result means you can assign it to a float * without any
diagnostic. I will admit that this is not a very common case though.

But

float fp = (float *)alloc_int()

will suppress any diagnostic you might have gotten. So I still maintain
that habitually adding unnecessary casts is a bad programming practice
which hides errors.

hp

 

[Peter J. Holzer]

On Sun, 16 Sep 2007 12:29:17 +0200, "Peter J. Holzer"

... whether real, existing, and widely used compilers
issue useful warnings.
Consider:

[...]
lcc-win32: "Missing prototype for 'malloc'.
Pelles C : "Missing prototype for 'malloc'".
gcc : "implicit declaration of function 'malloc'".


So at least the compilers *I* use issue useful warnings.

Please read the message you were replying to again. I don't think you
understood it.

hp

 

[Flash Gordon]

Karl Heinze wrote, On 16/09/07 11:10:

Completely agree with you. Moreover, if C99 is actually required to
produce a warning in case of an implicit declared function (as you
claimed) this silly argument (in the C-FAQ) is completely disproved.

No it isn't because most compilers still do not implement C99 fully and
many compilers used by newbies do not warn by default even if they can
be made to with additional options.

Omitting the cast ensures a diagnostic, on many systems _as_used_
including the cast prevents any diagnostic being produced. Thus the best
advice is to omit the cast unless you have a *very* good reason go
against this, such as your customers will only pay you if the code
compiles as C++ and C.

 

[Richard Heathfield]

Karl Heinze said:

Actually, I already found that habit (casting malloc's return value)
described as _good coding practice_.

And there is a considerable body of opinion to the effect that Elvis
lives. That in itself does not convince me. Can you explain *why* you
consider casting malloc's return value to be good practice? What good
thing does it achieve, or what bad thing does it prevent?

 

[CBFalconer]

Consider:

#include <stdio.h>
int main(void) {
char *p = (char *) malloc(10);

return 0;
}

lcc-win32: "Missing prototype for 'malloc'.
Pelles C : "Missing prototype for 'malloc'".
gcc : "implicit declaration of function 'malloc'".

So at least the compilers *I* use issue useful warnings.

So far so good. But where is the 'bad cast detected' warning?

 

[CBFalconer]

Actually, I already found that habit (casting malloc's return value)
described as _good coding practice_.

No, it is actually dangerous, in that it will suppress warnings due
to failure to #include <stdlib.h>.

 

[=?iso-2022-kr?q?=1B=24=29CHarald_van_D=0E=29=26=0F]

That's not the same. The function returns an (int *), but the macro
returns a (void *). In this case the cast is necessary, if the macro is
supposed to be a replacement for the function.

Yes, that was my point.

But

float fp = (float *)alloc_int()

will suppress any diagnostic you might have gotten. So I still maintain
that habitually adding unnecessary casts is a bad programming practice
which hides errors.

Agreed. Unless you find yourself in one of those rare situations where
compatibility with a certain implementation that doesn't conform to the C
standard in this regard (whether pre-standard or C++) is a good idea,
there's usually no benefit in casting malloc's result.

 

[babuswift]

Hi groups,

I'm about to embark on a new project and for maximum portability we've
been asked to code it in the common subset of C and C++.

Can anyone suggest any good documents that might help us? Lists of
gotchas to avoid, that sort of thing?

TIA!

Robbie

 

[Army1987]

Ark Khasin wrote, On 16/09/07 02:40:
No. Since some code which is well formed in both languages will do
different things in the two languages. We have has some such examples
posted in comp.lang.c in the past week.

There is code which is well formed in both C90 and C99 which will
do different things in the two versions of the language, but I've
never heard anyone suggesting *not* to try to write code in their
common subset.

 

[Richard]

For maximum portability, write unit tests for all your code. Then you can
run the tests on each target platform.

What strange advice.

For _real_ portability (not just "tell our boss we are portable"
portability), you could configure a test server on each target platform. Run
the test suite each time you integrate, automatically on each platform.
Configure them to e-mail all the developers if the tests break on any
platform.

Yes, I've done this before...

Clearly not. Your advice had almost nothing to do with his question. His
questions was what tools/techniques to create a portable code base. Not
on how to do basic QA.

 

[Phlip]

What strange advice.

Define portability. I don't want to hear the definition "our boss told us to
be portable, so we will write on one platform, with one compiler, without
tests, and we will research which (char *)malloc expressions to write where.
When the time comes to actually port, we intend to be surprised, and
experience Integration Hell followed by a long bug hunt."

Clearly not. Your advice had almost nothing to do with his question. His
questions was what tools/techniques to create a portable code base. Not
on how to do basic QA.

My colleagues develop a dual-mode Makefile that works both inside VC++ and
on Linux. I share a Linux on Samba, point VC++ at the source, and develop.
Each time VC++ runs all the developer tests (not QA, not unit tests), they
all run on the Linux at the same time.

So is there some part of "I've done this before" you still don't understand?

 

[werasm]

Hi groups,

I'm about to embark on a new project and for maximum portability we've
been asked to code it in the common subset of C and C++.

I've found that using the GCC compiler and STL as at the time of C++98
is very portable. On the other hand We've only developed for ix86,
Power-PC and ARM architectures using operating systems VxWorks,
Linux and Windows, therefore I suppose I can't say its the most
portable.

Kind regards,

Werner

 

[Jerry Coffin]

Hi groups,

I'm about to embark on a new project and for maximum portability we've
been asked to code it in the common subset of C and C++.

The first thing you should do is talk to your management about setting
goals that are realistic, meaningful and useful. For truly maximum
portability, you should restrict yourself to a fairly small subset of C
with no floating point, etc. (e.g. a talking greeting card doesn't
generally include floating point hardware, and neither will a rad-hard
80286 for use in a satellite).

A practical goal should be measureable, and should carry a measurable
benefit, that outweights the cost. "Maximum portability" isn't
measureable, carries no measurable benefit, and the cost is extreme.

Right now, I think the cart has been placed squarely in front of the
horse -- the decision to restrict the language has been made with what
is clearly insufficient analysis or reason. Only after meaningful goal
has been set will it be possible to make such a decision -- and with a
meaningful goal in mind, the decision will most likely change as well.

 

[Chris Hills]

The first thing you should do is talk to your management about setting
goals that are realistic, meaningful and useful. For truly maximum
portability, you should restrict yourself to a fairly small subset of C
with no floating point, etc. (e.g. a talking greeting card doesn't
generally include floating point hardware, and neither will a rad-hard
80286 for use in a satellite).

It depends what sort of portability they want. It also depends on the
sort of projects , the targets and the compilers.

a theoretical language subset is pointless

 

[Richard]

Define portability. I don't want to hear the definition "our boss told us to
be portable, so we will write on one platform, with one compiler, without
tests, and we will research which (char *)malloc expressions to write where.
When the time comes to actually port, we intend to be surprised, and
experience Integration Hell followed by a long bug hunt."


My colleagues develop a dual-mode Makefile that works both inside VC++ and
on Linux. I share a Linux on Samba, point VC++ at the source, and
develop.

A makefile does nothing to make the code a working cross section which
is valid C and C++. Which is what the OP asked for.

Each time VC++ runs all the developer tests (not QA, not unit tests), they
all run on the Linux at the same time.

So what? What has this to do with the original question? Really. What?
This is something you have - it answers no questions at all about what
he should do - especially in the context of a common C/C++ code base.

So is there some part of "I've done this before" you still don't
understand?

Yes. Your original post. It had nothing to do with what was being asked
especially when considering in what NG it is being asked in.

 

[Jerry Coffin]

[ ... ]

It depends what sort of portability they want. It also depends on the
sort of projects , the targets and the compilers.

a theoretical language subset is pointless

My point precisely. You start by setting a concrete goal, and then you
pick the language necessary to meet that goal. Right now, they have a
nebulous goal, and have chosen a theoretical language subset, which is
(as you pointed out) pointless.

 

[Chris Hills]

[ ... ]

It depends what sort of portability they want. It also depends on the
sort of projects , the targets and the compilers.

a theoretical language subset is pointless

My point precisely. You start by setting a concrete goal, and then you
pick the language necessary to meet that goal. Right now, they have a
nebulous goal, and have chosen a theoretical language subset, which is
(as you pointed out) pointless.

SO what are the platforms/target MCU's or OS and probable compilers?