Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > C/C++ guidelines

Reply
Thread Tools

C/C++ guidelines

 
 
Joachim Schmitz
Guest
Posts: n/a
 
      09-16-2007
"Joachim Schmitz" <(E-Mail Removed)> schrieb im Newsbeitrag
news:fcivet$jso$(E-Mail Removed)...
> "Harald van D?k" <(E-Mail Removed)> schrieb im Newsbeitrag
> news:fciv02$qn5$(E-Mail Removed)1.ov.home.nl...
>> On Sun, 16 Sep 2007 11:48:29 +0200, Joachim Schmitz wrote:
>>> "Harald van D?k" <(E-Mail Removed)> schrieb im Newsbeitrag
>>> news:fcj2k0$830$(E-Mail Removed)1.ov.home.nl...
>>>> On Sun, 16 Sep 2007 11:34:38 +0200, Joachim Schmitz wrote:
>>>>> a diagnostic is not required by the standard for an implicit declared
>>>>> function
>>>>
>>>> It is not in C90, but it is in C99.
>>> Chapter and Verse?

>>
>> C99 has no implicit function declarations.
>>
>> 6.5.1p2:
>> "An identifier is a primary expression, provided it has been declared as
>> designating an object (in which case it is an lvalue) or a function (in
>> which case it is a function designator). 76)"

>
>
>> Footnote 76:
>> "Thus, an undeclared identifier is a violation of the syntax."

> OK, thanks. Are footnotes normative?

No, they are not, the foreword, paragraph 6 states that they are for
information only


 
Reply With Quote
 
 
 
 
Keith Thompson
Guest
Posts: n/a
 
      09-16-2007
"Wade Ward" <(E-Mail Removed)> writes:
[...]
> Mr. Thompson has called me a troll,

[...]

I don't believe I have.

--
Keith Thompson (The_Other_Keith) http://www.velocityreviews.com/forums/(E-Mail Removed) <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
 
 
 
=?iso-2022-kr?q?Harald_van_D=0E=29=26=0Fk?=
Guest
Posts: n/a
 
      09-16-2007
On Sun, 16 Sep 2007 12:10:30 +0200, Joachim Schmitz wrote:
> "Harald van D?k" <(E-Mail Removed)> schrieb im Newsbeitrag
> news:fciv02$qn5$(E-Mail Removed)1.ov.home.nl...
>> C99 has no implicit function declarations.
>> 6.5.1p2:
>> "An identifier is a primary expression, provided it has been declared
>> as designating an object (in which case it is an lvalue) or a function
>> (in which case it is a function designator). 76)"

>
>> Footnote 76:
>> "Thus, an undeclared identifier is a violation of the syntax."

> OK, thanks. Are footnotes normative?


No, they are not. However, this footnote is a correct conclusion from the
normative text that references it.

>> Using malloc without a proper declaration would result in a warning
>> message from my compiler even in C90 mode. If yours doesn't at least
>> have an option to warn about implicit function declarations, though,
>> then yes, it would be better for you not to cast malloc's result. For
>> me, it wouldn't matter.

> The compilers I use warn too (with appropriate warning level set), but
> they are not required too and that's the whole point.


Oh? I thought the point was so that you, the programmer, can figure out
where your bugs are. If someone else wants to compile the code with a
compiler that doesn't warn on implicit malloc declarations, they can,
because you've already made sure to include <stdlib.h> after the warnings
you were getting.
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      09-16-2007
Karl Heinze <nomail@invalid> writes:
> On Sun, 16 Sep 2007 11:23:37 +0200, "Peter J. Holzer"
> <(E-Mail Removed)> wrote:
>> There is STILL something wrong with casting malloc's return value:
>> It is unnecessary and clutters up the code.
>>

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


What's good about it?

--
Keith Thompson (The_Other_Keith) (E-Mail Removed) <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
Jim Langston
Guest
Posts: n/a
 
      09-16-2007
"Wade Ward" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed). ..
>
>
> "Keith Thompson" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>> Robbie Marshall <(E-Mail Removed)> writes:
>>> 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?

>>
>> Consider programming in C90 and making sure not to accidentally use a
>> C++ compiler. You can enforce this with:
>>
>> #ifdef __cplusplus
>> #error "Use a C compiler, not a C++ compiler"
>> #endif

> Keith's right here.
>
> Mr. Thompson has called me a troll, a curious appellation for a large,
> jellyfilled donut whose first german language book was Gödel, Escher,
> Bach. Was ist die Abbildung an Bloop, Floop, und Gloop?


Ummm.. how do you take his response as him calling you a troll? His
response was appropriate and gave some good advice.

Seeing how you seem to think that's calling you a troll makes me think that
maybe you are.


 
Reply With Quote
 
Joachim Schmitz
Guest
Posts: n/a
 
      09-16-2007

"Karl Heinze" <nomail@invalid> schrieb im Newsbeitrag
news(E-Mail Removed)...
> On Sun, 16 Sep 2007 12:10:30 +0200, "Joachim Schmitz"
> <(E-Mail Removed)> wrote:
>
>>
>> The compilers I use warn too (with appropriate warning level set), but
>> they
>> are not required too and that's the whole point.
>>

> Clearly the "problem" is NOT the usage of a cast (which is required in
> C++ !) but forgetting to include <stdlib.h>.

What has C++ got to do with this?

Indeed the probem is the missing prototype, but C-Compilers don't have to
warn about that and they can't warn about type conversion if there's a cast,
so "defensive programming" mandates not to use the cast.
The cast _may_ hide a bug, not using it _will_ prevent it.


 
Reply With Quote
 
Peter J. Holzer
Guest
Posts: n/a
 
      09-16-2007
