gcc knows about malloc()

[Walter Roberson]

I've concluded that readers in c.l.c, if any, who know of the
optimization, or
even understood what it is, were too distracted by my peculiar casting
of
malloc to attend to the interesting issue.

Ummm, no, the "interesting issue" was one which is well known to
many and so not worth thinking about. "gcc" and "weird and
non-standard C compilers" would appear in the same category
of most computing thesaurii . Is it a profitable use of our time
to catelogue all of gcc's oddities?

 

[James Dow Allen]

Ummm, no, the "interesting issue" was one which is well known to
many and so not worth thinking about.

What it be rude to ask you which "interesting issue" *you* are talking
about? I erred greatly by introducing many unrelated issues in a
single post, but I've yet to see an acknowledgement that *anyone*
even *noticed* gcc's peculiar optimization demonstrated in my code
sample (1), let alone that that behavior "is well known to many."

If only gcc does this optimization, I think it's still on-topic here,
as relevant to what C compilers may or should do.

James Dow Allen

 

[Walter Roberson]

Walter Roberson wrote:

What it be rude to ask you which "interesting issue" *you* are talking
about? I erred greatly by introducing many unrelated issues in a
single post, but I've yet to see an acknowledgement that *anyone*
even *noticed* gcc's peculiar optimization demonstrated in my code
sample (1), let alone that that behavior "is well known to many."

Oh, I noticed you pointing out the executation difference, and
confirmed it on a local copy of gcc, but gcc has about the same
relationship to code as university students have proverbably had to
beer: afterwards, someone has to clean up after the pranks and vomit.

If only gcc does this optimization, I think it's still on-topic here,
as relevant to what C compilers may or should do.

Hmmm, possibly. I would need to examine the sequence more carefully
to see for myself whether any constraint had been violated by the
program.

 

[Keith Thompson]

What it be rude to ask you which "interesting issue" *you* are talking
about? I erred greatly by introducing many unrelated issues in a
single post, but I've yet to see an acknowledgement that *anyone*
even *noticed* gcc's peculiar optimization demonstrated in my code
sample (1), let alone that that behavior "is well known to many."

If only gcc does this optimization, I think it's still on-topic here,
as relevant to what C compilers may or should do.

Any compiler is allowed to use knowledge of functions in the standard
library. I've also seen gcc transform this:
printf("hello, world\n");
to this:
puts("hello, world");

They're both reasonably cool optimizations, but I think the fact that
they're allowed is well known, and there's really not all that much
more to say about them in the context of the C language.
(comp.compilers or one of the gnu.gcc.* newsgroups would be an
appropriate place to discuss the mechanics of how these optimizations
are done.)

 

[Mark McIntyre]

If only gcc does this optimization, I think it's still on-topic here,
as relevant to what C compilers may or should do.

I noticed this, but its not topical here since this group discusses
ISO C, not how a given compiler implements something under the hood.

If ever you find yourself looking at intermediate or assembler files.,
you need to take the discussion to a gcc group or whatever.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

 

[Keith Thompson]

I noticed this, but its not topical here since this group discusses
ISO C, not how a given compiler implements something under the hood.

If ever you find yourself looking at intermediate or assembler files.,
you need to take the discussion to a gcc group or whatever.

The fact that compilers in general are allowed to perform this
optimization is topical. The fact that gcc in particular does so is
not (though I don't object to mentioning it in passing).

 

[Mark McIntyre]

The fact that compilers in general are allowed to perform this
optimization is topical. The fact that gcc in particular does so is
not
agreed

(though I don't object to mentioning it in passing).

me neither, which is why I didn't comment on it the first time.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

 

[ena8t8si]

No, the undefined behavior is caused by calling malloc() without a
visible prototype.

Keith, your postings keep saying prototype, but what you
mean is declaration. It's not necessary that there be a
prototype for malloc, only a declaration.

...

Undefined behavior.

By converting malloc (a function name which has been implicitly
converted to a pointer-to-function) to type (void *(*)(), you're
trying to avoid the problem with malloc()'s return type,

The behavior is undefined, but that's because the identifier
malloc hasn't been declared (or because the implicit declaration
doesn't match the definition in the case of C90). There is nothing
in the conversion in and of itself that causes undefined behavior.
An implementation that gives a suitable definition for what
happens in the case of undeclared identifiers would have no
problem with undefined behavior for this code (assuming, as
noted elsewhere, that the TWELVE_MILLION argument
is such that it gets passed as a size_t).

 

[Keith Thompson]

Keith, your postings keep saying prototype, but what you
mean is declaration. It's not necessary that there be a
prototype for malloc, only a declaration.

Good point.

With a visible declaration that's not a prototype (i.e., that doesn't
specify the parameter type), a call with an argument that's not of
type size_t (or a type that promotes to size_t) will still invoke
undefined behavior.

The behavior is undefined, but that's because the identifier
malloc hasn't been declared (or because the implicit declaration
doesn't match the definition in the case of C90). There is nothing
in the conversion in and of itself that causes undefined behavior.

Right, and I didn't mean to imply otherwise. The cast is *intended*
to avoid the problem the problem with UB, but it doesn't.

An implementation that gives a suitable definition for what
happens in the case of undeclared identifiers would have no
problem with undefined behavior for this code (assuming, as
noted elsewhere, that the TWELVE_MILLION argument
is such that it gets passed as a size_t).

Well, an implementation is free to define the behavior of anything
that's undefined behavior according to the standard.