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

[Douglas A. Gwyn]

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.

It is certainly true that most of today's commercial software
cannot be implemented as strictly conforming C programs, because
they must interface to system-specific facilities (such as bitmap
graphics) that are not specified by the C standard itself. But
the role of strict conformance in establishing the "treaty point"
between the C provider and the C consumer is extremely practical,
and the vast majority of code in many major applications could be
implemented using code that is suitable for use in strictly-
conforming programs, which is usually a good idea since it
facilitates porting the application to a different platform.

It is also the case that a great many useful programs *can* be
implemented as strictly conforming C programs, if their operating
context is similar to that of the traditional Unix "shell"
environment. (I.e. a command-line interface.) I have a large
collection of useful programs, used for example in cryptanalysis,
that are either strictly conforming to the C standard or else
could readily be made strictly conforming.

 

[Douglas A. Gwyn]

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

Indeed, if you are clueless about software portability then
it is unlikely you are going to write s.c. C programs. That
is, however, an argument against being clueless, not against
the utility of writing s.c. programs.

 

[Richard Heathfield]

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.

<grin> Well, I /hope/ you know what I mean. I don't particularly have DG in
mind when I cut C code.

Having said that, sometimes when I'm writing C code, I can't quite shake the
notion that clc, csc, and the committee are staring at the screen over my
shoulder. This generally takes care of any shortcuts I might otherwise be
tempted to use.

 

[Douglas A. Gwyn]

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".

Assuming the obvious typo is fixed, I would say that (2)
is *arguably* s.c., with the concern of course being that
its behavior depends on environmental factors (other than
locale). But it stays as close to being as unarguably s.c.
as it can while dealing with those factors, which is a
whole lot better than incorporating unnecessary
dependencies on such characteristics as word size.

Any program that makes essential use of the command-line
arguments, for example, is going to face the issue of
output depending on something that the C standard does
not (and cannot) specify. For C99 we clarified that the
term "unspecified behavior" in the compliance clause does
*not* refer to such situations. I have no doubt that there
are instances (possibly including the malloc specification)
where clarification about this matter could be useful, and
I, among others, have long argued that the C standard could
benefit from more work on the requirements for compliance.
But there hasn't yet emerged a consensus that there is
enough of a problem to justify such an effort. The fact
that some pedants can find ways to misconstrue the wording
isn't convincing, although perhaps if those pedants have
managed to confuse enough programmers that it is harming
the cause of C source code portability, that might be
sufficient reason to do something about it.

 

[Douglas A. Gwyn]

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.

On its way into C99 some of the context seems to have gotten
scraped off that. It is meant merely to point out that
"unspecified behavior" really does not mean "undefined behavior";
its definition for C99 is substantially different, and this bit
was meant in support of that change. I would agree that it
doesn't convey much if one doesn't already understand it, which
is certainly sufficient reason to fix it. I think I once argued
that it should simply be deleted.

 

[Richard Heathfield]

Douglas A. Gwyn wrote:

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.

Well, in that case I urge a national body member, already experienced in
composing DRs, to compose an appropriate DR, and I'll leave it at that. I
appreciate that no national body member might consider it worth the time,
but at present the status of "strict conformance" is a laughing-stock,
perhaps wrongly. If the committee want the Standard to be respected, they
might want to consider making it a little more respectable, and this is one
very simple way they can do it.

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.

I think you and Dan Pop have, between you, made the case very convincing
indeed. Clearly, if two C experts disagree so much over such a simple
thing, the simple thing isn't properly defined by the Standard, which is
therefore defective.

 

[Douglas A. Gwyn]

I think you and Dan Pop have, between you, made the case very convincing
indeed. Clearly, if two C experts disagree so much over such a simple
thing, the simple thing isn't properly defined by the Standard, which is
therefore defective.

That's not as clear as you make it out to be.
Anyway, the case needs to be made convincingly to the
standards committee, and they have seen many previous
examples of pedantic misconstrual of wording where
nobody involved in actual implementation or programming
seemed to have a problem understanding the intent.
When it comes to vendor conformance and validation
testing, this specific issue has not (to my knowledge)
come up in the real world.

 

[LibraryUser]

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".

