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

[Douglas A. Gwyn]

By your logic, a check that bounces counts as payment.

No, that is *your* logic. My logic is that I have written
the check, even if it should happen to bounce. If somebody
requires me to write a check for a million dollars, I can
comply. If somebody requires me to *pay* a million dollars,
I cannot comply. The standard requires the puts characters
to be written, but whether or not they have some desired
effect lies outside the scope of the standard, as it must.
In any event, the correct interpretation makes sense of the
conformance requirement, whereas the contrary one doesn't.

 

[Dan Pop]

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

^^^^^^^^^^^^^^^^^^^^^^
In which case, the write operation fails and the program doesn't produce
its *intended* output. What is so difficult to understand here?

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

It's not my interpretation that is nonsensical, it's the text of the
standard that is badly written, making my interpretation the most
reasonable one.

If the standard decides to assign to "program output" a meaning that is
at odds with normal usage, then it should provide an explicit definition
in "3. Terms, definitions, and symbols".

Dan

 

[Richard Tobin]

Do write errors ever occur while using the abstract machine?

[/QUOTE]

They're not part of the model. ("Outside the scope of the
standard.")

But surely the the return value of many stdio functions depends on
whether such an error occurs.

-- Richard

 

[James Kuyper]

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

The standard specifies that fputc() returns the character written, or an
EOF if the write failed. Therefore, when an EOF is returned, no write
actually occurred (I suppose you could maintain that the EOF got
written, but AFAIK that's not the way any implementation actually
works). In what sense does this count as output?

It gets even more complicated when you consider buffering, but this
issue remains even for unbuffered streams.

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

Because I don't understand what the sensical interpretation is that
would have been written down, if all of the details about the sensical
one had actually been transferred from your head onto paper. Until I
know how the sensical definition differs from the one that was actually
written down, I can't judge whether or not it's reasonable. I know that
I've tried many times to figure out what a more reasonable definition
would look like, and failed - it's a very difficult thing to do right,
and I'm not at all faulting the author(s) for not doing it perfectly.
I'd love to read your mind to find out what the "more reasonable"
definition is that you believe is actually present in those words.
However, all I get from you is an appeal to "common sense", whatever
that means.

 

[James Kuyper]

No, that is *your* logic. My logic is that I have written
the check, even if it should happen to bounce. If somebody
requires me to write a check for a million dollars, I can
comply. If somebody requires me to *pay* a million dollars,
I cannot comply. The standard requires the puts characters
to be written, but whether or not they have some desired
effect lies outside the scope of the standard, as it must.

I agree, the standard does not require that actual output occur. I would
deny that it's a reasonable interpretation of 7.19.7.3 to say that any
actual writing has occurred when fputc() returns an EOF. However,
whether or not you want to call that "writing", there's no reasonable
sense in which it counts as output. Nothing actually got written
anywhere. Nothing was actually "put" "out", so how could it be output?

The standard defined strict conformance in terms of output, not
"writing". Since actual output lies outside the scope of the standard,
that is the fundamental problem with the definition.

In any event, the correct interpretation makes sense of the
conformance requirement, whereas the contrary one doesn't.

The intended interpretation may make sense of it, but it can't count as
the correct interpretation if the actual words used refer to "output",
rather than "attempted output" or "writing*". The "*" represents a
cross-reference to a clause somewhere explaining this non-standard
meaning for the word "writing"; a meaning which includes the case where
nothing actually gets written anywhere.

 

[David Hopwood]

-----BEGIN PGP SIGNED MESSAGE-----

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.

Since whether a write error occurs is observable by the program ("puts" returns
EOF), it does not matter for Dan Pop's argument whether the write itself occurs.

But that argument is unimportant, since implementation conformance requirements
do not only apply to an implementation's behaviour on running strictly
conforming programs. In fact the definition of strictly conforming programs
plays effectively no role in defining implementation conformance, because of
clause 4 #3:

A program that is correct in all other aspects, operating on correct data,
containing unspecified behavior shall be a correct program and act in
accordance with 5.1.2.3.

