Re: Seeking computer-programming job (Sunnyvale, CA)

[John B. Matthews]

Potential for harm, perhaps. Actual harm, no. I read Lew's
claim as the latter.

Ah, I read the statement as a universal negative: No warning is
harmless; you inferred the equivalent obverse: all warnings are harmful.
Harm may be difficult to quantify, and I maintain that the measure of
harm requires some analysis. Whether a particular warning is ignored or
cured, the burden of documenting the decision falls to the programmer.
Stuart & Richard Heathfield informatively discuss a concrete example in
this thread.

 

[Kaz Kylheku]

John B. Matthews said:

Please explain the potential for harm in:

struct tm foo = {0};

that causes this message:

foo.c:6: warning: missing initializer
foo.c:6: warning: (near initialization for `foo.tm_min')

and which vanishes when the code is changed to:

struct tm foo = {0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0};

.... and then the DS9K compiler has a warning for this one:

foo.c:6: warning: silly initializer, use {0).

 

[Seamus MacRae]

Where code does lead to nuisance warnings [for instance where the design
constraints of foo will _always_ require it to be initialized to 0, and
there is a high expectation that foo will continually change during the life
of the code, so the first form of initialiation is desirable], a method for
coping with this is to annotate the code (at the point the warning would be
raised) to explain the warning and justify why it is appropriate to
disregard it.

Alternatively, one could avoid the issue entirely with struct tm *foo =
calloc(sizeof(struct tm)), albeit having to replace tm.bar with tm->bar
elsewhere in the code.

Some developers even have tools to automatically filter such warnings
(comparing the warnings of a new build with those expected for any build).

I expect this sounds like an awful lot of fuss for a great many programmers
- but for some it is a way of life!

How unfortunate.

 

[Seamus MacRae]

Stuart said:

[missing attribution, to Richard I think]

And of course this technique [designated initializers]
does depend on your having a C99
compiler (or a compiler that includes some C99 features).

Or avoiding C and using something much more robust like Ada ;-)

Now now... language wars > /dev/null please!

It's far, far too late for that my friend.

 

[Seamus MacRae]

No, I'm asking why you're whining

I am not whining, and your claim otherwise constitutes yet another
personal attack.

Moreover, none of this seems relevant to either Lisp or Java.

 

[Ben Bacarisse]

Firstly, the preferred idiom is:

struct tm *foo = calloc(sizeof *foo);

Nit-pick: I think you mean

struct tm *foo = calloc(1, sizeof *foo);

 

[Paul Donnelly]

I am not whining, and your claim otherwise constitutes yet another
personal attack.

Moreover, none of this seems relevant to either Lisp or Java.

Quite right. Thisi whining is completely irrelevant, and doesn't
constitute an argument in favor of either Java or Seamus MacRae. So why
do you feel so compelled to point out every single perceived slight?

Obviously it's because the argument isn't going your way and you wish to
distract everyone with some unrelated topic.

 

[Series Expansion]

That's because there are no rational arguments in favor of either Lisp
or Java. They both suck. Use Clojure, which combines the best of both
worlds.

You're kidding.

(Even Google is apparently in on the joke: the captcha it gave me to
post this was "scala"!)

 

[Series Expansion]

Kindergarten really has been a great time!!

Well, now your incoherence is satisfactorily explained: you are
apparently far too young to have mastered coherence yet.

 

[Series Expansion]

I don't think any computer language ever grant miraculous powers.

You have to recognize that

You have to recognize that taking a condescending tone does not
encourage others to listen to you.

for lisp, 'tokenizing' the code turns the code into lisp objects (more
or less).

Not relevant.

Isomorphic isn't identical,
Symbols are first class objects.

The claim made regarding gensyms cannot be correct unless the program
structure in memory (your abstract syntax tree) is not actually a tree
but a directed acyclic graph with undirected cycles. Since the parse
tree of any text source file will be a bona fide tree, it follows that
if the claim regarding gensyms is true, the two representations are
NOT isomorphic; conversely, if as you have claimed the representations
ARE isomorphic the gensym claim is bogus.

I'd like to see your proof, it sounds quite impressive.

It was in an earlier post of mine. More than one of them in fact; I
kept having to repeat it for the hard of hearing.

I think you could say that both statements are true.

No.

 

[Paul Foley]

It was in an earlier post of mine. More than one of them in fact; I
kept having to repeat it for the hard of hearing.

Your idea of "proof" seems to taken from Lewis Carroll: "what i tell
you three times is true"

 

[Moi]

John B. Matthews said:


Please explain the potential for harm in:

struct tm foo = {0};

that causes this message:

foo.c:6: warning: missing initializer foo.c:6: warning: (near
initialization for `foo.tm_min')

and which vanishes when the code is changed to:

struct tm foo = {0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0};

which has precisely the same meaning as the prior code *except that*, if
for some reason the definition of foo changes to add more fields, the
former code does not need to be changed, and is therefore superior.


Please explain *any* circumstance in which struct structname = {0};
justifies the diagnostic message (above) that GCC generates for it.

Mostly I agree with your position, but some compilers, by generating
rather silly warnings in some circumstances, make it very difficult to
agree with you completely.

Some warnings, like the one above can be a nuisance.
Another one which is mostly harmless is:

for (cnt=0; cp = fgets(buff, sizeof buff, fp); cnt++) {}

-->> warning: suggest parentheses around assignment used as truth value

Well, there *could* be cases where this warning is wanted.
I don't like excessive parentheses either.


AvK

 

[Seamus MacRae]

Seamus MacRae said:

Where code does lead to nuisance warnings [for instance where the
design
constraints of foo will _always_ require it to be initialized to
0, and there is a high expectation that foo will continually
change during the life of the code, so the first form of
initialiation is desirable], a method for coping with this is to
annotate the code (at the point the warning would be raised) to
explain the warning and justify why it is appropriate to
disregard it.

Alternatively, one could avoid the issue entirely with struct tm
*foo = calloc(sizeof(struct tm)), albeit having to replace tm.bar
with tm->bar elsewhere in the code.

Firstly, the preferred idiom is:

struct tm *foo = calloc(sizeof *foo);

Surely not? That dereferences an uninitialized pointer, thereby invoking
undefined behavior. Even though it doesn't read or write through it.

Secondly, although all-bits-zero does indeed represent 0.0 or NULL
on many platforms, it is not guaranteed by the C Standard so to do.

Have you ever seen a reasonably modern system where it wasn't? Then
again, dereferencing a bad pointer without actually reading or writing
through it doesn't tend to cause h/w exceptions on modern machines either.

In the meantime, though, assigning it {0} causes warnings, as you noted.

I've worked in environments like that, and found it quite workable.

Now I know why so much C software is crash-prone and generally buggy.

 

[Seamus MacRae]

Quite right.

Then please do shut up.

(I've deleted the personal attacks and other nonsense that cluttered
things up after your admission that I was right. It didn't seem worth
keeping or responding to.)

 

[Series Expansion]

Your idea of "proof" seems to taken from Lewis Carroll: "what i tell
you three times is true"

These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, Paul.

 

[Paul Donnelly]

Then please do shut up.

(I've deleted the personal attacks and other nonsense that cluttered
things up after your admission that I was right. It didn't seem worth
keeping or responding to.)

"Please, everyone pay attention to me! Look how abused I am. "

You're not fooling anybody, but I do believe you're the most
irredeemably boring troll I've ever seen. Kudos to your tenacity which
has kept me following this thread thus far, but no points for style.

I'll save you some bandwidth and ask everyone to please note the
personal attacks in my post here.

 

[java.oke]

Well, now your incoherence is satisfactorily explained: you are
apparently far too young to have mastered coherence yet.

(To the public, other than "Too Serious of an Expansion"

You see, if somebody is so full of himself to ignore the possibility
of self-criticism, it's simply too easy to trap them in any kind of
self-revelatory naive trap.

Anyway, thanks go to "Serious Expansion" for allowing me to
demonstrate you this kind of lesson.

-JO

 

[Seamus MacRae]

Richard Heathfield wrote:
[snip]

Stop attacking me.

Surely not! The sizeof operator does not evaluate its operand

It must at least partly do so, in order to know what size of thing *foo
is referring to.

Have you ever seen a reasonably modern system that had precisely the
same architecture in all respects as the most common architecture
of the previous generation? There are real systems where NULL is
not all-bits-zero

Yes, but are any of them in widespread use?

and real systems where 0.0 is not all-bits-zero.

Not IEEE754-compatible ones.

In the absence of a guarantee from Silicon Valley that this will
never, ever, ever happen again, I will continue to assume the worst
when writing code that I need to be maximally portable.

And I will continue to use Java when writing code that I need to be
maximally portable. C is for systems-level stuff now.

Strawman argument.

Do not personally attack me or accuse me of intellectually dishonest
behavior again. You have been warned.

Now I know why so much C software is crash-prone and generally
buggy.

Yes, it's at least partly because there are people who don't know
[rest of personal attacks deleted]

Stop attacking me.

You've said your piece and I've said mine. Move on.

 

[Seamus MacRae]

"Please, everyone pay attention to me! Look how abused I am. "

You're not fooling anybody

I'm not trying to fool anybody. I'm trying to get one of two things done:
a) Rerail this discussion to be about Java and Lisp again, or else
b) Shut it down entirely.

I do not want the public commentary about me-personally to continue.
Have I made myself clear?

I do believe you're the most irredeemably boring troll I've ever
seen. [rest of post deleted unread]

More personal attacks and zero on-topic substance. Please go away.

 

[Lars Enderin]

You will not escape those "personal attacks" until you stop writing
ill-informed nonsense, which seems to be never, given your track record.
Your problem with "sizeof *foo" is just one of your most glaring errors.
You have to realize that you do make errors.