After which the use of the isXXX() and toXXX() functions/macros
in ctype.h greatly extend the portable aspects.

 

[Richard Heathfield]

That's not as clear as you make it out to be.
Anyway, the case needs to be made convincingly to the
standards committee,

No, the standards committee has a choice. Either they want the concept of
"strict conformance" to be taken seriously, or they don't. If they don't,
fine; we'll carry on laughing at it.

and they have seen many previous
examples of pedantic misconstrual of wording where
nobody involved in actual implementation or programming
seemed to have a problem understanding the intent.

The intent you have expressed in this thread is at odds with the
interpretation generally accepted in comp.lang.c. I would argue, therefore,
that from /your/ point of view, people involved in actual programming have
a problem understanding the intent.

When it comes to vendor conformance and validation
testing, this specific issue has not (to my knowledge)
come up in the real world.

I don't think the issue here is to do with vendor conformance. We already
know that vendors aren't too fussed about strict conformance to ISO C90,
and not in the slightest bit fussed about conforming to C99. On the
programming side, however, it matters. A C programmer doesn't stop being a
"real world" programmer the moment he subscribes to comp.lang.c.

You have expressed a view of strict conformance which I find refreshingly
positive, but it is difficult for me to justify adopting this view myself
in the light of the actual wording of the text. If the committee aren't
fussed enough to clarify this, I guess clc will have to continue to assume
that there ain't no such animal as a useful, strictly-conforming program
other than, perhaps, the canonical IEFBR14.

 

[Gabriel Dos Reis]

| The intent you have expressed in this thread is at odds with the
| interpretation generally accepted in comp.lang.c.

and Doug's view is also at odds with those of several C experts.

A fair conclusion that can be drawn is that the notion of "strict
conformance" as defined in the Standard is close to useless, in practice.

-- Gaby

 

[Ross Ridge]

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.

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

But since they haven't been written and won't be written this makes
a strictly conforming program a much more theoretical concept than a
practical one. Strictly conforming programmes are class of programs
that in theory could be written but in practice aren't.

Ross Ridge

 

[Ross Ridge]

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.

... But the role of strict conformance in establishing the "treaty point"
between the C provider and the C consumer is extremely practical ...

Strict conformance doesn't establish this "treaty point", if it did
the C standard itself would be useless. I can't use "$" in a literal
in a strictly conforming programme, but the C standard still provides
guarantees about what happens if you use "$" character in a string
literal. If "$" is valid character in the appropriate character sets,
a compiler can't use "$" in a literal as a token indicating Bourne shell
like variable substution.

Ross Ridge

 

[James Kuyper]

It says that the character is written, period.

It also says that it returns the character written, period. It then
follows that period by explaining that in the event of an error, it
returns an EOF. You can decide whether this overrides the statement
about writing a character, or you can decide that it instead overrides
the statement about the return value, but it has to override one or the
other; unless the character written was EOF, they can't both be true in
the case where it fails. You can say that writing has occured if you
wish, but if you claim that output must also have occurred, you're being
inconsistent with actual practice. I hope your interpretation is
incorrect, but if it isn't then any implementation that fails to produce
output, despite a write error, is non-conforming, and that includes just
about every implementation I've ever used.

....

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.

That criticism has almost nothing to do with any aspect of the reality
that I'm aware of. I was going to give a more in-depth explanation of
why it's meaningless, but I realized it didn't serve any purpose.

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've tried figuring out what conclusion I would reach if I got an answer
that said that the "Hello, world!" program is strictly conforming. I
don't see how it would make those issues evaporate, it would merely
render them more mysterious. I don't see how you decide, given two
different cases where the actual output is affected by
implementation-defined behavior, and decide which ones are strictly
conforming and which are not. In this particular case, it seems to be
based upon some bizarre kind of confusion between calling a function to
write characters to the output file or device, and actual output to that
file or device. However, I'm worried that there are yet more ways in
which it can occur that haven't even come up in these discussions. I'm
much happier relying upon the actual words of the standard, than trying
to figure out what words would have been written if your actual intent
for the clause had been successfully communicated.

 

[James Kuyper]

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.

It's even more likely that the words as written do not support the
correct interpretation.

 

