«

"Joachim Schmitz" <> schrieb im Newsbeitrag
news:fcivet$jso$...
> "Harald van D?k" <> schrieb im Newsbeitrag
> news:fciv02$qn5$...
>> On Sun, 16 Sep 2007 11:48:29 +0200, Joachim Schmitz wrote:
>>> "Harald van D?k" <> schrieb im Newsbeitrag
>>> news:fcj2k0$830$...
>>>> 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

"Wade Ward" <> writes:
[...]
> Mr. Thompson has called me a troll,
[...]

I don't believe I have.

--
Keith Thompson (The_Other_Keith) kst- <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"

On Sun, 16 Sep 2007 12:10:30 +0200, Joachim Schmitz wrote:
> "Harald van D?k" <> schrieb im Newsbeitrag
> news:fciv02$qn5$...
>> 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.

Karl Heinze <nomail@invalid> writes:
> On Sun, 16 Sep 2007 11:23:37 +0200, "Peter J. Holzer"
> <hjp-> 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) kst- <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"

"Wade Ward" <> wrote in message
news:. ..
>
>
> "Keith Thompson" <kst-> wrote in message
> news:...
>> Robbie Marshall <> 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.

"Karl Heinze" <nomail@invalid> schrieb im Newsbeitrag
news...
> On Sun, 16 Sep 2007 12:10:30 +0200, "Joachim Schmitz"
> <> 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.

On 2007-09-16 09:41, Joachim Schmitz <> wrote:
> "Joachim Schmitz" <> schrieb im Newsbeitrag
> news:fcitgn$h1f$...
>> "Peter J. Holzer" <hjp-> schrieb im Newsbeitrag
>> news:slrnfeptgp.4b3.hjp-...
>>> On 2007-09-16 01:36, Karl Heinze <nomail@invalid> wrote:
>>>> On Sat, 15 Sep 2007 18:14:30 -0700, "Chris Thomasson"
>>>><> 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.
| | | |
__/ | http://www.hjp.at/ | -- Sam in "Freefall"

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"
>> <hjp-> 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.

On Sun, 16 Sep 2007 12:29:17 +0200, "Peter J. Holzer"
<hjp-> 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

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?