There are indeed serious problems with the definitions of implementation
conformance in the standard (not least that "correct in all other aspects"
and "correct data" in 4 #3 are undefined and unclear), but the fact that it
is not possible to write a useful strictly conforming program is not one of
them.

- --
David Hopwood <[email protected]>

Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip


-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: noconv

iQEVAwUBP2Ay3jkCAxeYt5gVAQH1Rwf/d65kdLl22GZ5lLB9IskWqLwg3H9g6AvE
kwHDr1u25E9uH+53YH8jgUVrYCcRdCYLw+l1fzTtp8GSxUP72BCaZpEbfs6K1PKh
0qRG1qlflGtz79t2rP7apBdCwIFmh0mHYm4iaryoH0thXiZ5cBcJ5ffOXDyQLb86
/jiKfK2elNRfbiE3Yn+ei7ZJKQqlBUA5qvoBHza/zepo2HcOp4vMXR+Z7WhTdYwd
09j8HSJvzNQYosuBFy743vluc9iT+5VHVU+WwbdC6IyDEYA5od19d0m7zNmW3sqa
aXnKO7If9J88c5kMiqQ7vxGb5SEoDe5TZhKo2+1XGLOCs8F5yuKDSQ==
=kA6J
-----END PGP SIGNATURE-----

 

[Douglas A. Gwyn]

It's not my interpretation that is nonsensical, it's the text of the
standard that is badly written, making my interpretation the most
reasonable one.

It's not at all reasonable, because it arrives at an absurd
conclusion, namely that the conformance clause has no meaning.
Common sense would tell you that that is far less likely than
that you have chosen a wrong interpretation.

I again remark that you should examine your motivation for
promoting a nonsensical interpretation.

 

[Douglas A. Gwyn]

But surely the the return value of many stdio functions depends on
whether such an error occurs.

Yes, but the circumstances under which I/O errors might
occur remains outside the scope of the standard. There
are no such circumstances defined for the C abstract
machine, but there might be such circumstances for a
realization of the machine.

 

[Douglas A. Gwyn]

The standard specifies that fputc() returns the character written, or an
EOF if the write failed. Therefore, when an EOF is returned, no write
actually occurred (I suppose you could maintain that the EOF got
written, but AFAIK that's not the way any implementation actually
works). In what sense does this count as output?

It says that the character is written, period. If a
write error occurs, instead of returning the character
written the function preemptively returns EOF.

It gets even more complicated when you consider buffering, but this
issue remains even for unbuffered streams.

Not really. The character is written by the call to
fputs (on a valid open stream). Buffering occurs past
that point.

Because I don't understand what the sensical interpretation is that
would have been written down, if all of the details about the sensical
one had actually been transferred from your head onto paper. Until I
know how the sensical definition differs from the one that was actually
written down, I can't judge whether or not it's reasonable. I know that
I've tried many times to figure out what a more reasonable definition
would look like, and failed - it's a very difficult thing to do right,
and I'm not at all faulting the author(s) for not doing it perfectly.
I'd love to read your mind to find out what the "more reasonable"
definition is that you believe is actually present in those words.
However, all I get from you is an appeal to "common sense", whatever
that means.

It means that you shouldn't be having any problem in practice,
only perhaps in your attempt to apply "linguistic analysis",
which you may have been taught as the official philosophical
party line in university.

Once you understand that the obvious "Hello, world!" program is
a strictly conforming program, with 14 characters of output
(including the new-line), essentially all these issues about
buffering, write errors, etc. evaporate. So submit that DR!

 

[Douglas A. Gwyn]

... Nothing was actually "put" "out", so how could it be output?

Yes, it was put out by the program logic, but perhaps it
didn't arrive anywhere.

It is common to describe Fortran WRITE, C printf, etc.
as I/O statements or I/O functions, even though due to
external factors the I or O might not be completely
achieved.

 

[Kevin Easton]

It's not at all reasonable, because it arrives at an absurd
conclusion, namely that the conformance clause has no meaning.
Common sense would tell you that that is far less likely than
that you have chosen a wrong interpretation.

I again remark that you should examine your motivation for
promoting a nonsensical interpretation.

Your interpretation is equally nonsensical, since it leads to the
conclusion that a program that doesn't check for write errors is *less*
portable than one that does so!

- Kevin.

 

[Richard Heathfield]

Douglas A. Gwyn wrote:

Once you understand that the obvious "Hello, world!" program is
a strictly conforming program, with 14 characters of output
(including the new-line), essentially all these issues about
buffering, write errors, etc. evaporate. So submit that DR!

I know that this whole argument must seem very silly to some people, but
IMHO it's vital. If Doug Gwyn is correct about a "Hello, world!" program
being strictly conforming, then the whole comp.lang.c "party line" about
strictly conforming programs is incorrect, and thank heaven for that,
because it makes strict conformance practical and meaningful. On the other
hand, if he is incorrect, well, we ought to be told.

Doug Gwyn and Dan Pop are both C experts. Since they disagree about
something as fundamental as whether "Hello world" programs are strictly
conforming, there is clearly a deficiency in the definition. Having
followed both their arguments, I am not persuaded by either of them (or
rather, I am persuaded by both!).

This really is a significant problem IMHO. Can we sort it out officially,
once and for all, via whatever the appropriate channels are?

(No, I don't know how to raise a DR. If you want, I'll happily raise one, if
someone will point me in the right direction.)

 

[Ross Ridge]

I know that this whole argument must seem very silly to some people, but
IMHO it's vital. If Doug Gwyn is correct about a "Hello, world!" program
being strictly conforming, then the whole comp.lang.c "party line" about
strictly conforming programs is incorrect, and thank heaven for that,
because it makes strict conformance practical and meaningful. On the other
hand, if he is incorrect, well, we ought to be told.

Well, no, saying a hello world program is strictly conforming doesn't mean
the concept is practical. Essentially they're just arguing over whether
the term is completely meaningless or not. If Doug Gwyn is correct we're
still left with very few non-trivial strictly conforming programs that do
anything useful. It's a theoretical concept rather than a practical one.

This really is a significant problem IMHO. Can we sort it out officially,
once and for all, via whatever the appropriate channels are?

I don't see this as being as significant problem. The concept of a
strictly conforming program just delimits the scope of the C standard's
ability to define what a completely and perfectly portable programme is.
That scope is very small, in practice almost non-existant, and given
the scope of the C standard as a whole, as it should be.

"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.

I hope he didn't only come to that realization at that late of a date.

Ross Ridge

 

[Richard Heathfield]

Well, no, saying a hello world program is strictly conforming doesn't mean
the concept is practical. Essentially they're just arguing over whether
the term is completely meaningless or not. If Doug Gwyn is correct we're
still left with very few non-trivial strictly conforming programs that do
anything useful. It's a theoretical concept rather than a practical one.

On the contrary, if "hello world" is strictly conforming, then so are a vast
range of filter programs. If we can read input and write output and remain
strictly conforming, then millions of *useful* and distinctly non-trivial C
programs can be strictly conforming too.

<snip>

 

[Ross Ridge]

I know that this whole argument must seem very silly to some people, but
IMHO it's vital. If Doug Gwyn is correct about a "Hello, world!" program
being strictly conforming, then the whole comp.lang.c "party line" about
strictly conforming programs is incorrect, and thank heaven for that,
because it makes strict conformance practical and meaningful. On the other
hand, if he is incorrect, well, we ought to be told.

Well, no, saying a hello world program is strictly conforming doesn't mean
the concept is practical. Essentially they're just arguing over whether
the term is completely meaningless or not. If Doug Gwyn is correct we're
still left with very few non-trivial strictly conforming programs that do
anything useful. It's a theoretical concept rather than a practical one.

On the contrary, if "hello world" is strictly conforming, then so are a vast
range of filter programs. If we can read input and write output and remain
strictly conforming, then millions of *useful* and distinctly non-trivial C
programs can be strictly conforming too.

Millions of filter programs? I don't think so. But few of the filter
programs that actually exist are going to strictly conforming for
one reason or another. Most are going to assume things like ASCII,
twos-complement arithmetic, 32-bit ints, and non-standard library
functions. It doesn't take much to make your program not strictly
conforming, just using a dollar sign character ($) in a literal is enough.

Ross Ridge

 

[Richard Heathfield]

Millions of filter programs? I don't think so.

I didn't make myself clear. Millions of such programs /could be written/.

But few of the filter
programs that actually exist are going to strictly conforming for
one reason or another. Most are going to assume things like ASCII,
twos-complement arithmetic, 32-bit ints, and non-standard library
functions.

Maybe other people's, yes. When I write a C program, however, I generally
take some care in an attempt to ensure that, if I /can/ write it in a way
that Doug Gwyn would call strictly conforming, then I /do/ write it in that
way. That includes obvious things like "don't assume ASCII" and so on.

I have a couple of good reasons for doing this. Although it is true that I
haven't used a non-ASCII system for about four years now, I have written
quite a few programs for such systems, and I would not be at all surprised
to find myself working on such systems again in the future. I would like to
be able to re-use my C code on such systems. Also, I have published work in
the past which included the source code to programs intended to be portable
to any hosted environment, and I expect to do so again in the future. So
"strictly conforming" code is my ideal. Up until now, I have assumed it was
an unrealisable ideal. If "hello world" is strictly conforming, that is
very good news for me. That you see it as less useful is fair enough; I
don't suppose that /everyone/ has a use for strictly conforming code.

It doesn't take much to make your program not strictly
conforming, just using a dollar sign character ($) in a literal is enough.

Since I have almost no use for the dollar sign, this isn't a major problem.

 

[Larry__Weiss]

... If "hello world" is strictly conforming, that is
very good news for me.

Maybe it's time for someone to post the source to that
strictly conforming "hello world" program. I can think
of several ways to write a "hello world" program in C,
but I'm not sure if all of them (or any of them for that
matter) are strictly conforming.

