HeathField Strange Ideas!

[Keith Thompson]

The behaviour is defined until the return statement is processed,
but no further.

Right. The behavior *of the program* is defined. The behavior of the
operating system after the program terminates is irrelevant to the
question.

Aside from the fact that the question (apparently) ought to have been
"Is the following program strictly conforming or not?",

Huh? Those are two different questions, both valid (and the answer to
both is "yes"). Why should one question have been asked rather than
the other?

[snip]

 

[Keith Thompson]

Firstly, the standard does not restrict the language -- you can have
a routine to access keyboard in given implementation. Standard only
specifies the minimal requirements implementation have to fulfil.

[...]

Yes, the standard does restrict the language in many ways. For
example, an implementation can't yield the value 5 for the expression
2+2.

 

[Walter Roberson]

Right. The behavior *of the program* is defined. The behavior of the
operating system after the program terminates is irrelevant to the
question.

But by that reasoning, we have no grounds for telling people that
they ought to be returning a value explicitly in C89 programs.
The relevant clause of C89 leaves it unspecified as to what happens
if no value is returned, which means it is up to the operating system
as to what happens, which is *exactly* the same case as if one
of the defined statuses -is- returned.

 

[Malcolm McLean]

Is the behavior of the following program defined or not?

int main(void) {
return 0;
}

The behaviour is defined until the return statement is processed,
but no further.

Right. The behavior *of the program* is defined. The behavior of the
operating system after the program terminates is irrelevant to the
question.

It depends who is asking the question, and why.
For an average program, the questioner probably wants to know whether it
will function as expected under any conforming implementation. it would be
excessively precise to detail what happens on startup and termination.
However when a program does nothing, all that can be observed is the startup
and termination. So if someone says "will this do the same thing on my Mac
as my Windows Vista machine?", you might well give a different answer. If
they say "is the behaviour defined?" you've got to work out whether they
really know what the C standard means by "defined behaviour" or are just
using the word because they think that's how software engineers talk.

If you have to give a yes/no answer the answer is "yes", but only because it
is a toy question designed to have a yes/no answer. If it came up in
non-example context a useful answer would be more nuanced.

 

[Christopher Benson-Manica]

Aside from the fact that the question (apparently) ought to have been
"Is the following program strictly conforming or not?",

Huh? Those are two different questions, both valid (and the answer to
both is "yes"). Why should one question have been asked rather than
the other?

Because I intended to ask a question whose answer was not debatable,
for rhetorical purposes. I seem to have failed with the original
question.

 

[Christopher Benson-Manica]

But by that reasoning, we have no grounds for telling people that
they ought to be returning a value explicitly in C89 programs.
The relevant clause of C89 leaves it unspecified as to what happens
if no value is returned, which means it is up to the operating system
as to what happens, which is *exactly* the same case as if one
of the defined statuses -is- returned.

The behavior of the OS after program termination was not in the domain
of the question, but that does not mean that it shouldn't be of
interest to the programmer. Isn't "an implementation-defined form of
the status 'successful termination'" (n869 7.20.4.3 p5) (or at worst
an implementation-defined return status) an improvement over an
unspecified return status? (The word "exactly" doesn't seem to apply
here, unless I'm missing something.)

 

[Christopher Benson-Manica]

I don't think there's anything mealy mouthed about that. Not all
questions
can be answered yes/no. In fact if someone demands "a simple yes or a
simple no" there's usually something wrong with the question in some way.

usually
^^^^^

I rather doubt that there is a significant positive correlation
between a question having a "yes-no" answer and it being "defective".

You can create a question which has a "simple yes or a simple no" answer.
Those who demand "a simple yes or a simple no" as an answer usually have
defective questions, like "is C++ better than C, yes or no?".

Obviously, that is a silly question. What's less obvious is why the
yes-no question of whether Mr. Bacarisse agrees with you or not is
"defective", which seems to be the point that is under contention.

 

[CBFalconer]

.... snip ...

This compiles under lcc-win32:
void _stdcall fn(void)
{
int _stdcall=0;
}

Which, I believe, proves that lcc-win32 is not a C compiler. That
'code' is purposeless, does nothing, and should produce some sort
of reaction in any compiler.

 

[Eric Sosman]

Kenneth Brody wrote On 08/27/07 13:45,:

Eric Sosman wrote:
[...]

When pressed, Jacob admits that his compiler supports
"C with extras" in addition to (he says) Standard C. He
does not claim that operator overloading and String and the
rest are part of C -- and that's attributable, at least in
part, to the existence of the Standard. In the B.O.D. people
*did* just add new gadgets to their implementations and call
the result "C," and since there was no arbiter to say otherwise,
they got away with it.

[...]

Well, what is the definition of a "C compiler"? I assume that it
means it will properly compile any conforming C program. I do not
assume that it means it will fail to compile any and all non-
conforming programs, nor that it contains no extensions to the
Standard.

The Standard defines C implementations.

... and that's my point: Without the definitions (which
the O.P. thinks of as restrictions), you get anarchy. This
is no ivy-covered ivory-tower prediction, but based on
actual experience: We *did* get anarchy.

