Qry : Behaviour of fgets -- ?

[kuyper]

This text would fit into a newsgroup whose topic is production of
mildly creative absurd fiction or one discussing quirks of a
particular implementation of C BUT NOT into a discussion of C, because
it is only insofar related to it as it talks about something the
C-standard does not talk about. And 'C' is the set of things the
C-standard DOES talk about.

[...]

But it is NOT pointless to illustrute what "undefined behavior"
means by giving extreme examples.

It is not possible to illustrate 'nothing' by providing examples of
it.

True, but not very relevant. "nothing" is only one of the possible
forms that undefined behavior can take, and the huge, infinite variety
of other forms that it can take can indeed be illustrated.
If you think that "nothing" is the only permitted form of undefined
behavior, then you have most severely incorrect understanding of the
term.

 

[kuyper]

Richard Tobin wrote: ....

And what makes you think that that _FILE description describes the
actual structure that exists for any arbitrary file? If it does,
it may well work. If not, it certainly won't.

Well, the statements "_FILE is the complete type" and "_FILE would
contain the real fields" seemed, in context, pretty clear statements
of the fact that the implementor would ensure precisely that. The
"_FILE" identifier is from the name space reserved for the
implementation, and it's described as being used in <stdio.h>. As you
say, if _FILE didn't describe the actual structure, those macros
wouldn't work; and they could therefore not be part of a conforming
implementation of the C standard library. It's clear from context that
this was intended to describe a conforming implementation, so the
implementator must make sure that _FILE does correctly describe that
actual structure.

 

[Peter J. Holzer]

["Followup-To:" header set to comp.lang.c.]

It is not possible to illustrate 'nothing' by providing examples of
it.

But it is not "nothing", it is "everything".

hp

 

[Rainer Weikusat]

Rainer Weikusat wrote:
This text would fit into a newsgroup whose topic is production of
mildly creative absurd fiction or one discussing quirks of a
particular implementation of C BUT NOT into a discussion of C, because
it is only insofar related to it as it talks about something the
C-standard does not talk about. And 'C' is the set of things the
C-standard DOES talk about.
[...]

But it is NOT pointless to illustrute what "undefined behavior"
means by giving extreme examples.

It is not possible to illustrate 'nothing' by providing examples of
it.

True, but not very relevant. "nothing" is only one of the possible
forms that undefined behavior can take,

There is no such thing as a form of undefined behaviour because it
is undefined. If there was, it would be defined. In case of the midly
creative absurd fiction, it would be 'random nonsense defined by the
author'. And this random nonsense defined by whoever felt the desire
to write it is not part of the C-standard.

 

[Francis Glassborow]

There is no such thing as a form of undefined behaviour because it
is undefined. If there was, it would be defined. In case of the midly
creative absurd fiction, it would be 'random nonsense defined by the
author'. And this random nonsense defined by whoever felt the desire
to write it is not part of the C-standard.

Your view does not appear to be having much support. This is an
unmoderated group and what is acceptable is largely up to the consensus
to determine.

If you have anything technical and on topic to contribute please do so.

 

[Kenneth Brody]

This text would fit into a newsgroup whose topic is production of
mildly creative absurd fiction or one discussing quirks of a
particular implementation of C BUT NOT into a discussion of C, because
it is only insofar related to it as it talks about something the
C-standard does not talk about. And 'C' is the set of things the
C-standard DOES talk about.

[...]

But it is NOT pointless to illustrute what "undefined behavior"
means by giving extreme examples.

It is not possible to illustrate 'nothing' by providing examples of
it.

But UB is not "nothing".

Perhaps you don't realize that the term "undefined behavior" is,
in fact, defined. And it doesn't mean that "nothing" can happen.
In fact, just the opposite -- if a "nothing" part, which you appear
to be fixated on, even exists, it applies to _limits_ on what can
happen. There are _no_ limits to what can happen, which means,
literally, that _anything_ can happen.

So, it _is_ possible in this case to illustrate "nothing" by
providing examples of things which fall into the "no limits"
category.

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:ThisIsASpamTrap@gmail.com>

 

[kuyper]

There is no such thing as a form of undefined behaviour because it
is undefined. If there was, it would be defined. ...

That is a complete non-sequitur as far as I can tell. It's so
fundamentally wrong that I can't even figure out how to explain what's
wrong with it: it's like saying "Raisins taste good, therefore 1+1=3."
I don't know how to argue against it.

The standard DEFINES what the phrase "undefined behavior" means in the
context of the C standard: "behavior upon which this international
standard imposes no requirements". As you've misinterpreted this
definition, the standard imposes requirements so stringent that they
cannot even be met: "There is no such thing ...". Preventing an
implementation from giving any behavior whatsoever to code with
undefined behavior is exactly the opposite of the the committee
intended, and as far as I can tell, is also exactly the opposite of
what they wrote.

