OT: Requesting C advice

Mike McCarty Mike.McCarty at sbcglobal.net
Mon Jun 4 21:40:22 UTC 2007


Matthew Saltzman wrote:
> Sorry, readers, this is getting rather long and still pretty OT.  Les, 
> if you want to continue, perhaps we should take it offline?

[snip]

> Note I said "demonstrate", not "prove".  For a math teacher, there's an 
> important distinction 8^).

Sure is!

[snip]

>> state (most do by design).  Thus if the compiler doesn't initialize
> 
>                                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 
>> memory, and the memory where the code is placed has not been used in a
> 
>   ^^^^^^
> 
> But this is the key: In the absence of an explicit initializer, an 
> ISO-compliant compiler *must* generate code to properly initialize 
> static memory (not automatic or dynamic memory) just as if the default 
> initializer had been provided explicitly.

Umm, more correctly, the implementation must provide a way for
that to happen. This code may or may not be generated by the
compiler, and it may or may not be part of the program. It may,
for example, be part of the program loader.

[snip]

> If you don't believe me, how about the Usenet News comp.lang.c FAQ?

This is irrelevant. What is relevant is the Standard.

[snip]

> As I said, even if you are guaranteed that initialization will take 
> place, it can't hurt and might help readability to do it explicitly anyway.

It might. It might also mean that a program which runs in a
non-conforming implementation could restart more quickly :-)

It also might make the program too big to fit into memory.

Mike
-- 
p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
Oppose globalization and One World Governments like the UN.
This message made from 100% recycled bits.
You have found the bank of Larn.
I can explain it for you, but I can't understand it for you.
I speak only for myself, and I am unanimous in that!




More information about the fedora-list mailing list