Does your C compiler support "//"? (was Re: using structures)

[Zack Weinberg]

But the commercial judgment was that size_t should be no wider than long.
Why did the C committee overrule that existing practice, and
invalidate existing programs?

This is a slight misstatement. There is exactly one ABI - not in wide
use yet, but it does claim C99 conformance - that defines size_t to be
wider than long: Win64. One will refrain from speculating on the
cause-and-effect relationship between this and the C99 committee's
decision to allow it.

Personally, I have no hesitation in characterizing this ABI as broken,
precisely because it does that, and I'm pleased to hear POSIX did not
follow C99's error.

zw

 

[Dan Pop]

I suspect so.

No program generating output qualifies as strictly conforming. Any of
the <stdio.h> functions capable of generating output can fail for
*unspecified* reasons, therefore the program's actual output depends on
unspecified behaviour (the success of its output function calls).

To make the concept of "strictly conforming program" even
remotely/theoretically useful, its definition must be revised.

Dan

 

[Richard Delorme]

Dan Pop a écrit :

In <[email protected]> "Douglas A. Gwyn"


No program generating output qualifies as strictly conforming. Any of
the <stdio.h> functions capable of generating output can fail for
*unspecified* reasons, therefore the program's actual output depends on
unspecified behaviour (the success of its output function calls).

To make the concept of "strictly conforming program" even
remotely/theoretically useful, its definition must be revised.

Maybe it is better to remove its definition completely then. Any computer
instruction can fail for *unspecified* reasons, so no program can qualify
as a "strictly conforming program".

 

[Morris Dovey]

Welcome back! (You were missed.)

 

[Kevin Easton]

Dan Pop a ?crit :


Maybe it is better to remove its definition completely then. Any computer
instruction can fail for *unspecified* reasons, so no program can qualify
as a "strictly conforming program".

Not on the C abstract machine they can't. When a real machine fails, it
becomes non-conforming

- Kevin.

 

[Douglas A. Gwyn]

No program generating output qualifies as strictly conforming. Any of
the <stdio.h> functions capable of generating output can fail for
*unspecified* reasons, therefore the program's actual output depends on
unspecified behaviour (the success of its output function calls).

No, the output we were talking about in the conformance
section is the output that is properly attempted. Beyond
that is outside the scope of the standard. For example,
the output could be directed at /dev/null on one system
and at a display on another, which differ dramatically in
appearance but not in what was output by the program.

It is absurd to think that the conformance section uses
output in the fundamental role that it does, yet that
output has to be a void set.

 

[James Kuyper]

No, the output we were talking about in the conformance
section is the output that is properly attempted.

However, that's not what it says in the standard. It just refers to
output, not "properly attempted output".

....

It is absurd to think that the conformance section uses
output in the fundamental role that it does, yet that
output has to be a void set.

Agreed. That absurdity is one of the key defects with the current
definition. That doesn't change the fact that the absurdity is indeed
present in the standard.

 

[Dan Pop]

No, the output we were talking about in the conformance
section is the output that is properly attempted.

That's precisely my point. The text of the standard should be fixed to
*explicitly* say that. The reader of the standard cannot be expected to
be able to read the minds of the people who wrote the standard and the
current wording does NOT reflect the intent:

5 A strictly conforming program shall use only those features of
the language and library specified in this International
Standard.2) It shall not produce output dependent on any
unspecified, undefined, or implementation-defined behavior,
and shall not exceed any minimum implementation limit.

It is unspecified whether puts("hello, world") produces any output at all.

Dan

 

[Larry__Weiss]

5 A strictly conforming program shall use only those features of
the language and library specified in this International
Standard.2) It shall not produce output dependent on any
unspecified, undefined, or implementation-defined behavior,
and shall not exceed any minimum implementation limit.

It's too bad that the standard does not attempt to give any examples
of a complete strictly conforming program. That one snippet
of code from a hypothetical strictly conforming program in the
footnotes on page 7 sheds little light, in general.

- Larry Weiss

 

[Douglas A. Gwyn]

It is unspecified whether puts("hello, world") produces any output at all.

Wrong. The semantic specification says that the characters
are written to the standard output stream. A write error
may occur, but the write itself does occur.

 

[Francis Glassborow]

Wrong. The semantic specification says that the characters
are written to the standard output stream. A write error
may occur, but the write itself does occur.

And I think that is the key. The Standard output stream is simply the
way data leaves the program, it says nothing about how that data is then
used to provide (or not) a human recognisable result. If my display
device breaks so I cannot see any results that says nothing about the
conformance of the program. If my OS goes sour and scrambles the program
output, that says nothing about the program's conformance.