- Larry Weiss

 

[Richard Heathfield]

Maybe it's time for someone to post the source to that
strictly conforming "hello world" program. I can think
of several ways to write a "hello world" program in C,
but I'm not sure if all of them (or any of them for that
matter) are strictly conforming.

Here are some candidate programs:

1) puts

#include <stdio.h>

int main(void)
{
puts("Hello world");
return 0;
}

If that is strictly conforming, presumably this one is, too:

#include <stdio.h>

int main(void)
{
printf("%s\n", "Hello world");
return 0;
}

2) I/O and memory

#include <stdio.h>
#include <string.h>
#include <stdlib.h>

#define SIZE 512

int main(void)
{
char *p = NULL;
char line = malloc(SIZE);
if(line != NULL)
{
p = fgets(line, SIZE, stdin);
if(p != NULL)
{
p = strchr(line, '\n');
if(p != NULL)
{
printf("Hello %s\n", line);
}
else
{
fprintf(stderr, "You talk too much.\n");
}
}
else
{
fprintf(stderr, "Nothing to say?\n");
}
free(line);
}
else
{
fprintf(stderr, "Low on RAM?\n");
}

return 0;
}

If (1) is strictly conforming, then some useful sc apps can be written.

If (2) is strictly conforming, then sc programs are very practical indeed,
and fall into the category that some people in comp.lang.c currently call
"comp.lang.c-conforming".

 