I don't think anyone is agreeing with you. Since your point of view
seems to constitute an extreme minority position, I'd recommend that
if you want ot convince anybody that you're right, you're going to
have to come up with new arguments. One option available to you would
be to file a Defect Report with the C committee asking for
clarification of this issue. Despite the name, Defect Reports are not
reserved for defects. Since there is no other mechanism set up for
obtaining an official ruling on the meaning of the C standard, Defect
Reports are also used to convey requests for clarification.

 

[Chris Dollin]

There is no such thing as a form of undefined behaviour

Yes, there is. /Every/ program behaviour is an example of undefined
behaviour (as it is defined by the C standard).

The standard puts constraints on the behaviour of a program: it
says certain things are not permitted (and consequently that
others are required). In the specific case of "undefined behaviour",
there are /no constraints applied/, so all behaviours are acceptable.

because it is undefined. If there was, it would be defined.

You're confusing "undefined behaviour" (behaviour which isn't defined by
anything anywhere) and "undefined behaviour" (behaviour on which the
standard places no requirements). The latter technical term is the
one typically used in this newsgroup.

(You're also making a philosophical error, in that you apparently
believe that every behaviour /must/ have a definition, which as
far as I can see at best wishful thinking; but we can deal with
your argument without worrying about that.)

 

[Rainer Weikusat]

That is a complete non-sequitur as far as I can tell.

It more a sign of a (probably non-remediable) failure of you to
understand the literal meaning of a term.

It's so fundamentally wrong that I can't even figure out how to
explain what's wrong with it:

The reason for this is that it isn't wrong.

The standard DEFINES what the phrase "undefined behavior" means in the
context of the C standard: "behavior upon which this international
standard imposes no requirements".

Correct. But that is not a definition of 'undefined behaviour' (even
trying to do so would quite obviously contradict the term) but what
the phrase 'undefined behaviour' is supposed to mean: Behaviour which
is not defined by the standard. Specifically, it is neither defined as
random nor as arbitrary but NOT defined.

As you've misinterpreted this definition, the standard imposes
requirements so stringent that they cannot even be met:
"There is no such thing ...".

The text was "There is no such thing as a form of undefined behaviour
because it is undefined." And it was written in response to your claim
that the standard would specify 'forms of the undefined', in other
words impose, requirements on it.

Preventing an implementation from giving any behavior whatsoever to
code with undefined behavior is exactly the opposite of the the
committee intended,

These are your words and not mine. Consequently, this is a claim you
made and not a claim I made.

I don't think anyone is agreeing with you. Since your point of view
seems to constitute an extreme minority position,

Logically, it is not relevant how many people are convinced of
something.

[...]

One option available to you would be to file a Defect Report with
the C committee asking for clarification of this issue.

The issue is perfectly clear.

That

i = 3;
i = ++i;

means 'the value of i is now 3' is wrong, because the meaning of this
statement is undefined. 'i has now the value of 4' is wrong for the
same reason. Stating that it means that 'the front door should open'
is still wrong. Same reason again. And this can be continued for every
possible statement about anything: There is no statement which is
supposed to be true, provided the reference for determining what
exactly is true or false is the C-standard, which, for this particular
instance, does not define that.

This is completely orthogonal to the question what conceivable
behaviour of C-implementations when processing this piece of non-C
could be. And C is again very simple in this respect: Whatever the
behaviour may be, it does not matter. No reason to discuss it.

 

[Kenneth Brody]

The text was "There is no such thing as a form of undefined behaviour
because it is undefined." And it was written in response to your claim
that the standard would specify 'forms of the undefined', in other
words impose, requirements on it.

The Standard specifies no such thing as "forms of the undefined",
and no one here is specifying such things, either. Rather, they
are giving examples of behavior which do not contradict UB in the
Standard.

No one is saying "i = i++;" _will_ do such-and-such. Rather, they
are saying that "i = i++;" _may_ do such-and-such, and it would
still be conforming.

[...]

The issue is perfectly clear.

That

i = 3;
i = ++i;

means 'the value of i is now 3' is wrong,

No, it's not. Or, rather, it might not. It is certainly possible
that a given implementation results in i having a value of 3, and
such an implementation would be conforming.

Now, to say that "the value of i shall be 3" would be wrong, as it
contradicts the Standard. (Unless you are an implementor, and you
have chosen to define your particular implementation's behavior in
this case. Defining what your implementation does with UB is
allowed.)

because the meaning of this statement is undefined.

I assume that "this statement" refers to "i = ++i;" and not "the
value of i is now 3".

'i has now the value of 4' is wrong for the
same reason.

Again, the value of i may be 4 in a conforming implementation.