The Standard says that strchr() and its friends are
declared in <string.h>. It does not forbid an implementation
from providing a <strings.h> header in addition, but it saves
the programmer from having to write

#if defined(PLATFORM_X) || defined(PLATFORM_Y)
#include <strings.h>
#else
#include <string.h>
#endif

Yes, we had to do this -- and worse -- in the Bad Old Days.
Now, we don't need to.

The Standard gives the rules for macro substitution, so
we no longer need to worry that the insides of a string
literal will be macro-replaced, as we did in the B.O.D.

The Standard promises that free(NULL) is safe, which was
not always so in the B.O.D. The Standard requires sprintf()
to return a count; some in the B.O.D. returned a pointer.
The Standard separates the names of one struct's elements from
those of another struct; B.O.D. C compilers varied in this
regard. And so on, and so on: the Standard "restricts the
language" in order to define it, and thus give the programmer
a chance to do more programming and less porting.

I do not claim that the Standard has made a bed of roses
for programmers, but I *do* say that it has removed an awful
lot of the thorns. It has restricted us from feeling those
thorns in inconvenient parts of our anatomies.

My *nix boxes have perfectly good C compilers on them, even though
I can open() files and communicate via TCP/IP sockets. I believe
that the man pages on these "extra" features don't state that they
are part of ANSI C, but rather that they are part of some other
standard (if appropriate), or that they are an extension from some
other source.

I don't believe that they need to be called "C (with extras)
compilers".

On the other hand, I see the OP has not posted any replies to this
thread as of yet, over 2-1/2 days later.

From the first I thought he might be a troll, but amid
all the foolishness there was what seemed to be an actual
frustration with the "restrictions" imposed by the Standard.
But now I'm starting to think I should have sent the Three
Billy Goats Gruff in his direction.

 

[CBFalconer]

Size_t is, last I checked, an unsigned integer type. This would
be most improper for anything involving negative values:

size_t x = -2;
size_t y = -3;

What's the result of x + y? Is it -5? Not here it ain't.

Yes, it is -5, in the modulo arithmetic used for unsigned objects.
This happens to be identical to MAX_SIZE_T - 4. You probably don't
know what MAX_SIZE_T is on your system, and can't find out
directly. However, the value exists.

 

[Keith Thompson]

But by that reasoning, we have no grounds for telling people that
they ought to be returning a value explicitly in C89 programs.
The relevant clause of C89 leaves it unspecified as to what happens
if no value is returned, which means it is up to the operating system
as to what happens, which is *exactly* the same case as if one
of the defined statuses -is- returned.

The status value returned by a program is part of its behavior. The
above program returns a well-defined status value. Its effect on the
environment is not entirely well-defined, but it's as close to it as
you can get.

Reaching the closing '}' of main in C90 returns an undefined status
value to the environment. I don't *think* that qualifies as
"undefined behavior"; it could be argued either way. But the point
was to ask a question with a clear and unambiguous yes or no answer.

I'll also note that the question was about the behavior *of the
program*, not the behavior of the environment. The behavior of the
program is defined. Questions about the subsequent behavior of the
environment are outside the narrow scope of the question, but within
the scope of the C standard and of good programming practice.

 

[Francine.Neary]

Kenneth Brody wrote On 08/27/07 13:45,:

From the first I thought he might be a troll, but amid
all the foolishness there was what seemed to be an actual
frustration with the "restrictions" imposed by the Standard.
But now I'm starting to think I should have sent the Three
Billy Goats Gruff in his direction.

I don't necessarily think a supply of fresh trolls is categorically a
bad thing... a discussion is no less interesting or useful to its
participants and readers because it happened to be started by a troll.

Much worse, in my opinion, are
a) persistent trolls who keep harping on about one thing, unlike the
one-off troll who sometimes chances on an interesting topic (we've
seen two examples in this very thread)
b) "serious" posters who in fact contribute absolutely nothing except
a stream of whinges, frequently expressed in a willfully obnoxious and
unnecessarily truculent way that makes you hope you never have the
misfortune to share a beer with them (the initials "D.U." spring to
mind here)

 

[Malcolm McLean]

I rather doubt that there is a significant positive correlation
between a question having a "yes-no" answer and it being "defective".

The correlation is with demands that the question be answered in a yes/no
manner, and the question being defective.

 

[jacob navia]

jacob navia wrote:
... snip ...

Which, I believe, proves that lcc-win32 is not a C compiler. That
'code' is purposeless, does nothing, and should produce some sort
of reaction in any compiler.