[James Kuyper]

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

If it didn't arrive anywhere, it wasn't put out.

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.

Wait a minute - here you're saying that O, meaning "output", is not
necessarily achieved by a call to printf()? I'm in perfect agreement
there, but I thought that was precisely what we were disagreeing about.
If output isn't necessarily achieved, then the output of the program is
different from what it would have been had it been achieved. The reasons
why it can fail to be achieved are at best implemention-defined, and
possibly even completely unspecified. Therefore, the program that
attempts the output is not strictly conforming.

 

[James Kuyper]

David Hopwood wrote:
....

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.

We were discussing the problems with definitions of code conformance,
not implementation conformance. That's a different issue; the definition
of implementation conformance is in much better condition than the
definitions of code "conformance" and "strict conformance".

 

[Keith Thompson]

That's not as clear as you make it out to be.
Anyway, the case needs to be made convincingly to the
standards committee, and they have seen many previous
examples of pedantic misconstrual of wording where
nobody involved in actual implementation or programming
seemed to have a problem understanding the intent.
When it comes to vendor conformance and validation
testing, this specific issue has not (to my knowledge)
come up in the real world.

Perhaps that's because strict conformance isn't really a requirement
for anything.

The problem being discussed here is that the definition of strict
conformance is (allegedly) too narrow. That's not a problem for
implementers. They have to guarantee that the implementation will
accept any strictly conforming program; the narrower the definition,
the easier that is.

That's also not a real problem for programmers. If I can't write my
program in a strictly conforming manner, I'm not going to tear my hair
out trying to make it fit; I'll just write it as cleanly and portably
as I can, and not worry about strict conformance. Nothing requires me
to write strictly conforming code.

Strict conformance *seems* to be an important concept, but as far as I
can tell it's almost entirely ignored in the real world (a term that,
as I use it here, excludes Usenet). That's why it hasn't been an
issue for vendor conformance and validation testing. It's also why
the definition needs to be fixed, either by re-wording it or by
clearly and officially interpreting it.

 

[Douglas A. Gwyn]

... unless the character written was EOF, ...

That's not physically possible, on the vast majority of
implementations.

... I hope your interpretation is
incorrect, but if it isn't then any implementation that fails to produce
output, despite a write error, is non-conforming, ...

You apparently still don't understand what you call my
"interpretation".

I don't see how it would make those issues evaporate, ...

Ditto. Go back and examine the argumentation that has been
made in the past to justify claims that any program that
performs output cannot be s.c.

 

[Douglas A. Gwyn]

Wait a minute - here you're saying that O, meaning "output", is not
necessarily achieved by a call to printf()? I'm in perfect agreement
there, but I thought that was precisely what we were disagreeing about.
If output isn't necessarily achieved, then the output of the program is
different from what it would have been had it been achieved. The reasons
why it can fail to be achieved are at best implemention-defined, and
possibly even completely unspecified. Therefore, the program that
attempts the output is not strictly conforming.

No, to the contrary I have been saying that what printf is
instructed to produce constitutes (that part of) the
program's output. Environmental factors beyond the scope
of the standard might interfere with that data appearing
in the intended place, but it was nevertheless output,
insofar as is meant under the compliance clause.

I understand that you can repeat an incorrect argument
to support a contrary claim. I'm telling you what was
meant, and that the contrary interpretation is silly.

 

[Douglas A. Gwyn]

The problem being discussed here is that the definition of strict
conformance is (allegedly) too narrow. That's not a problem for
implementers. They have to guarantee that the implementation will
accept any strictly conforming program; the narrower the definition,
the easier that is.

What I said was that implementors have not been resorting
to such sophistry. Generally speaking they have understood
the compliance requirement quite well (along the lines that
I have explained). Actually I suspect that most of the
pedantic counterarguers understand what is meant quite well
also, but for reasons of their own choose to misrepresent
the requirements.

Strict conformance *seems* to be an important concept, but as far as I
can tell it's almost entirely ignored in the real world ...

That not so, since it is an important component of
programming for portability, which is economically
important.

Hopefully the *wrong* propaganda being promulgated by
opponents of the C standard is recognized as such and
is generally disregarded by real-world programmers.