Stating that it means that 'the front door should open'
is still wrong.

No one here is making such a statement. There is a world of
difference between "the front door should open" and "the front
door could open".

And, again, if you are making your own implementation, you are
certainly free to say "the front door should open" as it
pertains to your implementation.

Same reason again. And this can be continued for every
possible statement about anything: There is no statement which is
supposed to be true, provided the reference for determining what
exactly is true or false is the C-standard, which, for this particular
instance, does not define that.

Every statement made here by the regulars is true in this
regard, as they are always qualified with "may do this", or "does
this on my particular platform".

This is completely orthogonal to the question what conceivable
behaviour of C-implementations when processing this piece of non-C
could be. And C is again very simple in this respect: Whatever the
behaviour may be, it does not matter. No reason to discuss it.

There are plenty of reasons to discuss this when the subject comes
up with someone posting either a question ("why does X do Y?") or,
even more importantly, when someone answers "why" with a definitive
statement ("because 'i++' returns the old value").

The reason for discussing it is to make it clear to the reader that
UB has been invoked, and the result of UB can be, literally, anything.

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:ThisIsASpamTrap@gmail.com>

 

[Ben Bacarisse]

Your view does not appear to be having much support.

Well, count me as in support then. I did not say anything before
because RW was arguing perfectly adequately without my muddying the
waters but I, too, dislike any operation description of UB.

Because I have a liking for denotational semantics, given a C program
X which has some UB elements in it, I think E[X] = _|_ [1]. It is
worrying that, for some beginners, this fact (that their program has
no meaning) is not distressing enough, but attaching fanciful stories
to _|_ (especially ones to which experience will soon attribute low
probabilities) makes it seem *less* serious in my book.

It think RW's position is encapsulated in the last words of
Wittgenstein's Tractatus: "Whereof one cannot speak, thereof one must
be silent".

[1] The E in E[X] is the curly E used to refer to the "meaning" of
the program. _|_ is "bottom" (⊥ if you have a modern new reader and
some good fonts).

 

[Douglas A. Gwyn]

There is no such thing as a form of undefined behaviour because it
is undefined. If there was, it would be defined. ...

No, "defined" and "existent" do not mean the same thing.
Behavior is "defined" if and only if there is a definite
specification for it, and is "undefined" otherwise.

In the context of the C standard, there are two ways in
which behavior may be "undefined": either there is no
explicit specification concerning the behavior (under
the particular circumstances), or there is an *explicit*
statement in the standard that the behavior is undefined
(under the particular circumstances).

Other standards (such as POSIX) or specific C implementations
can of course provide definitions (specifications) for the
behavior that the C standard has left undefined. If nobody
specifies the behavior, however, then while it is certain
to be *some* behavior, it is not *defined* behavior.

The important thing for programmers to realize in this
connection is that relying on undefined behavior to be any
specific behavior is risky; just because it happens a
certain way today doesn't mean it will behave the same
tomorrow, and especially not if the code is ported to
another platform.

 

[Douglas A. Gwyn]

Correct. But that is not a definition of 'undefined behaviour' (even
trying to do so would quite obviously contradict the term) but what
the phrase 'undefined behaviour' is supposed to mean: Behaviour which
is not defined by the standard. Specifically, it is neither defined as
random nor as arbitrary but NOT defined.

