Parsing a string

[Eric Sosman]

I want to make some things clear here before I speak more. There are 2
things you can learn from clc or any programming language newsgroup:

(1) Genuine/Proper/Good/Real/(fill your favorite word here) way of
programming in that language. Its only because of clc that I *always*
compile with -ansi (-std=c99) -pedantic -Wall -Wextra flags to gcc.

(2) Style of Programming: This is personal. e.g. Richard Heathfield
considers it as a bug if his function contains more than one return
statement, while others consider having return statements at 3/4/N places
in the functions as a fine idea.


So, what you are saying belongs to (1) or (2) ? I think its (1) but I
want to be sure.

"You pays your money and you takes your choice" is a colloquialism
meaning "(2)."

 

[Keith Thompson]

(BTW why is it that uninitialized static variables are generally all set to
zero, rather than some completely arbitrary bit-pattern that is different on
every run?)

That's at least partly because, on many systems, that happens to
be the easiest thing to do.

An executable file might contain an indication that the program
needs N bytes of uninitialized static data. When the executable is
loaded, the operating system can just allocate N bytes of data and
set it all to zero; that's typically a simple and fast thing to do
(it might not even require a loop).

This advantage goes away if floating-point zeros and null pointers
aren't represented as all-bits-zero, which is perhaps part of the
reason that they are represented that way on most systems. But a
system where a null pointer is represented as 0xFFFFFFFF does have
to store that 0xFFFFFFFF representation in any uninitialized static
pointer objects, even if it would be more convenient to do it wrong
by setting them to all-bits-zero.

 

[Ian Collins]

OK. I just see it differently; ie. as providing a known default value in a
program structure that might be subject to change, or that might have an
as yet unperceived bug. So it's just good practice.

But your unit tests would catch that, wouldn't they?

 

[FredK]

That's at least partly because, on many systems, that happens to
be the easiest thing to do.

An executable file might contain an indication that the program
needs N bytes of uninitialized static data. When the executable is
loaded, the operating system can just allocate N bytes of data and
set it all to zero; that's typically a simple and fast thing to do
(it might not even require a loop).

Demand zero stuff is usually very cheap.

This advantage goes away if floating-point zeros and null pointers
aren't represented as all-bits-zero, which is perhaps part of the
reason that they are represented that way on most systems. But a
system where a null pointer is represented as 0xFFFFFFFF does have
to store that 0xFFFFFFFF representation in any uninitialized static
pointer objects, even if it would be more convenient to do it wrong
by setting them to all-bits-zero.

Non-zero "poison" patterns are something frequently used in debugging
(something other than all bits on or off) - very useful for finding use of
uninitialized fields in stuff allocated from a pool.

 

[Mark Wooding]

(BTW why is it that uninitialized static variables are generally all set to
zero, rather than some completely arbitrary bit-pattern that is different on
every run?)

Because the standard says so (6.7.8p10):

[#10] If an object that has automatic storage duration is
not initialized explicitly, its value is indeterminate. If
an object that has static storage duration is not
initialized explicitly, then:

-- if it has pointer type, it is initialized to a null
pointer;

-- if it has arithmetic type, it is initialized to
(positive or unsigned) zero;

-- if it is an aggregate, every member is initialized
(recursively) according to these rules;

-- if it is a union, the first named member is initialized
(recursively) according to these rules.

(Historically, the data space of a process was zero-initialized because
(a) it had to be initialized to something for security -- otherwise your
program might trip over some other user's secrets, (b) using all-bits-
zero was easier and considered more useful than any other pattern, and
(c) all-bits-zero just happened to initialize stuff as describe above on
the early system(s) in question, and programs made use of this fact.)

-- [mdw]