Are commands such as getch() only for DOS programs?
Brian
cputs("This is within the window\r\n");
etc
only used when creating a program that is to be run in DOS?
Regards Brian
Mike Wahler
Brian <bcl...@es.co.nz> wrote in message
news:4476uu0ukl6c75e78...@4ax.com...
I suspect a function (there are no 'commands' in C or C++)
called 'getch()' which is provided with the Borland C++
Builder product is only intended for use with or guaranteed
to work with, the Borland C++ Builder product. See your
product documentation to see what targets it supports and
how to build them.
This function 'getch()' is certainly not part of either
the ISO standard C or C++ languages or libraries, the
only topics here.
See www.usenet.org and/or www.groups.google.com to locate
newsgroups where you can get help with your particular
Borland product. Also don't forget that Borland hosts
good quality support resources at www.borland.com
More information about this newsgroup:
http://snurse-l.org/acllc-c++/faq.html
-Mike
>
> Regards Brian
>
>
>
R124c4u2
WRT getch(). No, it is not confined to DOS use. It can be used in the EasyWin
environment, for example. But it does potentially cause problems when its
usage is mixed with the more conventional I/0. You could search google groups
for elaboration on that. I never used the other call.
those who know me have no need of my name
>Are commands in Borland C++ builder such as getch()
>cputs("This is within the window\r\n");
since the standard doesn't define these functions they can do anything,
anywhere. by that i mean that a different compiler on the same platform
may not support it, or it may do something other than what you expect (has
different semantics); ditto different platforms.
--
bringing you boring signatures for 17 years
Chris Newton
Many libraries that do "console I/O" have functions in them by those
names, so they aren't necessarily just for DOS systems. The functions
aren't standard, though, so what you get varies from system to system
(or may not be there at all). The only way to be sure of the details is
to check the docs for your specific compiler, or ask in a group
specifically for C++ Builder.
HTH,
Chris
Paul
Mike Wahler <mkwa...@mkwahler.net> wrote in message
news:arv7p9$un4$1...@slb5.atl.mindspring.net...
>
> Brian <bcl...@es.co.nz> wrote in message
> news:4476uu0ukl6c75e78...@4ax.com...
> > Are commands in Borland C++ builder such as getch()
> > cputs("This is within the window\r\n");
> > etc
> > only used when creating a program that is to be run in DOS?
>
> I suspect a function (there are no 'commands' in C or C++)
> called 'getch()' which is provided with the Borland C++
> Builder product is only intended for use with or guaranteed
> to work with, the Borland C++ Builder product. See your
> product documentation to see what targets it supports and
> how to build them.
>
> This function 'getch()' is certainly not part of either
> the ISO standard C or C++ languages or libraries, the
> only topics here.
Nice of you to redirct the OP, it's a pity you added this piece of
misleading information to your post.
The function getch() is a perfectly good piece of code , can you point out
exactly which piece of code in the Conio.h library does not conform to the
ISO standards? And if the conio.h library does not conform to the
<EM>latest</EM> ISO standards this certainly does not justify your
indicating that is not a proper part of the C or C++ language.
If you choose to redirect thats fine but do not attempt to teach or dictate
your false interpretation of the languages topical to this newsgroup
:-)
>
> See www.usenet.org and/or www.groups.google.com to locate
> newsgroups where you can get help with your particular
> Borland product. Also don't forget that Borland hosts
> good quality support resources at www.borland.com
>
> More information about this newsgroup:
> http://snurse-l.org/acllc-c++/faq.html
*PLONK*
>
> -Mike
>
> >
> > Regards Brian
> >
> >
> >
>
>
Josh Sebastian
<paulcr<nospambots>@noplacespecial.fsworld.co.uk> wrote:
>Mike Wahler <mkwa...@mkwahler.net> wrote in message
>news:arv7p9$un4$1...@slb5.atl.mindspring.net...
>>
>> This function 'getch()' is certainly not part of either
>> the ISO standard C or C++ languages or libraries, the
>> only topics here.
>
>Nice of you to redirct the OP, it's a pity you added this piece of
>misleading information to your post.
>The function getch() is a perfectly good piece of code , can you point out
>exactly which piece of code in the Conio.h library does not conform to the
>ISO standards?
If you try to use one of the functions on a conforming compiler with
no extensions (ie, a purely standards-conforming compiler), it will
fail to link, as the functions will all be undefined.
>And if the conio.h library does not conform to the
><EM>latest</EM> ISO standards this certainly does not justify your
>indicating that is not a proper part of the C or C++ language.
It doesn't conform to *any* of the ISO standards, latest or otherwise.
And he said it's not part of the "ISO standard C or C++ languages or
libraries"... are you really disagreeing with that statement?
>> More information about this newsgroup:
>> http://snurse-l.org/acllc-c++/faq.html
>
>*PLONK*
Oooh... oooh... plonk me! Plonk me!!
Josh
Paul
Josh Sebastian <cur...@cox.net> wrote in message
news:3d28uuccfjhfocgnu...@4ax.com...
> On Tue, 26 Nov 2002 23:33:29 -0000, "Paul"
> <paulcr<nospambots>@noplacespecial.fsworld.co.uk> wrote:
>
> >Mike Wahler <mkwa...@mkwahler.net> wrote in message
> >news:arv7p9$un4$1...@slb5.atl.mindspring.net...
> >>
> >> This function 'getch()' is certainly not part of either
> >> the ISO standard C or C++ languages or libraries, the
> >> only topics here.
> >
> >Nice of you to redirct the OP, it's a pity you added this piece of
> >misleading information to your post.
> >The function getch() is a perfectly good piece of code , can you point
out
> >exactly which piece of code in the Conio.h library does not conform to
the
> >ISO standards?
>
> If you try to use one of the functions on a conforming compiler with
> no extensions (ie, a purely standards-conforming compiler), it will
> fail to link, as the functions will all be undefined.
Obviously if the particular system did not have that particular library
installed it would be undefined on any compiler be it conforming or non
conforming.
>
> >And if the conio.h library does not conform to the
> ><EM>latest</EM> ISO standards this certainly does not justify your
> >indicating that is not a proper part of the C or C++ language.
>
> It doesn't conform to *any* of the ISO standards, latest or otherwise.
And how can you prove this?
My copy of is documented to conform to older standards.
>
> And he said it's not part of the "ISO standard C or C++ languages or
> libraries"... are you really disagreeing with that statement?
I am disagreeing with the fact that he appears to be suggesting that its not
part of the C or C++ programming language as he stated at the top of his
post "there are no 'commands' in C or C++)
called 'getch()'" which you seem to have conveniently removed from your
reply.
Josh Sebastian
<paulcr<nospambots>@noplacespecial.fsworld.co.uk> wrote:
>Josh Sebastian <cur...@cox.net> wrote in message
>news:3d28uuccfjhfocgnu...@4ax.com...
>> On Tue, 26 Nov 2002 23:33:29 -0000, "Paul"
>> <paulcr<nospambots>@noplacespecial.fsworld.co.uk> wrote:
>>
>> >Mike Wahler <mkwa...@mkwahler.net> wrote in message
>> >news:arv7p9$un4$1...@slb5.atl.mindspring.net...
>> >>
>> >> This function 'getch()' is certainly not part of either
>> >> the ISO standard C or C++ languages or libraries, the
>> >> only topics here.
>> >
>> >Nice of you to redirct the OP, it's a pity you added this piece of
>> >misleading information to your post.
>> >The function getch() is a perfectly good piece of code , can you point
>out
>> >exactly which piece of code in the Conio.h library does not conform to
>the
>> >ISO standards?
>>
>> If you try to use one of the functions on a conforming compiler with
>> no extensions (ie, a purely standards-conforming compiler), it will
>> fail to link, as the functions will all be undefined.
>
>Obviously if the particular system did not have that particular library
>installed it would be undefined on any compiler be it conforming or non
>conforming.
If it doesn't include certain libraries (the standard library), it is
by definition non-conforming. A conforming compiler is allowed to not
include the libraries necessary for <conio.h>. That was my point, in
its entirety. I'm not saying that a standard conforming compiler must
*reject* the code, but it need not *accept* the code.
>> >And if the conio.h library does not conform to the
>> ><EM>latest</EM> ISO standards this certainly does not justify your
>> >indicating that is not a proper part of the C or C++ language.
>>
>> It doesn't conform to *any* of the ISO standards, latest or otherwise.
>And how can you prove this?
>My copy of is documented to conform to older standards.
Borland C 3.0 probably conformed very closely to the ISO C90 standard,
in that it was possible to compile ISO C90 programs on it. (I really
don't know -- I never checked it for conformance.) That doesn't mean
that *everything* that compiles on Borland C 3.0 conforms to ISO C,
however. Borland C 3.0 is "ISO C and then some" (or "ISO C with
extensions"). <conio.h> is one of many extensions.
The most recent standard for C++ is the *only* standard for C++, and
the standard is newer than the Borland C++ 3.0 compiler by several
years. As a result, your compiler is missing several features of
modern C++ (it has only the most rudimentary template support, for
example). This doesn't make it *bad* or *unuseful*. It's just a fact
that that compiler is a particularly poor judge of the C++ language as
it currently exists. I think there was a note in the documentation for
my copy of Borland C++ 3.1 that said it was compatible with AT&T C++
3.0... but that's just compatibility with another compiler -- there
was no standard back then.
>> And he said it's not part of the "ISO standard C or C++ languages or
>> libraries"... are you really disagreeing with that statement?
>
>I am disagreeing with the fact that he appears to be suggesting that its not
>part of the C or C++ programming language as he stated at the top of his
>post "there are no 'commands' in C or C++)
>called 'getch()'" which you seem to have conveniently removed from your
>reply.
My mistake; I got the impression that you were objecting to his last
paragraph (which I didn't snip out). Anyway, Mike is correct. There
are *no* "commands" in C or C++. They don't have "commands"; they have
functions, objects, macros, and keywords. So even if getch were part
of the language, it would not be a command.
Terminology is important.
Josh
Paul
But just because the code is non comforming does not mean to say it is not C
or C++ code as mike implied.
rjh
>
> Mike Wahler <mkwa...@mkwahler.net> wrote in message
> news:arv7p9$un4$1...@slb5.atl.mindspring.net...
>>
>> Brian <bcl...@es.co.nz> wrote in message
>> news:4476uu0ukl6c75e78...@4ax.com...
>> > Are commands in Borland C++ builder such as getch()
>> > cputs("This is within the window\r\n");
>> > etc
>> > only used when creating a program that is to be run in DOS?
>>
>> I suspect a function (there are no 'commands' in C or C++)
>> called 'getch()' which is provided with the Borland C++
>> Builder product is only intended for use with or guaranteed
>> to work with, the Borland C++ Builder product. See your
>> product documentation to see what targets it supports and
>> how to build them.
>>
>> This function 'getch()' is certainly not part of either
>> the ISO standard C or C++ languages or libraries, the
>> only topics here.
>
> Nice of you to redirct the OP, it's a pity you added this piece of
> misleading information to your post.
The information Mike posted is correct, and not misleading.
> The function getch() is a perfectly good piece of code , can you point out
> exactly which piece of code in the Conio.h library
The conio.h header supplied by Borland is not a library. It's a header.
> does not conform to
> the ISO standards?
Can you show us the source code to getch()? Since it's not part of the
Standard C or C++ languages or libraries, we can't tell whether the
function itself conforms without looking at it.
> And if the conio.h library does not conform to the
> <EM>latest</EM> ISO standards this certainly does not justify your
> indicating that is not a proper part of the C or C++ language.
Headers are headers, and libraries are libraries. Terminology matters. I see
no reason to think that getch() is a "proper part" of the C or C++
language. I can see how it might be a useful extension for those fortunate
enough to have it, but that's not the same thing at all.
> If you choose to redirect thats fine but do not attempt to teach or
> dictate your false interpretation of the languages topical to this
> newsgroup
> :-)
I see nothing false about Mike's interpretation.
--
Richard Heathfield : bin...@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
Paul
rjh <bin...@eton.powernet.co.uk> wrote in message
news:as1kma$d5l$1...@venus.btinternet.com...
> Paul wrote:
>
> >
> > Mike Wahler <mkwa...@mkwahler.net> wrote in message
> > news:arv7p9$un4$1...@slb5.atl.mindspring.net...
> >>
> >> Brian <bcl...@es.co.nz> wrote in message
> >> news:4476uu0ukl6c75e78...@4ax.com...
> >> > Are commands in Borland C++ builder such as getch()
> >> > cputs("This is within the window\r\n");
> >> > etc
> >> > only used when creating a program that is to be run in DOS?
> >>
> >> I suspect a function (there are no 'commands' in C or C++)
> >> called 'getch()' which is provided with the Borland C++
> >> Builder product is only intended for use with or guaranteed
> >> to work with, the Borland C++ Builder product. See your
> >> product documentation to see what targets it supports and
> >> how to build them.
> >>
> >> This function 'getch()' is certainly not part of either
> >> the ISO standard C or C++ languages or libraries, the
> >> only topics here.
> >
> > Nice of you to redirct the OP, it's a pity you added this piece of
> > misleading information to your post.
>
> The information Mike posted is correct, and not misleading.
misleading actually.
>
> > The function getch() is a perfectly good piece of code , can you point
out
> > exactly which piece of code in the Conio.h library
>
> The conio.h header supplied by Borland is not a library. It's a header.
into the project.
Your being very picky here.
>
> > does not conform to
> > the ISO standards?
>
> Can you show us the source code to getch()? Since it's not part of the
> Standard C or C++ languages or libraries, we can't tell whether the
> function itself conforms without looking at it.
[OT]
If the getch() function is not written in C or C++ which language do you
suggest it is written in?
[snip]
Strangely Placed
> rjh <bin...@eton.powernet.co.uk> wrote in message
> news:as1kma$d5l$1...@venus.btinternet.com...
> > Paul wrote:
> >
> > >
> > > Mike Wahler <mkwa...@mkwahler.net> wrote in message
> > > news:arv7p9$un4$1...@slb5.atl.mindspring.net...
> > >>
> > >> This function 'getch()' is certainly not part of either
> > >> the ISO standard C or C++ languages or libraries, the
> > >> only topics here.
> > >
> > > Nice of you to redirct the OP, it's a pity you added this piece of
> > > misleading information to your post.
> >
> > The information Mike posted is correct, and not misleading.
>
> To say that there are no commands in C or C++ called getch() is quite
> misleading actually.
No, it isn't. Neither C nor C++ have commands. This getch() thing that
you keep going on about has the syntax of a function or a macro call.
Borland supply a getch() function as an extension. The kind folks who
wrote the ncurses library /also/ supply a getch() function as an
extension. Its behaviour and semantics are rather different to the
Borland version.
> >
> > > The function getch() is a perfectly good piece of code , can you point
> out
> > > exactly which piece of code in the Conio.h library
> >
> > The conio.h header supplied by Borland is not a library. It's a header.
> But the conio.h header includes the library
No, it doesn't. You include headers. You link libraries. The conio.h
header supplied by Borland does not include any libraries whatsoever.
> which allows the use of getch()
> into the project.
The conio.h header supplied by Borland tells the compiler there is an
external function called getch(), and gives its prototype. This
information is sufficient to allow the compiler to compile code that
calls this external function. It is the linker's job to link the
appropriate library into the program.
> Your being very picky here.
Of course. Would you rather I went round giving out misleading and
incorrect information? On language issues, those are your choices -
right or wrong. "There is no try", as Yoda rightly said.
> > > does not conform to
> > > the ISO standards?
> >
> > Can you show us the source code to getch()? Since it's not part of the
> > Standard C or C++ languages or libraries, we can't tell whether the
> > function itself conforms without looking at it.
>
> [OT]
> If the getch() function is not written in C or C++ which language do you
> suggest it is written in?
Which getch() function do you mean? Do you mean Borland's, or the GNU
ncurses version, or my version, or your version, or Microsoft's
version, or whose version?
Anyway, it could be implemented in almost any programming language;
assembly language, Pascal, Ada, Fortran, COBOL, C, C++, whatever. In
fact, it is perfectly possible to write a getch() function in strictly
conforming C, as I will now demonstrate:
int getch(void)
{
static int ch;
ch %= 1000;
return ++ch;
}
This doesn't do what you might expect getch() to do, but the Standard
doesn't guarantee (or even mention) the behaviour of a getch()
function, so I'm free to make it do what I like. Do you see yet?
--
Richard Heathfield @ weird location
Paul
Strangely Placed <bin...@eton.powernet.co.uk> wrote in message
news:acec90c3.02112...@posting.google.com...
> "Paul" <paulcr<nospambots>@noplacespecial.fsworld.co.uk> wrote in message
news:<as1qu0$5mo$1...@news6.svr.pol.co.uk>...
> > rjh <bin...@eton.powernet.co.uk> wrote in message
> > news:as1kma$d5l$1...@venus.btinternet.com...
> > > Paul wrote:
> > >
> > > >
> > > > Mike Wahler <mkwa...@mkwahler.net> wrote in message
> > > > news:arv7p9$un4$1...@slb5.atl.mindspring.net...
> > > >>
> <snip>
> > > >> This function 'getch()' is certainly not part of either
> > > >> the ISO standard C or C++ languages or libraries, the
> > > >> only topics here.
> > > >
> > > > Nice of you to redirct the OP, it's a pity you added this piece of
> > > > misleading information to your post.
> > >
> > > The information Mike posted is correct, and not misleading.
> >
> > To say that there are no commands in C or C++ called getch() is quite
> > misleading actually.
>
> No, it isn't. Neither C nor C++ have commands. This getch() thing that
> you keep going on about has the syntax of a function or a macro call.
> Borland supply a getch() function as an extension. The kind folks who
> wrote the ncurses library /also/ supply a getch() function as an
> extension. Its behaviour and semantics are rather different to the
> Borland version.
Is getch() is neither C or C++.
Can you please explain which programming language this function is written
in then?
[snip]
Josh Sebastian
<paulcr<nospambots>@noplacespecial.fsworld.co.uk> wrote:
>[OT]
>If the getch() function is not written in C or C++ which language do you
>suggest it is written in?
I *know* what language they're written in, on my implementation (the
one that has them, anyway). They're written in assembler.
What was your point again?
Josh
Karl Heinz Buchegger
But it really doesn't matter.
It could have been written in any other language as well, as long
as the calling mechanism is compatible to the one used by the C
or C++ compiler.
--
Karl Heinz Buchegger
kbuc...@gascad.at
Josh Sebastian
Yep. In fact I'm sure some of my standard library was written in
assembly. That's not the point. The point is, Paul doesn't know what
he's talking about. He doesn't know what makes something conforming C
or C++; he doesn't know what makes something portable; he doesn't know
what makes something part of the language versus an extension.
And he's basing his arguments on his faulty knowledge. Anyone who
really knows about these things can see how misguided Paul is. But
this is a learning newsgroup, so there will be plenty of people who
*can't* tell the bullshit from the truth. I don't want them thinking
Paul knows this stuff. So when he gives me an opportunity to easily
and completely contradict him -- with evidence to back me up -- I'll
jump on it. The more obvious he makes his lack of knowledge, the
better.
Josh
rjh
<snip>
> Is getch() is neither C or C++.
> Can you please explain which programming language this function is written
> in then?
Which getch()? The Borland getch()? The ncurses getch()? My getch()? Your
getch()?
Here's a C version which I've also posted elsethread:
int getch(void)
{
static int ch = 0;
ch %= 1000;
return ++ch;
}
Okay, from now on, when you talk about getch(), I'll presume you mean this
one, since you haven't given me any information to the contrary.
I can therefore categorically answer your question: my getch() is written in
C. But it doesn't do what Borland's getch() does. And it doesn't do what
the ncurses getch() does. And those two getch() functions don't do the same
as each other.
What a confusing world it can be when you step outside of the Standard.
Paul
> On Wed, 27 Nov 2002 20:35:11 +0100, Karl Heinz Buchegger
> <kbuc...@gascad.at> wrote:
>
> >Josh Sebastian wrote:
> >>
> >> On Wed, 27 Nov 2002 07:04:48 -0000, "Paul"
> >> <paulcr<nospambots>@noplacespecial.fsworld.co.uk> wrote:
> >>
> >> >[OT]
> >> >If the getch() function is not written in C or C++ which language do
you
> >> >suggest it is written in?
> >>
> >> I *know* what language they're written in, on my implementation (the
> >> one that has them, anyway). They're written in assembler.
> >
> >But it really doesn't matter.
> >It could have been written in any other language as well, as long
> >as the calling mechanism is compatible to the one used by the C
> >or C++ compiler.
>
> Yep. In fact I'm sure some of my standard library was written in
> assembly. That's not the point. The point is, Paul doesn't know what
> he's talking about. He doesn't know what makes something conforming C
> or C++; he doesn't know what makes something portable; he doesn't know
> what makes something part of the language versus an extension.
>
> And he's basing his arguments on his faulty knowledge. Anyone who
> really knows about these things can see how misguided Paul is. But
> this is a learning newsgroup, so there will be plenty of people who
> *can't* tell the bullshit from the truth. I don't want them thinking
> Paul knows this stuff. So when he gives me an opportunity to easily
> and completely contradict him -- with evidence to back me up -- I'll
> jump on it. The more obvious he makes his lack of knowledge, the
> better.
shite!
You have no evidence to back these false accusations.
And I can prove your ideas to be completely misleading and incorrect. !
The sooner you find the balls to accept the truth the sooner we will all
benefit from the exclusion of your misguiding and ridiculously incorrect
posts!
.
>
> Josh
Josh Sebastian
<paulcr<nospambots>@noplacespecial.fsworld.co.uk> wrote:
>Josh Sebastian <cur...@cox.net> wrote in message
>news:139auuon48j0j392p...@4ax.com...
>
>> And he's basing his arguments on his faulty knowledge. Anyone who
>> really knows about these things can see how misguided Paul is. But
>> this is a learning newsgroup, so there will be plenty of people who
>> *can't* tell the bullshit from the truth. I don't want them thinking
>> Paul knows this stuff. So when he gives me an opportunity to easily
>> and completely contradict him -- with evidence to back me up -- I'll
>> jump on it. The more obvious he makes his lack of knowledge, the
>> better.
>
>shite!
>You have no evidence to back these false accusations.
Paul, you're providing the evidence. That was my point. You're not
*completely* ignorant. I said before that I thought you were very
intelligent, and I wasn't just patronizing. But the number of
trivially incorrect statements you've made belies your ignorance of
the topics under discussion.
>And I can prove your ideas to be completely misleading and incorrect. !
You've yet to do so. Richard even tried to help you out a bit, but he
couldn't quite get it ;-} Maybe you'll fair better. I doubt it.
>The sooner you find the balls to accept the truth the sooner we will all
>benefit from the exclusion of your misguiding and ridiculously incorrect
>posts!
LOL... good show, Paul :-} You're playing the part excellently.
Josh
Mike Hewson
wrote in message news:as32i8$eq4$1...@news8.svr.pol.co.uk...
> Is getch() is neither C or C++.
My Dear Pace Car,
How do I parse thee?
Is getch() neither C nor C++?
OR
Is getch() either C or C++?
OR
getch() is neither C nor C++.
OR
getch() is either C or C++.
OR
getch() is neither C nor C++?
OR
getch() is either C or C++?
OR
something else.
> Can you please explain which programming language this
function is written
> in then?
It could be written it any language whatsoever, as long as
it interfaces 'correctly' ( semantics, syntax, calling
conventions .... ).
--
Cheers
--
Hewson::Mike
"This letter is longer than usual because I lack the time to
make it shorter" - Blaise Pascal
Jerry Coffin
cur...@cox.net says...
[ ... ]
> Yep. In fact I'm sure some of my standard library was written in
> assembly. That's not the point. The point is, Paul doesn't know what
> he's talking about. He doesn't know what makes something conforming C
> or C++; he doesn't know what makes something portable; he doesn't know
> what makes something part of the language versus an extension.
I doubt you do either -- there's no such thing as "conforming C++" --
the C++ standard is very clear that its requirements are only on
implementations, not programs. Sometimes it's easier to phrase
things in a way that sounds like a requirement on the code, but it
explicitly says that's still to be interpreted as requirements on the
implementation.
The C standard does define "conforming program", but it explicitly
allows a conforming program to use implementation-specific extensions
-- a conforming program is a program that is acceptable to a (meaning
"at least one", not "all") conforming implementation.
That means all the MS/Borland/gcc/whatever-specific extensions in the
world do NOT prevent a program from being conforming C. In fact, the
wording is such that Fortran code (which is accepted by gcc) is
_probably_ conforming C code (I emphasized "probably" only because
there's a possibility that gcc isn't a conforming implementation of
C). Likewise, x86 assembly language is conforming C as long as it's
enclosed in _asm { and }, because BC 3.1 accepts it (and BC 3.1 is
one of the few compilers that's officially certified as conforming).
I could go on for quite a while, but the bottom line is pretty
obvious: "conforming" places _almost_ no limitation on the code at
all.
The other phrase defined by the C standard is "strictly conforming".
Strictly conforming code is not allowed to produce output that
depends on unspecified, implementation defined, or undefined
behavior. For better or worse, however, that means that strictly
conforming code can't produce any output AT ALL, or (basically)
interact with the user in any other way. IMO, strictly conforming
code is a useful category for some types of library functions and
such, but no complete program can be strictly conforming and remain
at all useful.
Most of us, of course, are interested in something between these two
extremes: code that's highly portable and will work with an extremely
wide variety of real implementations, but we don't particularly mind
something that might break on a useless implementation, even if it
did technically follow the standard.
--
Later,
Jerry.
The universe is a figment of its own imagination.
Paul
Jerry Coffin <jco...@taeus.com> wrote in message
news:MPG.185000349...@news.direcpc.com...
Thankyou for this wonderfull post Jerry, I am glad someone knows the true
meaning of the word standards.
:-)
James Hu
wrote:
> In article <139auuon48j0j392p...@4ax.com>,
> cur...@cox.net says...
>
> [ ... ]
>
>> Yep. In fact I'm sure some of my standard library was written in
>> assembly. That's not the point. The point is, Paul doesn't know what
>> he's talking about. He doesn't know what makes something conforming
>> C or C++; he doesn't know what makes something portable; he doesn't
>> know what makes something part of the language versus an extension.
>
> I doubt you do either -- there's no such thing as "conforming C++"
> -- the C++ standard is very clear that its requirements are only
> on implementations, not programs. Sometimes it's easier to phrase
> things in a way that sounds like a requirement on the code, but it
> explicitly says that's still to be interpreted as requirements on the
> implementation.
The C++ standard defines a "well-formed program" as "a C++ program
constructed according to the syntax rules, diagnosable semantic rules,
and the One Definition Rule (3.2)."
This leaves open the possiblity that a well-formed program may infact
invoke implementation defined behavior and unspecified behavior (a
well-formed program cannot invoke undefined behavior by the way
undefined behavior is defined).
The C++ standard says: "A conforming implementation may have extensions
(including additonal library functions), provided they do not alter the
behavior of any well-formed program."
Now, the C++ standard will explicitly note within the standard what
behaviors will be left implementation defined, and what behaviors are
unspecified. This leads me to conclude that the C++ standard intends
all conforming implementations to correctly execute all well-formed
programs (although each conforming implementation may execute the
program differently modulo implementation defined and unspecified
behavior).
However, any extension a conforming implemetation decides to include
that invokes behaviors that are outside of standard C++ must be
considered an extension that causes undefined behavior. So a program
that uses such an extension is no longer a well-formed program.
Even in the light of this loose definition of a well-formed program, it
is not incorrect to point out unspecified and implementation defined
behaviors so that a student will know why the program is not behaving as
expected when moved to a different platform.
> The C standard does define "conforming program", but it explicitly
> allows a conforming program to use implementation-specific extensions
> -- a conforming program is a program that is acceptable to a (meaning
> "at least one", not "all") conforming implementation.
>
> That means all the MS/Borland/gcc/whatever-specific extensions in the
> world do NOT prevent a program from being conforming C. In fact, the
> wording is such that Fortran code (which is accepted by gcc) is
> _probably_ conforming C code (I emphasized "probably" only because
> there's a possibility that gcc isn't a conforming implementation of
> C). Likewise, x86 assembly language is conforming C as long as it's
> enclosed in _asm { and }, because BC 3.1 accepts it (and BC 3.1 is
> one of the few compilers that's officially certified as conforming).
>
> I could go on for quite a while, but the bottom line is pretty
> obvious: "conforming" places _almost_ no limitation on the code at
> all.
>
> The other phrase defined by the C standard is "strictly conforming".
> Strictly conforming code is not allowed to produce output that
> depends on unspecified, implementation defined, or undefined
> behavior.
All this is true.
> For better or worse, however, that means that strictly
> conforming code can't produce any output AT ALL, or (basically)
> interact with the user in any other way. IMO, strictly conforming
> code is a useful category for some types of library functions and
> such, but no complete program can be strictly conforming and remain
> at all useful.
That's not true.
#define q(k)main(){return!puts(#k"\nq("#k")");}
q(#define q(k)main(){return!puts(#k"\nq("#k")");})
is a strictly conforming C89 program (all conforming hosted
implementations are required to accept it). What leads you to believe
it cannot interact with the user or produce any output at all? The C
standard library is part of the C standard, and if used correctly, will
not invoke unspecified, implementation defined, or undefined behavior.
> Most of us, of course, are interested in something between these two
> extremes: code that's highly portable and will work with an extremely
> wide variety of real implementations, but we don't particularly mind
> something that might break on a useless implementation, even if it did
> technically follow the standard.
I think you meant "did not technically".
I think this group is correct in taking a stance that leans toward
strict conformance over plain conformance. The goals are:
(1) to teach students to be able to distinguish features that are in the
standard from features that are not in the standard, and;
(2) to teach students how to exploit and leverage standard features to
gain maximal portability.
I believe this is a very pragmatic approach to *learning* how to
program in C or C++. And it certainly makes the boundaries of this
newsgroup well-defined.
I personally would be willing to overlook the inclusion of certain
headers and the use of certain extensions so long as the student
posing the question makes it clear which part of the program he/she
is having difficulty with. If that part of the program is
standard C or C++, then I would have no problem helping out.
But, I also do not see the harm in pointing out to the student when
non-standard features are being used.
-- James
Paul
James Hu <j...@despammed.com> wrote in message
news:slrnauct2...@despammed.com...
I would like to say discussing the detailed implications of the C or C++
standards is not a topic of great interest to me , and admit I don't know a
whole lot about the the implications of the C or C++ standards as I have
never even read them. So I cannot comment and these aspects of the posting.
However I disagree with what he states below regarding the goals of this
newsgroup.......
>
> I think this group is correct in taking a stance that leans toward
> strict conformance over plain conformance. The goals are:
> (1) to teach students to be able to distinguish features that are in the
> standard from features that are not in the standard, and;
> (2) to teach students how to exploit and leverage standard features to
> gain maximal portability.
> I believe this is a very pragmatic approach to *learning* how to
> program in C or C++. And it certainly makes the boundaries of this
> newsgroup well-defined.
AFAIK there are other newsgroups already in place dedicated to strictly
standard C and C++.
If this is James' opinion of the best learning method for such programming
languages then I have no desire to try and change his views. I would like to
point out however that these are definately only James *views* as oppose to
a fact.
This does not make the boundaries of this newsgroup well defined as he has
stated, I would suggest that this statement is completely untrue and seems
to be attempting to tend the focus of this newsgroup towards his way of
doing things .
>
> I personally would be willing to overlook the inclusion of certain
> headers and the use of certain extensions so long as the student
> posing the question makes it clear which part of the program he/she
> is having difficulty with. If that part of the program is
> standard C or C++, then I would have no problem helping out.
>
> But, I also do not see the harm in pointing out to the student when
> non-standard features are being used.
I fully agree that it is a good thing to point out if non-compliant code is
being used. However I do feel that many students within this group seem to
be doing this to extremes of ridiculousness. And any many cases they are
denouncing code as non- compliant when it probably actually is very
compliant.
As you can see from the detailed discussions on the implications of the
standards, this is a topic where many people seem to have a different
interpretations of what the wording in the standards actually means.
Introducing this type of discussion to a thread when it is completely
unecessary is simply veering the thread off topic.
A good example off badly and uneccessarily introducing of the standards to a
thread is the recent thread posted by someone asking how to use the arrow
keys for user input.
The OP was replied to by someone who stated that this could not be done
using compliant C++ code. Which I doubt is true. It is completely useless
and misleading information and it is unneccessary to introduce this to a
thread.
If I am wrong on this and it is in fact true that this cannot be done using
compliant code then I would suggest that compliant code would be pretty
useless. Note I said IF , I do not wish anyone to misinterpret this as me
saying I support non-compliance.
But I strongly protest about misuse and misinterpretations of the standards
to restrict the scope of the C++ programming language. This would be very
unbeneficial to me as a learner. And I do not want to learn C++ in this
misguided manner.
Thakyou for considering my views.
>
> -- James
rjh
>
> James Hu <j...@despammed.com> wrote in message
> news:slrnauct2...@despammed.com...
>>
<snip>
>
> AFAIK there are other newsgroups already in place dedicated to strictly
> standard C and C++.
comp.std.c discusses the C Standard.
comp.lang.c discusses the C language.
Similar groups with similar names discuss the C++ language and Standard.
alt.comp.lang.learn.c-c++ discusses learning the C and C++ languages.
In all of these groups, "C" and "C++" refer to the programming languages
defined by ISO. There is no other *reasonable and universally-understood
complete definition of those languages* (unless you count ANSI C and ANSI
C++, which are identical in all but page-numbering to their ISO
counterparts).
> If this is James' opinion of the best learning method for such programming
> languages then I have no desire to try and change his views. I would like
> to point out however that these are definately only James *views* as
> oppose to a fact.
<shrug> His view appears to be approximately the same as mine - i.e. that
when one is learning the language, one should learn the *language*. This is
orthogonal to learning the machine. For example, when learning Windows
programming, you need to understand about message pumps, event processing,
and that kind of stuff. When learning DOS programming, you need to
understand about controlling cursor movement, hitting video RAM, and that
kind of stuff. When learning C++ programming, you need to understand about
STL, classes, that kind of stuff.
To mix "learning about C++" and "learning about programming" into the same
bag is IMHO a big mistake. It leads to too much confusion about all kinds
of things.
<snip>
> A good example off badly and uneccessarily introducing of the standards to
> a thread is the recent thread posted by someone asking how to use the
> arrow keys for user input.
> The OP was replied to by someone who stated that this could not be done
> using compliant C++ code. Which I doubt is true. It is completely useless
> and misleading information and it is unneccessary to introduce this to a
> thread.
> If I am wrong on this and it is in fact true that this cannot be done
> using compliant code then I would suggest that compliant code would be
> pretty useless. Note I said IF , I do not wish anyone to misinterpret this
> as me saying I support non-compliance.
There is no way, using standard C++ (and in this newsgroup, the word
"standard" is redundant - an unqualified "C++" is assumed to mean
"standard" and any kind that does need qualification - e.g. "Microsoft
C++", "Borland C++", "g++", or whatever - is generally considered more
appropriate in newsgroups devoted to those compilers), to guarantee
correctly capturing cursor key movement.
If you think that makes standard C++ programming useless, that's entirely up
to you. Many of us find a great deal of use for a language in which we can
pick up vast amounts of well-written code from one platform and drop them
onto another *arbitrarily chosen* platform with little or no change
required to get them working on the new platform. This is /only/ possible,
however, if we pay a great deal of attention to ensuring that we write the
code in a way that facilitates that porting effort. In other words, if we
take the trouble to write in what I am obliged, when talking to you, to
call "standard C++", we get our return on investment later, when it's
porting time.
Any program that is sufficiently useful will get ported at least once in its
lifetime. It is worth taking the time to make this porting effort easy.
> But I strongly protest about misuse and misinterpretations of the
> standards to restrict the scope of the C++ programming language.
It is certainly your right to protest in that way if you wish, but I think
it's misguided. The restriction is intended to help, not hinder. By making
as few assumptions as possible about the student's environment, we make
sure that the advice given to him is maximally useful not just to him but
to all those reading this group who have a similar problem or question.
We don't say that to use non-portable programming constructs for which there
is no standard substitute is *wrong* - clearly it is not, and clearly many
students are obliged by their teachers to use such constructs. But it makes
no sense to "diversify" into such areas when there are already plenty of
newsgroups dealing with those areas. We concentrate on C and C++, and those
other groups concentrate on the extensions. That sounds perfectly rational
to me. If you don't like it, it's certainly your right not to like it, but
that doesn't mean you have the right to change it by force. You can try to
change it by persuasion if you like, but childishly flooding the newsgroup
and threatening to break people's noses if they disagree with you is not
the kind of persuasive tactic that will win you many friends.
<snip>
Paul
> Paul wrote:
>
> >
> > James Hu <j...@despammed.com> wrote in message
> > news:slrnauct2...@despammed.com...
> >>
> <snip>
> >
> > AFAIK there are other newsgroups already in place dedicated to strictly
> > standard C and C++.
>
> comp.std.c discusses the C Standard.
> comp.lang.c discusses the C language.
> Similar groups with similar names discuss the C++ language and Standard.
> alt.comp.lang.learn.c-c++ discusses learning the C and C++ languages.
[snip]
Oh your speaking to me again after me giving you a public humiliation?
Or are you in the huff?
I would like to know how you feel Richard after me completely proving you
wrong in public.
Jerry Coffin
says...
[ ... ]
> > For better or worse, however, that means that strictly
> > conforming code can't produce any output AT ALL, or (basically)
> > interact with the user in any other way. IMO, strictly conforming
> > code is a useful category for some types of library functions and
> > such, but no complete program can be strictly conforming and remain
> > at all useful.
>
> That's not true.
>
> #define q(k)main(){return!puts(#k"\nq("#k")");}
> q(#define q(k)main(){return!puts(#k"\nq("#k")");})
>
> is a strictly conforming C89 program (all conforming hosted
> implementations are required to accept it).
Good lord in heaven -- did you have to pick the single most
ridiculous program you could find as an (incorrect) example of
strictly conforming code? Here's a MUCH simpler program that I'm
sure nearly everybody recognizes:
#include <stdio.h>
int main() {
puts("Hello, World!");
return 0;
}
Note that puts writes to stdout, which is opened in text (translated)
mode. Now look at section 7.19.2/2 and read "characters may have to
be added altered or deleted on input and output to conform to
differing conventions for representing text in the host environment.
Thus there need not be a one-to-one correspondence between the
characters in the stream and those in the external representation."
That's telling you that any program that writes to a translated
stream includes implementation-defined behavior.
Now look at section 7.19.2/3, which talks about binary streams, and
says: "Such a stream may, however, have an implementation-defined
number of null characters appended to the end of the stream."
That's implementation defined behavior again. Bottom line: you can't
write anything to any stream without involving implementation-defined
behavior.
> what leads you to believe
> it cannot interact with the user or produce any output at all?
The fact that it's impossible to write anything to any stream without
implementation-defined behavior.
> The C
> standard library is part of the C standard, and if used correctly, will
> not invoke unspecified, implementation defined, or undefined behavior.
There are parts of the C standard that can be used without involving
implementation-defined behavior. Writing to a file is NOT one of
those parts though.
> > Most of us, of course, are interested in something between these two
> > extremes: code that's highly portable and will work with an extremely
> > wide variety of real implementations, but we don't particularly mind
> > something that might break on a useless implementation, even if it did
> > technically follow the standard.
>
> I think you meant "did not technically".
I meant exactly what I said. Consider an implementation that would
never let you open any file (fopen always returns NULL). In
addition, it documents that all characters written to any text stream
will be deleted (i.e. nothing you write will ever show up to the
outside world). Technically, this follows the standard, but it
produces an implementation that's utterly useless. I don't care in
the least that my "portable" code won't work on this conforming
implementation.
> I think this group is correct in taking a stance that leans toward
> strict conformance over plain conformance.
I think it's perfectly wonderful to keep as much as possible of your
code strictly conforming. I also think they should realize that
parts of any useful program they write won't be strictly conforming,
and it's not really doing anything wrong, it's just how life is.
Paul
Excellent Jerry *thumbs up*.
You have completely outclassed him in this debate
At last we have a real expert to lead people in the right direction.
Absolutely excellent :-)
That post is so good I cannot bring myself to snip it for the sake of
bandwidth.
Well done.
rjh
> rjh <bin...@eton.powernet.co.uk> wrote in message
> news:as6v5g$g0u$1...@helle.btinternet.com...
>> Paul wrote:
>>
>> >
>> > James Hu <j...@despammed.com> wrote in message
>> > news:slrnauct2...@despammed.com...
>> >>
>> <snip>
>> >
>> > AFAIK there are other newsgroups already in place dedicated to strictly
>> > standard C and C++.
>>
>> comp.std.c discusses the C Standard.
>> comp.lang.c discusses the C language.
>> Similar groups with similar names discuss the C++ language and Standard.
>> alt.comp.lang.learn.c-c++ discusses learning the C and C++ languages.
>
> [snip]
>
> Oh your speaking to me again after me giving you a public humiliation?
No, I continue to provide rebuttals for your errors as before, and you are
mistaken if you think you've humiliated me.
> Or are you in the huff?
Let's see now - you've posted erroneous code and demonstrated a thorough
misunderstanding of what this newsgroup is for, you've trolled the
newsgroup for over a week, you've flooded the newsgroup for two or three
days, you've falsely accused me of spamming, you've posted defamatory
material about me not just here but (if you are to be believed) Amazon, and
you've threatened to break my nose.
Am I in a huff? Hmmmm.... think think think...
No, I'm not in a huff. But I do wish you would get a copy of the Standard
and spend the next year or so studying it assiduously. It would do you the
world of good.
> I would like to know how you feel Richard after me completely proving you
> wrong in public.
If it ever happens, I'll let you know.
Paul F. Johnson
With the winds blowing light to moderate, Paul sang sweetly:
> To say that there are no commands in C or C++ called getch() is quite
> misleading actually.
It isn't. Nowhere in the C99 or C++98 standard are any commands given.
There are functions, macros, modifiers and keywords a plenty. There are no
commands at all. The closest you can get to a command is go to
getch() is not listed in either of the above standards either. It is a
vendor provided function in a header linked to a library containing the
appropriate object code.
Please, will you stop these plainly ridiculous arguments, pay the $20 or
so for a copy of the newest versions of the standard (or do a google
search - I know the standards are out there on a website in PDF form, I
have them, but I also have the paper versions), sit down and *read* them.
TTFN
Paul
James Hu
That is an interesting interpretation. The standard does define the
conditions under which the data read from a text stream will compare
equal to the data earlier written out on the text stream.
Data read in from a text stream will necessarily compare equal
to the data that were earlier written out to that stream only
if: the data consists only of printing characters and the
control characters horizontal tab and new-line; no new-line
character is preceeded by space characters; and the last
character is a new-line character.
This guarantees that the hello world example, and the quine example,
will succeed as expected, and the output can be verified for
correctness. The programs are strictly conforming, and do not
invoke implementation defined behavior.
Binary streams are a different animal, and I will concede their use
invokes implementation defined behavior.
>> The C
>> standard library is part of the C standard, and if used correctly, will
>> not invoke unspecified, implementation defined, or undefined behavior.
>
> There are parts of the C standard that can be used without involving
> implementation-defined behavior. Writing to a file is NOT one of
> those parts though.
>
>> > Most of us, of course, are interested in something between
>> > these two extremes: code that's highly portable and will work
>> > with an extremely wide variety of real implementations, but we
>> > don't particularly mind something that might break on a useless
>> > implementation, even if it did technically follow the standard.
>>
>> I think you meant "did not technically".
>
> I meant exactly what I said. Consider an implementation that would
> never let you open any file (fopen always returns NULL). In
> addition, it documents that all characters written to any text stream
> will be deleted (i.e. nothing you write will ever show up to the
> outside world). Technically, this follows the standard, but it
> produces an implementation that's utterly useless. I don't care in
> the least that my "portable" code won't work on this conforming
> implementation.
Although the standard says "there need not be a one-to-one
correspondence between the characters in a stream and those in the
external representation", this does not mean successful writes to the
text stream are allowed to simply disappear. If the program sticks to
the conditions for data read matching previous data write mentioned
earlier, then a read on that stream must be able to recover those
written characters (they may not appear on the computer monitor, but
that *is* a platform specific issue). So, your esoteric system
does not support standard C.
>> I think this group is correct in taking a stance that leans toward
>> strict conformance over plain conformance.
>
> I think it's perfectly wonderful to keep as much as possible of your
> code strictly conforming. I also think they should realize that
> parts of any useful program they write won't be strictly conforming,
> and it's not really doing anything wrong, it's just how life is.
I don't think I disagree with this point. But, I would not discount the
ability to write useful programs that are strictly conforming. Also,
a good software design principle is to isolate platform specific code
and minimize its impact to the software system, so that future porting
efforts can be done more easily (in most software systems written in C
of C++, the amount of platform specific code is a small portion compared
to the size of the entire system). A pragmatic tactic to putting
this design principle in practice is to always try to write strictly
conforming code.
-- James
Jerry Coffin
says...
[ ... ]
> That is an interesting interpretation. The standard does define the
> conditions under which the data read from a text stream will compare
> equal to the data earlier written out on the text stream.
>
> Data read in from a text stream will necessarily compare equal
> to the data that were earlier written out to that stream only
> if: the data consists only of printing characters and the
> control characters horizontal tab and new-line; no new-line
> character is preceeded by space characters; and the last
> character is a new-line character.
>
> This guarantees that the hello world example, and the quine example,
> will succeed as expected,
No, it does not.
> and the output can be verified for
> correctness. The programs are strictly conforming, and do not
> invoke implementation defined behavior.
What you write to stdout can't be read back in by any standard means
at all, so no matter what an implementation does with the output,
it's impossible to detect (in a way recognized by the standard) that
there's any difference between writing the data out as expected,
modifying it in an unexpected manner, or not writing it out at all.
This passage _does_ mean that _if_ you successfully open a file for
update, then writing (that's done successfully) must be done in some
way that's reversible so that when/if you read it back in
(successfully) it will compare equal to the original, at least under
some circumstances.
The problem is that opening a file for update in the first place gets
you back to using fopen (with its implementation definition of
acceptable strings for file names). Even if you successfully open
the file, the implementation is allowed to simply signal that writing
to the file has always failed, in which case you can't expect to read
the same data back in.
Of course, there's not much the standard can do about that. If (for
example) I open a file on a disk that only has 20 bytes left free on
it, the standard can't do much to dictate my being able to write more
than 20 bytes to it. Unfortunately, this sort of unpredictability
prevents it from guaranteeing much even when things should work.
[ ... ]
> If the program sticks to
> the conditions for data read matching previous data write mentioned
> earlier, then a read on that stream must be able to recover those
> written characters
That obviously only applies to a stream that it's possible to read
from, which clearly does NOT include stdout or stderr. stdin has the
reverse problem: you can't write to it at all, so detecting changes
in what you wrote isn't possible there either.
> (they may not appear on the computer monitor, but
> that *is* a platform specific issue). So, your esoteric system
> does not support standard C.
If standard output and/or standard error was opened for update so you
could read from it, you'd be right. As-is, you're not.
> I don't think I disagree with this point. But, I would not discount the
> ability to write useful programs that are strictly conforming. Also,
> a good software design principle is to isolate platform specific code
> and minimize its impact to the software system, so that future porting
> efforts can be done more easily (in most software systems written in C
> of C++, the amount of platform specific code is a small portion compared
> to the size of the entire system).
That depends -- at one time it was almost always true, and by a wide
margin at that. For better or worse, the percentage of most code
that's devoted to the user interface seems to grow constantly, to the
point that the portable parts of a program often almost disappear.
> A pragmatic tactic to putting
> this design principle in practice is to always try to write strictly
> conforming code.
Yes and no. Just for example, I recently wrote a quick little
program to take some data (in a rather special format), do an FFT on
it, and then do a combined oscilloscope/spectrum analyzer display.
The FFT code itself probably isn't strictly conforming, but it's
portable enough for any practical purpose. The UI code is entirely
non-portable. I suppose I could demand a file name on the command
line as the input, and create a text file of points as the output.
If I did, the result would be reasonably portable, but so useless
that nobody would care about using it on any platform. As-is, I'll
have to do more work if somebody wants to run it on another platform
-- but at least it works well enough that there's a chance they might
care.
Paul
Go-on Jerry Go-on
and The fans gave Jerry their full support.
:-)
James Hu
> In article <slrnaug9...@despammed.com>, j...@despammed.com
> says...
>
> [ ... ]
>
>> That is an interesting interpretation. The standard does define the
>> conditions under which the data read from a text stream will compare
>> equal to the data earlier written out on the text stream.
>>
>> Data read in from a text stream will necessarily compare
>> equal to the data that were earlier written out to that
>> stream only if: the data consists only of printing characters
>> and the control characters horizontal tab and new-line; no
>> new-line character is preceeded by space characters; and the
>> last character is a new-line character.
>>
>> This guarantees that the hello world example, and the quine example,
>> will succeed as expected,
>
> No, it does not.
True.
>> and the output can be verified for
>> correctness. The programs are strictly conforming, and do not
>> invoke implementation defined behavior.
>
> What you write to stdout can't be read back in by any standard means
> at all, so no matter what an implementation does with the output,
> it's impossible to detect (in a way recognized by the standard) that
> there's any difference between writing the data out as expected,
> modifying it in an unexpected manner, or not writing it out at all.
>
> This passage _does_ mean that _if_ you successfully open a file
> for update, then writing (that's done successfully) must be done
> in some way that's reversible so that when/if you read it back in
> (successfully) it will compare equal to the original, at least under
> some circumstances.
Hmmm. All you really need to validate the program is a validation
framework. The programs could be wrapped around a framework that mimics
the C runtime. The framework could use freopen to redirect stdout
for the program it intends to validate. The framework could then use
exit status to express the success or failure of the validation. This
framework could be written standard C.
> The problem is that opening a file for update in the first place
> gets you back to using fopen (with its implementation definition of
> acceptable strings for file names). Even if you successfully open the
> file, the implementation is allowed to simply signal that writing to
> the file has always failed, in which case you can't expect to read the
> same data back in.
You could always use tempnam() to get a valid filename.
> Of course, there's not much the standard can do about that. If (for
> example) I open a file on a disk that only has 20 bytes left free on
> it, the standard can't do much to dictate my being able to write more
> than 20 bytes to it. Unfortunately, this sort of unpredictability
> prevents it from guaranteeing much even when things should work.
Yes, I have been implicitly assuming calls to fopen(), puts(), etc.
succeed. There are all sorts of conditions that can cause a strictly
conforming program to fail (e.g., running out of memory or disk).
[...]
>> I don't think I disagree with this point. But, I would not discount
>> the ability to write useful programs that are strictly conforming.
>> Also, a good software design principle is to isolate platform
>> specific code and minimize its impact to the software system, so that
>> future porting efforts can be done more easily (in most software
>> systems written in C of C++, the amount of platform specific code is
>> a small portion compared to the size of the entire system).
>
> That depends -- at one time it was almost always true, and by a wide
> margin at that. For better or worse, the percentage of most code
> that's devoted to the user interface seems to grow constantly, to the
> point that the portable parts of a program often almost disappear.
On a different pragmatic note, programmers will write code with the
(UI) tools they know. But, it is not impossible to alleviate the pain
by doing some research to look for a more portable solution or create
one that is more portable than what is available. Such solutions are
typically not perfect, but, like your FFT code, they may be portable
enough for any practical purpose (e.g., Qt or V C++ GUI).
The point is that it is more often than not worth trying to keep things
portable. Especially the parts intended to be reused (like your FFT
code).
[...]
-- James
Jerry Coffin
says...
[ ... ]
> Hmmm. All you really need to validate the program is a validation
> framework. The programs could be wrapped around a framework that mimics
> the C runtime. The framework could use freopen to redirect stdout
> for the program it intends to validate. The framework could then use
> exit status to express the success or failure of the validation. This
> framework could be written standard C.
The question is what are you going to validate about the program?
> > The problem is that opening a file for update in the first place
> > gets you back to using fopen (with its implementation definition of
> > acceptable strings for file names). Even if you successfully open the
> > file, the implementation is allowed to simply signal that writing to
> > the file has always failed, in which case you can't expect to read the
> > same data back in.
>
> You could always use tempnam() to get a valid filename.
You could always try -- but (7.19.4.4/2): "The function is
potentially capable of generating TMP_MAX different strings, but any
or all of them may already be in use by existing files and thus not
be suitable return values."
While this obviously _intends_ that it be able to return valid names
as long as they're not already in use, I doubt that's enforceable --
if an implementation simply always return NULL, would there be any
way of standard-defined way of detecting that it wasn't even trying
to generate a valid name?
[ ... ]
> Yes, I have been implicitly assuming calls to fopen(), puts(), etc.
> succeed. There are all sorts of conditions that can cause a strictly
> conforming program to fail (e.g., running out of memory or disk).
Right. My point, however, wasn't just that it could fail, but that a
sufficiently bad implementation can take the same possibility of
failure as permission to implement the function to _always_ fail,
even if resources are abundant. Clearly this isn't the intent of the
standard, but it appears such an implementation would still conform.
Jerry Coffin
<nospambots>@noplacespecial.fsworld.co.uk> says...
[ I had this bozo killfiled, but after seeing a few replies
mentioning me, lost my resolve and decided to add a bit to the noise.
My apologies... ]
> Excellent Jerry *thumbs up*.
> You have completely outclassed him in this debate
You disgusting little maggot. You should learn the difference
between somebody acting like an anal retentive jerk and having class.
> At last we have a real expert to lead people in the right direction.
> Absolutely excellent :-)
Being able to read the standard in excruciating detail is NOT a
particularly great qualification for deciding the direction things
should take. Rather the contrary, most of the qualities that make me
good at reading the standard tend to lead to my being a relatively
poor teacher, especially of beginners. While I don't give then
answers that are blatantly wrong like your's, I tend to overwhelm
them with excessive detail about things they'd really rather not
know.
Overall, I'd say that Richard Heathfield is a much better teacher
than I'll ever be. While I try to keep my answers accurate, other
people here often provide answers that I'm quite certain are more
helpful most of the time. That's not to say that I don't think I can
contribute anything (if I thought that, I wouldn't be here) but at
the same time, I think quite a few others generally contribute a
great deal more.
> That post is so good I cannot bring myself to snip it for the sake of
> bandwidth.
I, OTOH, had no trouble snipping all of it.
> Well done.
I find your admiration nauseating -- it makes me wonder what I've
done wrong, and whether it might not be a good idea for me to move
into the mountains and become a hermit with no connection to the
Internet at all!
Paul
I never did or never will admire you , I was simply encouringing you to
speak the truth.
Now you have made it apparent your views on me you little prick, I can only
say you are a knob.
James Hu
> In article <slrnaugml...@despammed.com>, j...@despammed.com
> says...
>
> [ ... ]
>
>> Hmmm. All you really need to validate the program is a validation
>> framework. The programs could be wrapped around a framework that
>> mimics the C runtime. The framework could use freopen to redirect
>> stdout for the program it intends to validate. The framework could
>> then use exit status to express the success or failure of the
>> validation. This framework could be written standard C.
>
> The question is what are you going to validate about the program?
Well, this was only for the puts() programs we wrote. So, it is
meant to validate if the programs do what they were designed to
do.
>> You could always use tempnam() to get a valid filename.
>
> You could always try -- but (7.19.4.4/2): "The function is
> potentially capable of generating TMP_MAX different strings, but any
> or all of them may already be in use by existing files and thus not
> be suitable return values."
>
> While this obviously _intends_ that it be able to return valid names
> as long as they're not already in use, I doubt that's enforceable --
> if an implementation simply always return NULL, would there be any
> way of standard-defined way of detecting that it wasn't even trying
> to generate a valid name?
Again, I assume tempnam() will succeed in its primary function. But,
even a Byzantine conforming implementation must comply with the
specified behavior for reporting a failure.
> [ ... ]
>
>> Yes, I have been implicitly assuming calls to fopen(), puts(), etc.
>> succeed. There are all sorts of conditions that can cause a strictly
>> conforming program to fail (e.g., running out of memory or disk).
>
> Right. My point, however, wasn't just that it could fail, but that a
> sufficiently bad implementation can take the same possibility of
> failure as permission to implement the function to _always_ fail,
> even if resources are abundant. Clearly this isn't the intent of the
> standard, but it appears such an implementation would still conform.
A strictly conforming program should check for failure conditions, and
take appropriate actions when encountered. This extends the set of
correct behaviors a strictly conforming program may exhibit to include
what it does when an error occurs.
So, yes, a conforming implementation may produce failures. It still
doesn't mean that strictly conforming programs cannot perform I/O.
-- James
Jerry Coffin
says...
[ ... ]
> Again, I assume tempnam() will succeed in its primary function. But,
> even a Byzantine conforming implementation must comply with the
> specified behavior for reporting a failure.
Yes, and that's the behavior I gave above. Even if it succeeds,
however, it doesn't really do you any good: first of all, the file
name it generates will be implementation defined, and second anything
you write to the file will be implementation defined.
> A strictly conforming program should check for failure conditions, and
> take appropriate actions when encountered. This extends the set of
> correct behaviors a strictly conforming program may exhibit to include
> what it does when an error occurs.
Yes, but think about it: what are you going to do when an error
occurs? The obvious thing to do would be to tell the user by writing
something to standard error -- but that gives implementation defined
results.
> So, yes, a conforming implementation may produce failures. It still
> doesn't mean that strictly conforming programs cannot perform I/O.
By itself, no, it doesn't. Coupled with the other points I've
already cited, yes, it does.
You really should go back and read the definition of strictly
conforming. Then, try to work out a way for a program to actually do
some output without that output involving implementation defined
behavior.
The fact is, there simply is no such thing. You've already agreed
that writing to a binary file gives implementation-defined behavior.
Even though it's clearly stated in the standard, you apparently
haven't resigned yourself to the fact that the same is true of text
files (actually, even MORE true of text files). The fact that there
may be a _matching_ implementation-defined transformation when you
read back the contents of a text file does NOT change the fact that
writing to a text file gives entirely implementation-defined results.
You're not guaranteed to get any output at all unless you write to a
file that can be read back in. If you do that, you're only
guaranteed that most of the implementation-defined transformations
that happened during output will be reversed during input.
That doesn't make the behavior any less implementation defined. Just
for example, an implementation could perfectly legitimately do ROT13
on all letters as long as it documented that fact.
Bottom line: writing to a file produces implementation defined
behavior. Reversibility of that behavior makes it no less
implementation-defined.
James Hu
> In article <slrnauku9...@despammed.com>, j...@despammed.com
> says...
>
> [ ... ]
>
>> Again, I assume tempnam() will succeed in its primary function. But,
>> even a Byzantine conforming implementation must comply with the
>> specified behavior for reporting a failure.
>
> Yes, and that's the behavior I gave above. Even if it succeeds,
> however, it doesn't really do you any good: first of all, the file
> name it generates will be implementation defined, and second anything
> you write to the file will be implementation defined.
But the fact that it returns a valid filename is well defined.
I also don't think just because what you write to the file may be
implementation defined means the program is not strictly conforming.
>> A strictly conforming program should check for failure conditions,
>> and take appropriate actions when encountered. This extends the set
>> of correct behaviors a strictly conforming program may exhibit to
>> include what it does when an error occurs.
>
> Yes, but think about it: what are you going to do when an error
> occurs? The obvious thing to do would be to tell the user by writing
> something to standard error -- but that gives implementation defined
> results.
It could just exit with EXIT_FAILURE status. But again, I don't agree
that just because the acutal output of a program is implementation
defined means the program is exhibiting implementaiton defined
behavior. It is ok for a strictly conforming program on two different
implementations to emit different output.
>> So, yes, a conforming implementation may produce failures. It still
>> doesn't mean that strictly conforming programs cannot perform I/O.
>
> By itself, no, it doesn't. Coupled with the other points I've
> already cited, yes, it does.
>
> You really should go back and read the definition of strictly
> conforming. Then, try to work out a way for a program to actually
> do some output without that output involving implementation defined
> behavior.
A /strictly/ /conforming/ /program/ shall use only those
featrues of the language and library specified in this
International Standard. It shall not produce output dependent
on any unspecified, undefined, or implementation-defined
behavior, and shall not exceed any minimum implementation limit.
Ok, re-reading this definition again, I am going to change my argument a
little bit (more below).
> The fact is, there simply is no such thing. You've already agreed
> that writing to a binary file gives implementation-defined behavior.
I think I want to take that back now :-).
> Even though it's clearly stated in the standard, you apparently
> haven't resigned yourself to the fact that the same is true of text
> files (actually, even MORE true of text files).
The definition said "shall not produce output dependent on ...
implementation-defined behavior."
(1) It doesn't say "shall not produce output." If that was what the
committee had meant, then I am sure that is what they would have
said.
(2) It also doesn't say "shall not produce implementation defined
output." Although the standard says the actual output of text
and binary streams are implementation defined, it does not
mean the program is therefore producing output dependent on
implementation-defined behavior.
> The fact that there may be a _matching_ implementation-defined
> transformation when you read back the contents of a text file does
> NOT change the fact that writing to a text file gives entirely
> implementation-defined results. You're not guaranteed to get
> any output at all unless you write to a file that can be read
> back in. If you do that, you're only guaranteed that most of the
> implementation-defined transformations that happened during output
> will be reversed during input.
>
> That doesn't make the behavior any less implementation defined. Just
> for example, an implementation could perfectly legitimately do ROT13
> on all letters as long as it documented that fact.
>
> Bottom line: writing to a file produces implementation defined
> behavior. Reversibility of that behavior makes it no less
> implementation-defined.
It really depends on what "shall not produce output dependent on any
unspecified, undefined, or implementation-defined behavior" is taken
to mean. Consider the program:
#include <stdlib.h>
int main (void)
{
exit(EXIT_SUCCESS);
}
Does this program produce output? I would say yes. Although there is
no I/O in the sense of 7.19, there is output in the form of an exit
status. Does this program produce output dependent on any unspecified,
undefined or implementation-defined behavior? I would say no, since the
standard C behavior I am interested in is whether or not the program
exited with status successful termination. But, according to your
argument, you would say yes. You would say yes, since according to the
C standard (7.20.4.3/5), the exit status is of an implementation-defined
form.
I am not willing to go along with your interpretation. The reasoning
is once the output leaves the confines of C program into the host
environment, the form of that output is inherently implementaiton
defined. But, it is not the form of that output that is important,
it is whether or not the program itself depended upon unspecified,
undefined, or implementation-defined behavior when deciding to
produce that output.
The consequence of my interpretation would be that this example is not
strictly conforming:
#include <stdlib.h>
int main (void)
{
if ('A' < 'B') exit(EXIT_SUCCESS);
exit(EXIT_FAILURE);
}
But this program is strictly conforming:
#include <stdlib.h>
int main (void)
{
if ('A' < 'B') exit(EXIT_SUCCESS);
exit(EXIT_SUCCESS);
}
In fact, according to me, this program is also strictly conforming:
#include <stdlib.h>
int main (void)
{
int i = 0;
i = i++;
exit(EXIT_SUCCESS);
}
Returning to I/O, the only remaining question I have is whether to
following is strictly conforming or not:
#include <stdio.h>
#include <stdlib.h>
int main (void)
{
fputc('a', stdout);
exit(EXIT_SUCCESS);
}
The standard says whether or not a newline character is required on
the last line of output is implementation-defined. One can argue
that it is not a strictly conforming program because the program
does not insert the final newline character.
However, I would still argue that the program *is* strictly conforming.
Before the call to exit(), the definition of what fputc() does is well
defined (7.19.7.3). It is only after control is released back to
the host environment through exit() that the stdout stream may have
a last line that does not end with a newline. But, at that point,
everything is in control of the host environment, the program has
already finished its task. The the program did not produce output ('a'
on stdout and the termination status) dependent on any unspecified,
undefined, or implementation-defined behavior. The form of the output
becomes implementation-defined after the termination of the program.
Now, back to the hello world example:
#include <stdio.h>
int main (void)
{
puts("Hello world.");
return 0;
}
According to the C standard (7.19.3/12), this program behaves as if:
#include <stdio.h>
int main (void)
{
char *s = "Hello world.\n";
while (*s) {
if (fputc(*s++, stdout) == EOF) break;
}
return 0;
}
By my previous arguments, this program is still strictly conforming.
-- James
Arthur J. O'Dwyer
On Tue, 3 Dec 2002, James Hu wrote:
>
> In article <MPG.1855f236d...@news.direcpc.com>, Jerry Coffin wrote:
> > In article <slrnauku9...@despammed.com>, j...@despammed.com
> > says...
> > [ ... ]
> >
> >> Again, I assume tempnam() will succeed in its primary function. But,
> >> even a Byzantine conforming implementation must comply with the
> >> specified behavior for reporting a failure.
> >
> > Yes, and that's the behavior I gave above. Even if it succeeds,
> > however, it doesn't really do you any good: first of all, the file
> > name it generates will be implementation defined, and second anything
> > you write to the file will be implementation defined.
>
> But the fact that it returns a valid filename is well defined.
Correct. At least, the first 25 times you call it.
(Standard section 7.19.4.4)
I think someone said in this thread before that a conforming
implementation could just return NULL every time; I think whoever said
that is wrong.
> It could just exit with EXIT_FAILURE status. But again, I don't agree
> that just because the acutal output of a program is implementation
> defined means the program is exhibiting implementaiton defined
> behavior.
Incorrect. Output is a form of behavior, as I understand it. You may
not use implementation-defined behavior to produce output, and you may
not use implementation-defined output as that behavior.
(No evidence here, but I think it's reasonable.)
> It is ok for a strictly conforming program on two different
> implementations to emit different output.
Correct? For example, you could guard the implementation-defined parts
with an #ifdef. I'm not sure about this.
(Standard section 4.5, footnote 2)
> >> So, yes, a conforming implementation may produce failures. It still
> >> doesn't mean that strictly conforming programs cannot perform I/O.
> >
> > By itself, no, it doesn't. Coupled with the other points I've
> > already cited, yes, it does.
ITYM "file I/O". Streams I/O (stdin, stdout) appears to be quite
conforming when used portably. (That's a bit redundant, in't it?)
> The definition said "shall not produce output dependent on ...
> implementation-defined behavior."
>
> (1) It doesn't say "shall not produce output." If that was what the
> committee had meant, then I am sure that is what they would have
> said.
Correct.
> (2) It also doesn't say "shall not produce implementation defined
> output." Although the standard says the actual output of text
> and binary streams are implementation defined, it does not
> mean the program is therefore producing output dependent on
> implementation-defined behavior.
As above: I think output is a form of behavior, and so
implementation-defined output is a form of implementation-defined
behavior. So, incorrect.
> > That doesn't make the behavior any less implementation defined. Just
> > for example, an implementation could perfectly legitimately do ROT13
> > on all letters as long as it documented that fact.
Correct? :-)
> It really depends on what "shall not produce output dependent on any
> unspecified, undefined, or implementation-defined behavior" is taken
> to mean. Consider the program:
>
> #include <stdlib.h>
> int main (void)
> {
> exit(EXIT_SUCCESS);
> }
>
> Does this program produce output? I would say yes. Although there is
> no I/O in the sense of 7.19, there is output in the form of an exit
> status.
Incorrect? I think 7.19 implies that the return value is not a form
of I/O, since it isn't an I/O function. Seems kind of silly to say
that the exit value is output, since it's not really "going" anywhere,
if you get my drift -- it's just telling the system something, not
reading or recording data.
(Standard section 7.19)
> Does this program produce output dependent on any unspecified,
> undefined or implementation-defined behavior? I would say no, since the
> standard C behavior I am interested in is whether or not the program
> exited with status successful termination. But, according to your
> argument, you would say yes. You would say yes, since according to the
> C standard (7.20.4.3/5), the exit status is of an implementation-defined
> form.
Incorrect? I, at least, would say no. While the status is
implementation-defined, as you correctly point out, I don't consider it
"output". Analogously, strictly conforming programs can still use NULL
even though its bit pattern may be implementation-defined. :-)
(Standard section 7.17.3)
> The consequence of my interpretation would be that this example is not
> strictly conforming:
>
> #include <stdlib.h>
> int main (void)
> {
> if ('A' < 'B') exit(EXIT_SUCCESS);
> exit(EXIT_FAILURE);
> }
Incorrect? Good example, though. It relies on the fact that ('A' < 'B')
is implementation-defined, am I right? As above, though, I don't think
exit status is output per se.
> But this program is strictly conforming:
>
> #include <stdlib.h>
> int main (void)
> {
> if ('A' < 'B') exit(EXIT_SUCCESS);
> exit(EXIT_SUCCESS);
> }
Correct.
> In fact, according to me, this program is also strictly conforming:
>
> #include <stdlib.h>
> int main (void)
> {
> int i = 0;
> i = i++;
> exit(EXIT_SUCCESS);
> }
Incorrect. i = i++ invokes undefined behavior, which may do anything,
including the issuance of a diagnostic message (to stderr, stdout, or
anywhere else, for that matter). That counts as output, if I am not
mistaken.
(Standard section 3.18)
> Returning to I/O, the only remaining question I have is whether to
> following is strictly conforming or not:
>
> #include <stdio.h>
> #include <stdlib.h>
> int main (void)
> {
> fputc('a', stdout);
> exit(EXIT_SUCCESS);
> }
>
> The standard says whether or not a newline character is required on
> the last line of output is implementation-defined. One can argue
> that it is not a strictly conforming program because the program
> does not insert the final newline character.
Yes; I would too. Inserting the last putc('\n') would in my opinion make
the program strictly conforming.
> However, I would still argue that the program *is* strictly conforming.
> Before the call to exit(), the definition of what fputc() does is well
> defined (7.19.7.3). It is only after control is released back to
> the host environment through exit() that the stdout stream may have
> a last line that does not end with a newline. But, at that point,
> everything is in control of the host environment, the program has
> already finished its task.
Not quite; you leave out the "clean-up" which the program must do before
returning to the host environment. I think the implementation is allowed
to catch the error here.
> The the program did not produce output ('a'
> on stdout and the termination status) dependent on any unspecified,
> undefined, or implementation-defined behavior. The form of the output
> becomes implementation-defined after the termination of the program.
ITYM "after the end of main." And implementation-defined output is a
no-no for strictly conforming programs.
> Now, back to the hello world example:
>
> #include <stdio.h>
> int main (void)
> {
> puts("Hello world.");
> return 0;
> }
[snip]
> By my previous arguments, this program is still strictly conforming.
By my previous arguments, this program is not strictly conforming.
> -- James
-Arthur
Jerry Coffin
says...
[ ... ]
> But the fact that it returns a valid filename is well defined.
You can argue about "well defied", but it's clearly implementation
defined. The definition of strictly conforming doesn't say "uses
only well defined behavior" -- it says the output can't depend on any
implementation defined behavior.
> I also don't think just because what you write to the file may be
> implementation defined means the program is not strictly conforming.
Then you're just plain wrong. The content of the file is (part of)
the output from the program. Therefore, the content of the file
cannot depend on any implementation defined behavior if the program
is strictly conforming. Unfortunately, there's simply no way to
avoid the content of the file depending on implementation defined
behavior.
> It could just exit with EXIT_FAILURE status.
Look at the definition of exit -- you'll find that (you guessed it)
what you return to the environment (by the return value from main, or
equivalently, the value passed to exit) is basically implementation
defined as well.
> But again, I don't agree
> that just because the acutal output of a program is implementation
> defined means the program is exhibiting implementaiton defined
> behavior. It is ok for a strictly conforming program on two different
> implementations to emit different output.
That's simply not true. The definition is very clear that the output
of the program can't depend on any implementation defined,
unspecified or undefined behavior. Something that doesn't depend on
one of those cannot and will not vary. IOW, any variation in the
output means the program is not strictly conforming -- and the only
way a program can ensure against varying output (normally via
implementation-defined behavior) is to not produce ANY output. It
also can't perform a normal exit, because that produces output that's
implementation defined as well.
[ ... ]
> (1) It doesn't say "shall not produce output." If that was what the
> committee had meant, then I am sure that is what they would have
> said.
Not really -- I doubt they _intended_ or realized the full
implications of what the rest of the standard says. If you want to
prove it can produce output, try to find one, single, solitary method
for it to do so without the output depending on (at least)
implementation defined behavior.
I've looked at this for years, and I'm quite certain there is no such
thing. You can't write to a pre-opened file, you can't open any
other files, and you can't return an exit status. You're left with
no avenue by which to produce output that doesn't make part of that
output depend on implementation-defined behavior.
> (2) It also doesn't say "shall not produce implementation defined
> output." Although the standard says the actual output of text
> and binary streams are implementation defined, it does not
> mean the program is therefore producing output dependent on
> implementation-defined behavior.
Yes, that's _exactly_ what it means. The output cannot depend on
implementation-defined behavior. The output produced by writing to
either a text file OR a binary file DOES depend on implementation
defined behavior. How much simpler can it get than that?
> Does this program produce output? I would say yes. Although there is
> no I/O in the sense of 7.19, there is output in the form of an exit
> status. Does this program produce output dependent on any unspecified,
> undefined or implementation-defined behavior? I would say no, since the
> standard C behavior I am interested in is whether or not the program
> exited with status successful termination.
Yes, but if you look at the definition of exit, you'll see:
If the value of status is zero or EXIT_SUCCESS, an
implementation-defined form of the status successful
termination is returned. If the value of status is
EXIT_FAILURE, an implementation-defined form of the
status unsuccessful termination is returned. Otherwise
the status returned is implementation-defined.
In short, every value you pass to exit produces implementation-
defined output. Returning a value from main is defined as being
equivalent to calling exit with the same value; you have no escape
from the output produced being implementation-defined.
> I am not willing to go along with your interpretation. The reasoning
> is once the output leaves the confines of C program into the host
> environment, the form of that output is inherently implementaiton
> defined.
The reasoning has nothing to do with "inherent" -- it has to do with
the fact that the standard explicitly says it's implementation-
defined.
> But, it is not the form of that output that is important,
> it is whether or not the program itself depended upon unspecified,
> undefined, or implementation-defined behavior when deciding to
> produce that output.
That's simply not true: the standard is very explicit in saying that
the output itself shall not depend on ANY implementation-defined
behavior. It doesn't say parts can be and other parts can't, nor
does it say part of it can be implementation-defined if you prefer to
ignore it, or anything else.
> In fact, according to me, this program is also strictly conforming:
According to the standard it's clearly not.
[ ... ]
> Returning to I/O, the only remaining question I have is whether to
> following is strictly conforming or not:
>
> #include <stdio.h>
> #include <stdlib.h>
> int main (void)
> {
> fputc('a', stdout);
> exit(EXIT_SUCCESS);
> }
>
> The standard says whether or not a newline character is required on
> the last line of output is implementation-defined. One can argue
> that it is not a strictly conforming program because the program
> does not insert the final newline character.
That's irrelevant: even if it inserts a newline character, the output
is still implementation-defined, because the standard says it is.
> However, I would still argue that the program *is* strictly conforming.
You can argue it all you want, but the standard makes it clear that
your argument is wrong.
> Before the call to exit(), the definition of what fputc() does is well
> defined (7.19.7.3).
Not really -- since you're writing to a text-mode stream, characters
may be "added, altered or deleted", so the output you produce depends
on an implementation-defined mapping for text streams.
> It is only after control is released back to
> the host environment through exit() that the stdout stream may have
> a last line that does not end with a newline. But, at that point,
> everything is in control of the host environment, the program has
> already finished its task. The the program did not produce output ('a'
> on stdout and the termination status) dependent on any unspecified,
> undefined, or implementation-defined behavior.
Not true at all -- it wrote to a text stream, which is clearly
defined to produce implementation-defined results.
[ a hello world program: ]
> By my previous arguments, this program is still strictly conforming.
By the standard, it's clearly not.
James Hu
<Pine.GSO.4.44L-027.021...@unix15.andrew.cmu.edu>,
Arthur J. O'Dwyer wrote:
> On Tue, 3 Dec 2002, James Hu wrote:
>> In article <MPG.1855f236d...@news.direcpc.com>,
>> Jerry Coffin wrote:
>> >
>> > Yes, and that's the behavior I gave above. Even if it succeeds,
>> > however, it doesn't really do you any good: first of all, the
>> > file name it generates will be implementation defined, and second
>> > anything you write to the file will be implementation defined.
[...]
>> It could just exit with EXIT_FAILURE status. But again, I
>> don't agree that just because the acutal output of a program is
>> implementation defined means the program is exhibiting implementaiton
>> defined behavior.
>
> Incorrect. Output is a form of behavior, as I understand it. You may
> not use implementation-defined behavior to produce output, and you may
> not use implementation-defined output as that behavior.
> (No evidence here, but I think it's reasonable.)
Assuming that Jerry agrees with your opinion, we are pitting reasonable
interpretation against reasonable interpretation. I will make a few
more clarifying remarks here, but I guess that'll wrap things up for me
on this thread.
>> It is ok for a strictly conforming program on two different
>> implementations to emit different output.
>
> Correct? For example, you could guard the implementation-defined parts
> with an #ifdef. I'm not sure about this.
> (Standard section 4.5, footnote 2)
I was thinking something along the lines of:
#include <stdio.h>
int main(void) { fputc('\n', stdout); return 0; }
On one implementation, '\r\n' is emitted, and on another '\n' is
emitted.
[...]
>> The definition said "shall not produce output dependent on ...
>> implementation-defined behavior."
>>
>> (1) It doesn't say "shall not produce output." If that was what the
>> committee had meant, then I am sure that is what they would have
>> said.
>
> Correct.
>
>> (2) It also doesn't say "shall not produce implementation defined
>> output." Although the standard says the actual output of text
>> and binary streams are implementation defined, it does not
>> mean the program is therefore producing output dependent on
>> implementation-defined behavior.
>
> As above: I think output is a form of behavior, and so
> implementation-defined output is a form of implementation-defined
> behavior. So, incorrect.
I think that if the standard had meant "shall not produce
implementation-defined output", it would have stated it that way.
My take is that the wording in the C standard is deliberate.
I also do not think output is a form of behavior. I think it is
a consequence of behavior.
>> It really depends on what "shall not produce output dependent on any
>> unspecified, undefined, or implementation-defined behavior" is taken
>> to mean. Consider the program:
>>
>> #include <stdlib.h>
>> int main (void)
>> {
>> exit(EXIT_SUCCESS);
>> }
>>
>> Does this program produce output? I would say yes. Although there
>> is no I/O in the sense of 7.19, there is output in the form of an
>> exit status.
>
> Incorrect? I think 7.19 implies that the return value is not a form
> of I/O, since it isn't an I/O function. Seems kind of silly to say
> that the exit value is output, since it's not really "going" anywhere,
> if you get my drift -- it's just telling the system something, not
> reading or recording data. (Standard section 7.19)
I explicitly said "there is no I/O in the sense of 7.19." I interpret
the term "output" to mean some observable consequence of the program's
execution.
>> Does this program produce output dependent on any unspecified,
>> undefined or implementation-defined behavior? I would say no, since
>> the standard C behavior I am interested in is whether or not the
>> program exited with status successful termination. But, according
>> to your argument, you would say yes. You would say yes, since
>> according to the C standard (7.20.4.3/5), the exit status is of an
>> implementation-defined form.
>
> Incorrect? I, at least, would say no. While the status is
> implementation-defined, as you correctly point out, I don't consider
> it "output". Analogously, strictly conforming programs can still use
> NULL even though its bit pattern may be implementation-defined. :-)
> (Standard section 7.17.3)
Assigning NULL to a variable does not produce output (there is no
observable consequence from the assignment itself).
>> The consequence of my interpretation would be that this example is
>> not strictly conforming:
>>
>> #include <stdlib.h>
>> int main (void)
>> {
>> if ('A' < 'B') exit(EXIT_SUCCESS);
>> exit(EXIT_FAILURE);
>> }
>
> Incorrect? Good example, though. It relies on the fact that ('A' <
> 'B') is implementation-defined, am I right? As above, though, I don't
> think exit status is output per se.
Since the host environment can observe whether or not the program
returns EXIT_SUCCESS or EXIT_FAILURE, the program's execution produces
an observable consequence that is dependent on implementation-defined
behavior.
>> But this program is strictly conforming:
>>
>> #include <stdlib.h>
>> int main (void)
>> {
>> if ('A' < 'B') exit(EXIT_SUCCESS);
>> exit(EXIT_SUCCESS);
>> }
>
> Correct.
Since the host environment only sees the program returns EXIT_SUCCESS,
the program's execution produces the same observable consequence no
matter how the implementation defines the relationship between 'A' and
'B'.
>> In fact, according to me, this program is also strictly conforming:
>>
>> #include <stdlib.h>
>> int main (void)
>> {
>> int i = 0;
>> i = i++;
>> exit(EXIT_SUCCESS);
>> }
>
> Incorrect. i = i++ invokes undefined behavior, which may do anything,
> including the issuance of a diagnostic message (to stderr, stdout, or
> anywhere else, for that matter). That counts as output, if I am not
> mistaken. (Standard section 3.18)
Yes, I must retract that. Although, I think unspecified behavior would
be ok. E.g.
#include <stdlib.h>
int main (void)
{
if ("abc" == "abc") exit(EXIT_SUCCESS);
exit(EXIT_SUCCESS);
}
>> Returning to I/O, the only remaining question I have is whether to
>> following is strictly conforming or not:
>>
>> #include <stdio.h>
>> #include <stdlib.h>
>> int main (void)
>> {
>> fputc('a', stdout);
>> exit(EXIT_SUCCESS);
>> }
>>
>> The standard says whether or not a newline character is required on
>> the last line of output is implementation-defined. One can argue
>> that it is not a strictly conforming program because the program
>> does not insert the final newline character.
>
> Yes; I would too. Inserting the last putc('\n') would in my opinion make
> the program strictly conforming.
No. If you say the above program is not strictly conforming, then
neither would this:
#include <stdio.h>
#include <stdlib.h>
int main (void)
{
fputc('a', stdout);
fputc('\n', stdout);
exit(EXIT_SUCCESS);
}
because the second fputc() may fail, and thus behave like the program
you already said was not strictly conforming.
>> However, I would still argue that the program *is* strictly
>> conforming. Before the call to exit(), the definition of what
>> fputc() does is well defined (7.19.7.3). It is only after control is
>> released back to the host environment through exit() that the stdout
>> stream may have a last line that does not end with a newline. But,
>> at that point, everything is in control of the host environment, the
>> program has already finished its task.
>
> Not quite; you leave out the "clean-up" which the program must do
> before returning to the host environment. I think the implementation
> is allowed to catch the error here.
Right. All streams are flushed, and all associated files are closed.
But the standard only says "whether the last line requires a terminating
new-line character is implementation-defined." There is no behavior
implied in this statement, so it is reasonable that this is a case of
the C standard calling out an /implementation-defined value/.
>> The the program did not produce output ('a' on stdout and the
>> termination status) dependent on any unspecified, undefined, or
>> implementation-defined behavior. The form of the output becomes
>> implementation-defined after the termination of the program.
>
> ITYM "after the end of main." And implementation-defined output is a
> no-no for strictly conforming programs.
That is too restrictive, since the format of all output is
implementation-defined. If the committee intended that no strictly
conforming program produce implementation-defined output, they
would not have bothered to discuss I/O in the least requirements
for a conforming implementation (5.1.2.3/5). Remember, the
definition said a strictly conforming program "shall not produce
output dependent on ... implementation-defined behavior." The
format of the output is not dependent on implementation-defined
behavior. The format of the output itself is an implementation
defined value.
>> Now, back to the hello world example:
>>
>> #include <stdio.h>
>> int main (void)
>> {
>> puts("Hello world.");
>> return 0;
>> }
> [snip]
>> By my previous arguments, this program is still strictly conforming.
>
> By my previous arguments, this program is not strictly conforming.
I don't think there is anything more I can contribute to this thread.
-- James