Wrong; it is the operative definition for the term "undefined
behavior" in the context of the C standard. There is no
contradiction in defining that term, any more than there would
be to *write* about the properties of *sound*. You're mixing
"levels" (to borrow Hofstadter's phrase).

 

[Bart van Ingen Schenau]

Correct. But that is not a definition of 'undefined behaviour' (even
trying to do so would quite obviously contradict the term) but what
the phrase 'undefined behaviour' is supposed to mean: Behaviour which
is not defined by the standard. Specifically, it is neither defined as
random nor as arbitrary but NOT defined.

Wrong. In this group the convention is that if a term or phrase is
defined by the C standard, then that definition is how the term
should/will be interpreted when used in a post to this group.
The term 'undefined behaviour' has such a definition in the standard, so
you can't just interpret it the way you do.

You seem to imply that, if a program invokes UB, then whatever behaviour
results is wrong, because showing behaviour means that it must be
defined, which contradicts your interpretation of 'undefined
behaviour'. This leads to the logical conclusion that 'undefined
behaviour' can not exist.

The text was "There is no such thing as a form of undefined behaviour
because it is undefined." And it was written in response to your claim
that the standard would specify 'forms of the undefined', in other
words impose, requirements on it.

The fact that the standard does not define the behaviour does not mean
that you can't speculate about what a particular compiler/processor/OS
would do when confronted with such code.
Because there is no definition for the behaviour, you can't be SURE what
it will be, but you CAN speculate.

Preventing an implementation from giving any behavior whatsoever to
code with undefined behavior is exactly the opposite of the the
committee intended,

These are your words and not mine. Consequently, this is a claim you
made and not a claim I made.

I don't think anyone is agreeing with you. Since your point of view
seems to constitute an extreme minority position,

Logically, it is not relevant how many people are convinced of
something.

[...]

One option available to you would be to file a Defect Report with
the C committee asking for clarification of this issue.

The issue is perfectly clear.

That

i = 3;
i = ++i;

means 'the value of i is now 3' is wrong, because the meaning of this
statement is undefined. 'i has now the value of 4' is wrong for the
same reason. Stating that it means that 'the front door should open'
is still wrong. Same reason again. And this can be continued for every
possible statement about anything: There is no statement which is
supposed to be true, provided the reference for determining what
exactly is true or false is the C-standard, which, for this particular
instance, does not define that.

So, how many bug-reports have you filed with the compiler builders that
their behaviour for the code above is incorrect?

Bart v Ingen Schenau

 

[Douglas A. Gwyn]

What happens when the function definition of fun() is in an entirely
separate TU? Isn't than the 'restrict' qualifier useful in the header
file of that TU?

It's useful for documentation purposes, but doesn't affect
compilation or linkage.

 

[Douglas A. Gwyn]

I'm interested, do you know one implementation on a word adressed platform
which used a byte selector which didn't use otherwise unused bits in other
pointers?

Yes; there have been architectures (typically 16-bit word ones)
where type char * or void * required multiple words but other
pointers required only a single word. Also, the conversion
from byte address to word address is likely to force the "must
be zero" bits to actually be zero even when all object pointers
have the same size, although since it is in the realm of
undefined behavior, the implementation may opt to not worry
about them (i.e. will assume that they are already zero).

My perception was that the current word-addressed platforms used
sizeof(char)==sizeof(word) and so had no byte selector: ...

On a word-addressed machine where more than one char is packed
into a word, there *must* be a byte selector. Some implementations
have used the low-order bits for this, necessitating shifting to
convert between pointer types, while others have used the high-
order bits. In the latter case, if the byte selector is not
all-zero, most likely an invalid-address trap will occur if the
pointer value is used as a word address.

 

[Keith Thompson]

Wrong. In this group the convention is that if a term or phrase is
defined by the C standard, then that definition is how the term
should/will be interpreted when used in a post to this group.
The term 'undefined behaviour' has such a definition in the standard, so
you can't just interpret it the way you do.

You seem to imply that, if a program invokes UB, then whatever behaviour
results is wrong, because showing behaviour means that it must be
defined, which contradicts your interpretation of 'undefined
behaviour'. This leads to the logical conclusion that 'undefined
behaviour' can not exist.

I think you've misinterpreted (this part of) what Rainer is saying.

Obviously the phrase "undefined behavior" is defined by the standard
(C99 3.4.3). Given that definition, the behavior of any code whose
behavior is undefined is not defined.

The phrase is defined. The behavior is not. I *think* that's all
Rainer is saying here.

I disagree with some of Rainer's other arguments, but I think he's
correctly summarized what the standard says about UB.

[snip]

 

[Kenneth Brody]

No, "defined" and "existent" do not mean the same thing.
Behavior is "defined" if and only if there is a definite
specification for it, and is "undefined" otherwise.

[...]

<pedant>
There are things other than "definite specification" and
"undefined". For example, there is "unspecified", as in
6.5.2.2p10:

The order of evaluation of the function designator, the actual
arguments, and subexpressions within the actual arguments is
unspecified, but there is a sequence point before the actual
call.
</pedant>

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:ThisIsASpamTrap@gmail.com>

 

[Keith Thompson]

It's useful for documentation purposes, but doesn't affect
compilation or linkage.

So the 'restrict' qualifiers in the declaration of, say, memcpy()
might as well be comments. And, like comments, they can be wrong.

Any 'restrict' qualifiers in the definition of memcpy() are meaningful
(*if* memcpy() is implemented in C), but are not necessarily available
to the user.

Allowing 'const' qualifiers on pointer parameters to be inconsistent
between a function declaration and its definition makes some sense, I
suppose, since they affect only the implementation of the function;
they say something about the parameter object, which is local to the
body of the function, and there's no reason for the caller to care
about it.

Allowing 'restrict' qualifiers to be inconsistent seems problematic,
since they're saying something about the pointed-to objects, not just
about the pointers, and that's information that could be useful to the
caller.

 

[Keith Thompson]

There is no such thing as a form of undefined behaviour because it
is undefined. If there was, it would be defined.

Behavior can occur without being defined. Stuff happens.

You've managed to make a claim to which there are infinitely many
counterexamples.