Hi Chuck!

As it seems, you didn't take your much needed holidays... That was
a bad decisions: you are irascible and tend to spew a lot of
nonsense

The purpose of that code was to prove that the identifier _stdcall is
recognized only at file scope. It is not recognized as special
in an inner scope as required by the standard. _stdcall starts with a
single underscore and it is not reserved at an inner scope, as
Eric Sossman had pointed out.

jacob

 

[Keith Thompson]

Which, I believe, proves that lcc-win32 is not a C compiler. That
'code' is purposeless, does nothing, and should produce some sort
of reaction in any compiler.

Allowing '_stdcall' to appear within a function declaration is within
the range of extensions explicitly allowed by the C standard. See C99
4p6:

A conforming implementation may have extensions (including
additional library functions), provided they do not alter the
behavior of any strictly conforming program.

Its purpose is to demonstrate how lcc-win32 handles this particular
extension. Depending on what '_stdcall' means, it probably defines a
function that does nothing; of course, defining a function that does
nothing when called is perfectly valid. The standard does not require
a diagnostic, as long as '_stdcall' is a documented extension (if it
isn't, the compiler must report a syntax error).

IMHO a compiler that provides extensions should have a mode in which
any use of such extensions is diagnosed, but the standard doesn't
require this.

There may well be reasons why lcc-win32 is not a conforming C
compiler, but this isn't one of them.

 

[pete]

Yes, it is -5, in the modulo arithmetic used for unsigned objects.
This happens to be identical to MAX_SIZE_T - 4. You probably don't
know what MAX_SIZE_T is on your system, and can't find out
directly. However, the value exists.

In C89 you use ((size_t)-1) instead of SIZE_MAX.

 

[Malcolm McLean]

From the first I thought he might be a troll, but amid
all the foolishness there was what seemed to be an actual
frustration with the "restrictions" imposed by the Standard.
But now I'm starting to think I should have sent the Three
Billy Goats Gruff in his direction.

The complaint was that he was told "you can't read the keyboard in standard
C". Since of course his compiler did provide a function that did just that,
he felt the advice was unhelpful.
ANSI C doesn't provide any libraries for even minimal interaction with the
console, only streams, as all regs know. Sometimes they maybe forget that
this can be surprise to newbies.

 

[Richard Heathfield]

Malcolm McLean said:

The complaint was that he was told "you can't read the keyboard in
standard C". Since of course his compiler did provide a function that
did just that, he felt the advice was unhelpful.

I have kept out of this thread up until now, for what I hope are obvious
reasons. But it appears that some people participating in this thread
are unaware of the background.

It all goes back to 23rd November 2002, in a thread entitled "help", in
which the OP gave some very bad advice, that I (among others)
corrected. The OP took exception to being corrected, and launched a
long series of vituperative rejoinders, notable more for their heat
than for their light.

In one of them, he threatened to break my nose. (No, really he did.)

He also wrote a negative and indeed expletive review of "C Unleashed"
which he then posted on Amazon (and the review made it very clear that
he has not actually read the book).

In December 2002, he posted a thread to - I think - comp.std.c and
comp.lang.c.moderated, entitled "Richard HeathField. Bad ideas!", from
which the OP in this thread is derived.

On that occasion as on this, I stayed well out of it and he was put
firmly in his place by a number of C experts.

 

[Al Balmer]

Malcolm McLean said:


I have kept out of this thread up until now, for what I hope are obvious
reasons. But it appears that some people participating in this thread
are unaware of the background.

It all goes back to 23rd November 2002, in a thread entitled "help", in
which the OP gave some very bad advice, that I (among others)
corrected. The OP took exception to being corrected, and launched a
long series of vituperative rejoinders, notable more for their heat
than for their light.

Interesting. It appears that his current post was constructed from
bits and pieces of the "Bad ideas" thread, no new material. In light
of the posts by some (not you) about complaints made to his ISP, I
also found his news server's description of itself interesting:

"This site is designed as a last resort access way to USENET for those
who can't find a better option"

In one of them, he threatened to break my nose. (No, really he did.)

Not just the nose <g>:
" But it quite obviously you need it smashed up u asshole. Maybe some
other parts of you too."

 

[Paul]

I want to say that I am not the person involved in any threats with
Richard HeathField in 2002. I only found out about this history from Mr
HeathField's post quoted below. I would never threaten anyone and any
violence makes me sick in the stomach.

What happened was I have real frustrations about the negative way people
in this forum use the standard to restrict what people can do with C,
and I searched Google to find if it had been discussed already. I found
the "HeathField Bad Ideas" post, I thought that it reflected my views in
a nutshell and basically plagiarized it.

I'm sorry if this has brought up bad memories for Mr HeathField - I
really didn't realize it had that extra dimension.