main() in C90

[Kelsey Bjarnason]

[snips]

The limits comparison is an integer comparison and a jump.

And thus, two more instructions than need to be there.

In most processors this is 2-3 instructions. Then, there is a call to
C99 printf, that is surely at least 3000 - 4000 instructions, several
function calls, and a quite BIG overhead.

Whether you call printf or not is irrelevant.

Your attitude towards errors and error checking is the same as the
committee. "Error checking is stupid. C doesn't do error checking".

Actually, C does do some error checking, but you miss the point. The
point is it is not the language's job to detect every possible error
condition, particularly when such error checking imposes performance
issues on the code.

My preferred example is string handling. Sure, the standard could
mandate that every string-related call check for NULLs and overflows and
the like, but to what end?

It is only on input that we get strings of unknown, unpredictable sizes.
Once they're "in the app", so to speak - once they've been input and
parsed, scanned, length-checked, whatever - then we know how big they
are, what we can do with them: a length-checking strcat, at that point,
buys us *nothing* but inefficiency.

If I'm going to be doing a lot of string processing in my code, the
*last* thing I want is some library routine pointlessly wasting time to
tell me what I already know: that I have (or don't) space to store the
string. I figured that out at input time, checking again and again and
again doesn't buy me anything, it just slows the code down.

Error checking is good. *Pointless* error checking is not good. Richard
and others are attempting to get you to see that you can have both error
checking *and* efficiency, where you seem to be focused solely on error
checking, to the detriment of efficiency.

You defend them becasue you and they have the same basic philosophy
towards error checking:

"Error checking is unnecessary overhead"

Nope. *Pointless* error checking is unnecessary overhead. Stop ignoring
the key term in there: "pointless".

 

[James Kuyper]

As others have pointed out, the presence of an overlong buffer is
not detectable, since asctime never places a string that occupies
over 26 bytes (length 25) in it.

When the behavior of asctime() is undefined by the C standard, there's
no reason why asctime() couldn't place a string that occupies more than
26 bytes in the location in memory whose first 26 bytes are that buffer.

... However a string of less than 26
byte capacity would be immediately detectable by causing undefined
behaviour. It is up to you to detect that, and I don't want the
task (portable).

I said, very explicitly "There is no way for strictly conforming code to
detect the fact that the buffer is larger than 26, ..." I was not
discussing short buffers. Jacob did not state that quite as clearly as I
did, but since he was talking about ways of avoiding buffer overruns
inside asctime(), when he talked about "fix the buffer size", he also
could not have been talking about making the buffer shorter.

Let us get back to what we were talking about, and not an irrelevant
tangent: an implementation of asctime() that uses a buffer long enough
to hold even the longest possible output from an unnormalized struct tm
does not violate any requirement of the C standard. If you disagree,
cite the violation. The fact that the standard's reference
implementation uses of buffer of exactly 26 bytes is irrelevant, for
reasons that have already been discussed to death.

 

[David Thompson]

I think he's claimed to be an "observing member" or something like
that. I've heard that actual members of the committee don't recall
seeing him at any meetings.

The claim in my copy of The [Poorly] Annotated ANSI C Standard
is that he was an "Observing Member" of ANSI X3J11 "throughout
formation and adoption" (presumably meaning 1989). He says nothing
about (JTC1SC22)WG14, and I'm pretty sure it didn't even exist for
most if not all of that time.

- formerly david.thompson1 || achar(64) || worldnet.att.net