[Ben Pfaff]

When I write a C program, however, I generally take some care
in an attempt to ensure that, if I /can/ write it in a way that
Doug Gwyn would call strictly conforming, then I /do/ write it
in that way.

It is often observed that programs should be written with the
purpose of being read by another programmer. This is the first
time, however, that I have heard it suggested that the other
programmer should in particular be Doug Gwyn.

 

[Douglas A. Gwyn]

(No, I don't know how to raise a DR. If you want,
I'll happily raise one, if someone will point me
in the right direction.)

I think the DR submission procedure has been described before
in this newsgroup, by people who have an "official" position
within the standards organization, and perhaps it can be
found in a Web archive. Here is my attempt to summarize it:
Defect Reports are accepted from "national bodies" that are
members of ISO/IEC JTC1/SC22/WG14, or at the discretion of
the Convenor of that Working Group. The US national body is
NCITS J11, of which I am a member; a handful of other nations
have analogous actively participating bodies. The originator
of the DR could be *any*body, but to get it into channels
they need to find a national body member to put it forth.
You can probably find willing a volunteer *if* you have a
convincing case that there is a *practical* problem that
deserves a slice of the scarce committee resources to address,
and *if* you format the DR sufficiently close to the norm for
DRs; see the DR log on the WG14 Web site for examples. It
helps a lot to give specific examples that highlight the
problem, to list reasonable alternatives for solving the
problem, and to suggest specific changes to the wording of
the standard that might resolve the problem. If a DR is too
vague or insufficiently convincing, it isn't likely to elicit
a favorable response.