I think it is important to remember that the Standard is talking about
the behaviour of an abstract machine and so the actual behaviour of any
real hardware is completely irrelevant. This is hard to grasp because
most people are firmly rooted in reality and when they see words about
'output' they interpret them to mean data they can at least see, however
in the case of the abstract machine that data has an abstract
representation, we do not even know if it is composed of electrons in a
wire -- computing devices have been constructed with (hot) air is the
fluid

 

[Dan Pop]

Wrong. The semantic specification says that the characters
are written to the standard output stream. A write error
may occur, but the write itself does occur.

Nope, the write itself is merely attempted. If it fails, one or more
characters of the intended program output will not be part of the
program's output. But the standard talks about the program output, not
about the *intended* program output.

Dan

 

[Larry__Weiss]

And I think that is the key. The Standard output stream is simply the
way data leaves the program, it says nothing about how that data is then
used to provide (or not) a human recognisable result. If my display
device breaks so I cannot see any results that says nothing about the
conformance of the program. If my OS goes sour and scrambles the program
output, that says nothing about the program's conformance.

I think it is important to remember that the Standard is talking about
the behaviour of an abstract machine and so the actual behaviour of any
real hardware is completely irrelevant. This is hard to grasp because
most people are firmly rooted in reality and when they see words about
'output' they interpret them to mean data they can at least see, however
in the case of the abstract machine that data has an abstract
representation, we do not even know if it is composed of electrons in a
wire -- computing devices have been constructed with (hot) air is the
fluid

Do write errors ever occur while using the abstract machine?

- Larry Weiss

 

[Dan Pop]

And I think that is the key. The Standard output stream is simply the
way data leaves the program, it says nothing about how that data is then
used to provide (or not) a human recognisable result. If my display
device breaks so I cannot see any results that says nothing about the
conformance of the program. If my OS goes sour and scrambles the program
output, that says nothing about the program's conformance.

You're confused. We're talking about the cases when <stdio.h> output
functions report failure, therefore the *program* cannot produce the
intended output. Noone cares, in this discussion, about what happens
with the data that is actually output by the program.

Dan

 

[James Kuyper]

Wrong. The semantic specification says that the characters
are written to the standard output stream. A write error
may occur, but the write itself does occur.

A write that fails is a function call, but it can't qualify as output.

By your logic, a check that bounces counts as payment. If that's the way
you feel, do you happen to be selling anything that I'd care to buy? I'd
be happy to do business under those terms.

 

[Al Grant]

I think it is important to remember that the Standard is talking about
the behaviour of an abstract machine and so the actual behaviour of any
real hardware is completely irrelevant.

The Standard does refers to the actual behavior of real hardware,
in normative text, in vague and controversial ways. For example
7.19.3, "if a file can support positioning requests (such as a
disk file, as opposed to a terminal)". Or 7.19.5.3, "a stream is
fully buffered if and only if it can be determined not to refer
to an interactive device".

But the real question in the conformance issue is "at what point
_in the astract machine_ does a program 'produce output'"?

Is it when it calls say fputs()?
Is it when it calls say fputs() successfully?
Is it when it calls fclose() or fflush() and the data is
"delivered to the host environment"?

One might also ask the question "does data written to a file
created by tmpfile() have the status of 'output'"?

 

[Larry__Weiss]

But the real question in the conformance issue is "at what point
_in the astract machine_ does a program 'produce output'"?

Is it when it calls say fputs()?
Is it when it calls say fputs() successfully?
Is it when it calls fclose() or fflush() and the data is
"delivered to the host environment"?

I'm still eager to get an answer to my earlier question:

Do write errors ever occur _in the abstract machine_?

 

[Kevin Easton]

I'm still eager to get an answer to my earlier question:

Do write errors ever occur _in the abstract machine_?

Of course, because if they didn't, then any implementation that did
return write errors wouldn't be conforming to the semantics of the
abstract machine.

- Kevin.

 

[Douglas A. Gwyn]

Do write errors ever occur while using the abstract machine?

They're not part of the model. ("Outside the scope of the
standard.") That emphasizes even more strongly that the
occurrence of write errors happens "beyond" the phase of
output that is relevant for conformance.

 

[Douglas A. Gwyn]

Nope, the write itself is merely attempted.

Wrong again. The standard says that the characters *are*
written and that write errors may occur.

Perhaps you should ask yourself why you are so persistent
in trying to maintain a nonsensical interpretation of the
conformance requirements.