On 2007-09-16 09:41, Joachim Schmitz <(E-Mail Removed)> wrote:
> "Joachim Schmitz" <(E-Mail Removed)> schrieb im Newsbeitrag
> news:fcitgn$h1f$(E-Mail Removed)...
>> "Peter J. Holzer" <(E-Mail Removed)> schrieb im Newsbeitrag
>> news:(E-Mail Removed)...
>>> On 2007-09-16 01:36, Karl Heinze <nomail@invalid> wrote:
>>>> On Sat, 15 Sep 2007 18:14:30 -0700, "Chris Thomasson"
>>>><(E-Mail Removed)> wrote:
>>>>> http://c-faq.com/malloc/mallocnocast.html
>>>>>
>>>> Thanx. Though I don't buy in that "argument".

[...]
>>>> At least lcc-win32 DOES warn you: "Missing prototype for 'malloc'.
>>>>
>>>> Same with Pelles C: "Missing prototype for 'malloc'".
>>>>
>>>> Same with gcc: "implicit declaration of function 'malloc'".
>>>
>>> Once upon a time most compilers didn't warn about missing prototypes but
>>> they did warn about conversions from int to a pointer. In these days not
>>> casting malloc was the most reliable way to catch a missing declaration
>>> of malloc.

>> Because they are required to do diagnose the conversionm and free to do do
>> the same with the missing prototype

> oops, spelling/typing problems, sorry...
> Because they are required to diagnose the conversion and free to diagnose
> the missing prototype


Actually, most of the compilers I was thinking about were pre-ANSI, so
they weren't required to do anything. It's probably the other way
around: Because most compilers already warned about int<->pointer
conversions the ANSI committee made that warning mandatory and because
most compilers did not warn about implicitely declared functions and a
lot of existing code relied on that they had to allow that.

As an aside, GCC still isn't able to warn about a missing prototype.
Today this isn't much of a problem since old-style declarations have
gone out of fashion, but when system header files still contained lots
of them, there was no sane combination of warning flags:

* -Wimplicit only warned if there was no declaration of malloc at
all. If the declaration was "void *malloc()", it wouldn't warn
about "p = malloc(10)", even though int and size_t might be of
different sizes.

* -Wstrict-prototypes was unusable: It would produce hundreds of
warnings for the system header files.

* -Wmissing-prototypes does something completely different.

Back to the topic: The standard doesn't require any specific form of a
diagnostic. A compiler which always prints "Warning: This program may
contain constraint violations" would be conforming, but of appallingly
bad quality. So for this discussion, I think it is completely irrelevant
whether something is a constraint violation or not. What is relevant is
whether real, existing, and widely used compilers issue useful warnings.

hp

--
_ | Peter J. Holzer | I know I'd be respectful of a pirate
|_|_) | Sysadmin WSR | with an emu on his shoulder.
| | | (E-Mail Removed) |
__/ | http://www.hjp.at/ | -- Sam in "Freefall"
 
Reply With Quote
 
=?iso-2022-kr?q?=1B=24=29CHarald_van_D=0E=29=26=0Fk?=
Guest
Posts: n/a
 
      09-16-2007
On Sun, 16 Sep 2007 03:26:58 -0700, Keith Thompson wrote:
> Karl Heinze <nomail@invalid> writes:
>> On Sun, 16 Sep 2007 11:23:37 +0200, "Peter J. Holzer"
>> <(E-Mail Removed)> wrote:
>>> There is STILL something wrong with casting malloc's return value: It
>>> is unnecessary and clutters up the code.
>>>

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

>
> What's good about it?


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))

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.
 
Reply With Quote
 
Karl Heinze
Guest
Posts: n/a
 
      09-16-2007
On Sun, 16 Sep 2007 12:29:17 +0200, "Peter J. Holzer"
<(E-Mail Removed)> wrote:

Concerning...
>
> ... whether real, existing, and widely used compilers
> issue useful warnings.
>


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.


K. H.

--

E-mail: info<at>simple-line<Punkt>de
 
Reply With Quote
 
=?iso-2022-kr?q?=1B=24=29CHarald_van_D=0E=29=26=0Fk?=
Guest
Posts: n/a
 
      09-16-2007
On Sat, 15 Sep 2007 23:16:27 -0400, CBFalconer wrote:
> Phlip wrote:
>> Wade Ward wrote:
>>
>>>> Yes, I've done this before...

>>
>>> I think the common subset of c and c++ is empty, because if you do
>>> malloc then yikes and if you don't malloc, well that's not much of a
>>> program is it.

>>
>> Actually I haven't done the Common Subset thing.
>>
>> But (char*)malloc(..) is well-formed C++ (with appropriate substitution
>> for ...). Don't sweat the details; portability is up to your
>> compiler(s).

>
> And it is execreble dangerous coding in C.


Nonsense. In the cases where the code is broken with the cast, it's also
broken without the cast, and the argument about hiding a missing
inclusion of <stdlib.h> only applies if the programmer uses a compiler
that won't warn on implicit function declarations. Mine does, so how
would it be dangerous for me to cast the result of malloc?
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Case Gallery rules and Guidelines Silverstrand Case Modding 0 06-20-2005 11:38 PM
Portable Coding Guidelines? Roger VHDL 0 12-17-2004 07:33 PM
Code Guidelines JIT ASP .Net 2 11-02-2004 06:57 AM
Is WPS compatible with Smart client as defined in WISPr guidelines nsmurthy Wireless Networking 0 08-13-2004 10:23 AM
VHDL Coding Guidelines Francisco Camarero VHDL 1 07-08-2003 08:17 PM



Advertisments