Stylistic questions on UNIX C coding.

[Seebs]

You have again ignored this completely.

I looked at it a bit, and it didn't seem to say much.

Further, I posted an
explanation of the difference between this
postincrement-where-it-isn't-appropriate issue and you for loop:

,----
| since none of the increments which are supposed to be performed by
| the code quoted above are technically useless, meaning, what I
| called 'overstepping the loop counter' does not occur here.
`----

Because the test is basically while (i < N), i needs to be incremented
until i == N, while in order to test i != 0, no post-decrement down to
(unsigned)-1 needs to be performed. You still claim that both would be
identical while they are clearly not identical and anyone with sufficient
knowledge in C to understand the code at all can be expected to
understand the difference.

I think we've gotten to a point where we need a couple of code fragments
in view.

Could you show us the two tests you're comparing, which you say are not
identical, and which someone else apparently said were identical? Ideally,
a short loop using each to, say, print the numbers from 9 to 0 or something
like that.

-s

 

[Rainer Weikusat]

I looked at it a bit, and it didn't seem to say much.

Cutting something away from a text and than making a summary statement
about what had been cut away is a standard tactic.

 

[Keith Thompson]

Whatever your motivation for acting in this way might be, for as long
as you are basically attaching unrelated statements to random parts of
heavily redacted variants of texts I originally wrote, any attempt at
a 'discussion' is a waste of bandwidth.

I have been honestly trying to understand what you've been saying.
If you're unwilling either to help or to answer direct questions,
then yes, this is a waste of bandwidth.

Bye.

 

[Seebs]

Cutting something away from a text and than making a summary statement
about what had been cut away is a standard tactic.

It was more informative than what you did here -- which is completely
ignore the technical question I asked in favor of commenting on "tactics".

If all you want to do is fight, please go to alt.flame. If you want to
talk about C, how about you answer my technical question:

What are these two loops which you are comparing? There's been enough
different loops in this thread that I have no idea which ones you're
referring to.

-s

 

[Richard Bos]

As CS Lewis said, the first pot, which would prove its maker a genius
if it were the first pot ever made, would prove him a dunce if it came
after many millenia of pot-making.

That's a good one; I'll try to remember it.
FWIW, the K&R bit was intentional, to make the joke more obvious. Not
obvious enough for some, but apparently I either overestimated the
volume in the ng, or underestimated the mass. My bad.[/QUOTE]

No, as should by now be clear, you underestimated the number of people
who have made such arguments in this newsgroup in all seriousness. I
didn't understand it was a joke, not because it wasn't jokey enough, but
because too many people before you have said similar things with no
jocular intent at all.

Richard

 

[Richard Bos]

Are there any real-world C implementations that take advantage of this
permission? Specifically, is there a C compiler that accepts
additional forms of constant expressions in (what it claims to be)
conforming mode?

And why is that permission there in the first place? What benefit
does it really provide beyond the existing permission to provide
extensions?

IYAM, the only benefit of this permission, as of the "other forms of
main()" one, is entirely political.

Richard

 

[Richard Bos]

But if you had typed it this way:

if (7 = x)

The compiler will throw an error.

So now you come to rely on this to prevent mistypes.

And then you write what should be

if (x == y)

and you switch the operands for safety, so you write

if (y = x)

and because you have got completely out of the habit of paying attention
to what you actually write (because, after all, if you had made a typo
the compiler would have thrown an error, right?), you fail to notice the
mistake even after reading that section of code thirteen times.

Meanwhile, your colleague, who does not rely on such broken crutches,
spots it with a single glance at the code.

Richard

 

[ImpalerCore]

So now you come to rely on this to prevent mistypes.

And then you write what should be

  if (x == y)

and you switch the operands for safety, so you write

  if (y = x)

and because you have got completely out of the habit of paying attention
to what you actually write (because, after all, if you had made a typo
the compiler would have thrown an error, right?), you fail to notice the
mistake even after reading that section of code thirteen times.

Meanwhile, your colleague, who does not rely on such broken crutches,
spots it with a single glance at the code.

Richard

I sometimes run a 'grep -r "if (" * | grep " = "' to review
assignments in 'if' statements in my source, but most of the time, the
compiler catches them if I unintentionally make a mistake.

 

[BruceS]

No, as should by now be clear, you underestimated the number of people
who have made such arguments in this newsgroup in all seriousness. I
didn't understand it was a joke, not because it wasn't jokey enough, but
because too many people before you have said similar things with no
jocular intent at all.

OK, I'm glad we're clear now. It's either sad or laughable (maybe
both) that people do take this so seriously. I hope this thread has
helped the OP realize how flexible "correct" style can be, as well as
how inflexible some can be about what's "correct". I see disagreement
even among and with those I really respect and consider to be
experts. These style differences are so minor in the face of what I
see in the real world, like 400+ line functions that have nothing to
do with what their name implies, repeated cut-and-paste code, and
short-named variables with multiple unrelated purposes, that I failed
to see how anyone could be very passionate about them. Then again, I
don't even get passionate about the language. I use C where it makes
sense to me, and in other places use Java, C#, C++, etc. My primary
language is none of the above, though it looks and acts a lot like C.

So no matter how silly I try to be, someone else acts the same way
being serious. I'll have to try harder. Or resort to emoticons

 

[Anand Hariharan]

You dont say "if pi is larger than p".You say "if p is larger than
pi".

They are not equivalent statements. ;-)

 

[BruceS]

They are not equivalent statements. ;-)

No, they certainly aren't (good catch)! If one writes code with the
assumption that these are the same, one introduces a bug. So, a
better question might be which of the following would you say:

"e is larger than pi"
"pi is larger than e"

?

I know which *I* prefer.

 

[Richard Bos]

OK, I'm glad we're clear now. It's either sad or laughable (maybe
both) that people do take this so seriously.

Definitely both. Hence my misdirected attempt at sarcasm.

So no matter how silly I try to be, someone else acts the same way
being serious.

Depends on the subject; this is certainly one for which that is almost
true. Almost; even I would smell a rat if someone posted

if

{
/* code... */

}

Richard

 

[Tim Rentsch]

IYAM, the only benefit of this permission, as of the "other forms of
main()" one, is entirely political.

There are implementations that use the "constant expression"
permission to technical advantage. And Unix implementations
typically allow a 'char **envp' third argument to main().
I guess some people might not consider such things to provide
any (non-political) benefit. Other people (rightly IMO) think
that they do.

 

[Richard Bos]

There are implementations that use the "constant expression"
permission to technical advantage. And Unix implementations
typically allow a 'char **envp' third argument to main().
I guess some people might not consider such things to provide
any (non-political) benefit.

You miss the point. It's not the having /per se/ of such extensions that
is political; it is the insertion of extra sentences in the Standard
_specifically_ to "allow" _these_ extensions, even though they were
perfectly allowed already by the normal text of the Standard, which is
political. In other words, it is, as Keith wrote, the benefit _beyond_
the existing permission which is political.

Richard

 

[Tim Rentsch]

You miss the point. It's not the having /per se/ of such extensions that
is political; it is the insertion of extra sentences in the Standard
_specifically_ to "allow" _these_ extensions, even though they were
perfectly allowed already by the normal text of the Standard, which is
political. In other words, it is, as Keith wrote, the benefit _beyond_
the existing permission which is political.

In the first place, the comment is wrong. As I've already explained
in other postings, there's a significant difference between including
6.6p10 and leaving it out (and also differences for making other forms
of main() be implementation-defined, although these are more minor).

In the second place, the comment is silly. By your reasoning, we
could take all the implementation-defined behaviors and make them
undefined or unspecified behavior. After all, these behaviors could
then be specified in each implementation as extensions, right?
Let's just get rid of implementation-defined behavior altogether,
the benefits are entirely political.

I'm sure some developers and some development organizations
don't care whether some behavior that they rely on is
undefined or implementation-defined. Others do. Just
because it doesn't matter to you doesn't mean other folks
don't have good reasons why it matters to them.