program output?

[bnp]

Hi,

I took a test on C.
there was an objective question for program output type.
following is the program:

main()
{
char ch;
int i =2;
for (ch=0;ch<128;ch++)
i+=2;
printf("%d",i);
}
i wrote the answer 256 will be printed.
But our instructor told me that it will be infinite loop.
Is that right, I am not sure of the answer.

Regards,

Bhavik

[Leor Zolman]

On 24 May 2004 04:20:00 -0700, bh**********@yahoo.com (bnp) wrote:

Hi,

I took a test on C.
there was an objective question for program output type.
following is the program:

main()
{
char ch;
int i =2;
for (ch=0;ch<128;ch++)
i+=2;
printf("%d",i);
}
i wrote the answer 256 will be printed.
But our instructor told me that it will be infinite loop.
Is that right, I am not sure of the answer.
Kinda tricky.
First of all, the default "signedness" of the char type is
platform-dependent. If it is 8 bits and "signed", as is the default on
typical PC-based platforms, then this does indeed go into an infinite loop.
In that case, the range of values for an 8-bit char is -128 to +127. It
will always be less than +128.

If the default for chars is unsigned, then the program output is 258 [I
didn't figure it out, I just ran it ;-) ]
-leor

Regards,

Bhavik

--
Leor Zolman --- BD Software --- www.bdsoft.com
On-Site Training in C/C++, Java, Perl and Unix
C++ users: download BD Software's free STL Error Message Decryptor at:
www.bdsoft.com/tools/stlfilt.html

[Pieter Droogendijk]

On Mon, 24 May 2004 04:20:00 -0700, bnp wrote:

Hi,

I took a test on C.
there was an objective question for program output type.
following is the program:

main()
int main () or int main (void) is preferred.
{
Proper indentation is a Good Thing(tm), even for trivial examples such as
this.
char ch;
int i =2;
for (ch=0;ch<128;ch++)
i+=2;
printf("%d",i);
}
i wrote the answer 256 will be printed.
But our instructor told me that it will be infinite loop.
Is that right, I am not sure of the answer.

Your instructor may have been right. It all depends on CHAR_MAX, which may
be 127 if char is signed. If this is the case, ch will never be >= 128,
and the loop will never end. If CHAR_MAX is greater than 127 (because it's
unsigned, or because char has more than 8 value bits), then it may print
258 (and will for sure if you print a newline or flush stdout).

--
int main(void){int putchar(int),i=0;unsigned long t=500555079,n[]={t
,159418370,88921539,286883974,80500161,0};while(n[i])putchar(*(!(t&1
)+!(t||!++i)+"# \n")),(t&&1+(t>>=i-~-i))||(t=n[i]^n[i-1]);return 0;}

[Arthur J. O'Dwyer]

On Mon, 24 May 2004, bnp wrote:

I took a test on C.
there was an objective question for program output type.
following is the program:


Good style dictates the inclusion of <stdio.h> (see errors regarding
'printf' below).
main()
_int_ main() required for C99; _int_ main(_void_) preferred in both
C89 and C99. (Where _this_ indicates emphasis, not literal underscores.)
{
char ch;
Lack of indentation is a bad thing and should be avoided, especially
on Usenet and on school tests. Also, everywhere else.
int i =2;
for (ch=0;ch<128;ch++)
Non-strict-conformance: program behavior depends on signedness of
plain char.
Possible undefined behavior: If char is signed and has eight bits,
signed integer overflow will occur.
i+=2;
printf("%d",i);
Possible linker error: 'printf' undefined.
Undefined behavior: variadic function 'printf' called without
prototype in scope.
Constraint violation (is that correct?): program output ends
without terminating newline '\n'.
}
i wrote the answer 256 will be printed.
But our instructor told me that it will be infinite loop.
Is that right, I am not sure of the answer.

Yes, you are both "right." Only the program is wrong.

-Arthur

[CBFalconer]

Pieter Droogendijk wrote:

On Mon, 24 May 2004 04:20:00 -0700, bnp wrote:

I took a test on C.
there was an objective question for program output type.
following is the program:

main()

int main () or int main (void) is preferred.

{

Proper indentation is a Good Thing(tm), even for trivial examples
such as this.

char ch;
int i =2;
for (ch=0;ch<128;ch++)
i+=2;
printf("%d",i);
}
i wrote the answer 256 will be printed.
But our instructor told me that it will be infinite loop.
Is that right, I am not sure of the answer.

Your instructor may have been right. It all depends on CHAR_MAX,
which may be 127 if char is signed. If this is the case, ch will
never be >= 128, and the loop will never end. If CHAR_MAX is
greater than 127 (because it's unsigned, or because char has
more than 8 value bits), then it may print 258 (and will for
sure if you print a newline or flush stdout).

No, in that (signed) case you will overflow ch, and behaviour
becomes undefined. So it may well print "the instructor is full
of it" or do anything else.

--
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[buda]

So overflow is undefined? I thought that the "overflowed bit" gets discarded
and you end up with the "next" number, which in this case might be -128 (if
char is 8 bits signed, then gets to 127 which is 0111 1111, thus adding one
in binary will make it 1000 0000 which translates into -128). I actually
expect this to be "not defined" by the standard, but this is the behavior on
most (if not all) machines I have seen.

"CBFalconer" <cb********@yahoo.com> wrote in message
news:40***************@yahoo.com...

Pieter Droogendijk wrote:

On Mon, 24 May 2004 04:20:00 -0700, bnp wrote:

I took a test on C.
there was an objective question for program output type.
following is the program:

main()

int main () or int main (void) is preferred.

{

Proper indentation is a Good Thing(tm), even for trivial examples
such as this.

char ch;
int i =2;
for (ch=0;ch<128;ch++)
i+=2;
printf("%d",i);
}
i wrote the answer 256 will be printed.
But our instructor told me that it will be infinite loop.
Is that right, I am not sure of the answer.

Your instructor may have been right. It all depends on CHAR_MAX,
which may be 127 if char is signed. If this is the case, ch will
never be >= 128, and the loop will never end. If CHAR_MAX is
greater than 127 (because it's unsigned, or because char has
more than 8 value bits), then it may print 258 (and will for
sure if you print a newline or flush stdout).

No, in that (signed) case you will overflow ch, and behaviour
becomes undefined. So it may well print "the instructor is full
of it" or do anything else.

--
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[Dan Pop]

In <47********************************@4ax.com> Leor Zolman <le**@bdsoft.com> writes:

On 24 May 2004 04:20:00 -0700, bh**********@yahoo.com (bnp) wrote:

I took a test on C.
there was an objective question for program output type.
following is the program:

main()
{
char ch;
int i =2;
for (ch=0;ch<128;ch++)
i+=2;
printf("%d",i);
}
i wrote the answer 256 will be printed.
But our instructor told me that it will be infinite loop.
Is that right, I am not sure of the answer.
Kinda tricky.

Not really: the code invokes undefined behaviour at least once, by calling
printf without a proper declaration in scope, so it is not even worth
analysing it: anything can legally happen.
First of all, the default "signedness" of the char type is
platform-dependent. If it is 8 bits and "signed", as is the default on
typical PC-based platforms, then this does indeed go into an infinite loop.
Can we have a chapter and verse for that? I naively thought that signed
overflow results in undefined behaviour...
In that case, the range of values for an 8-bit char is -128 to +127.
Can we have a chapter and verse for that? I naively thought that the
standard only guaranteed -127 to 127 and that sign-magnitude and one's
complement implementations are perfectly OK...
It will always be less than +128.
True, but by the time it makes the transition from 127 to whatever value
(if any), anything can happen... including getting out of the loop.
If the default for chars is unsigned, then the program output is 258 [I
didn't figure it out, I just ran it ;-) ]

Maybe, maybe not. As the last line of output is not newline terminated,
there is no guarantee that the program will produce any output at all
(it's an implementation-defined feature).

Whoever wrote this test expecting another answer than "undefined
behaviour" should better start learning C...

Here's a properly rewritten version of this test:

Assuming 8-bit bytes, what is the output of the following program?

#include <stdio.h>

int main()
{
unsigned char ch;
unsigned int i = 2;

for (ch = 0; ch < 256; ch++) i += 2;
printf("%u\n", i);
return 0;
}

Note that if i is plain int, signed overflow will occur inside the
infinite loop, and all the bets are off, again.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Ralmin]

"buda" <ku*****@hotmail.com> wrote:

So overflow is undefined? I thought that the "overflowed bit" gets
discarded and you end up with the "next" number, which in this case
might be -128 (if char is 8 bits signed, then gets to 127 which is
0111 1111, thus adding one in binary will make it 1000 0000 which
translates into -128). I actually expect this to be "not defined"
by the standard, but this is the behavior on most (if not all)
machines I have seen.

Yes, signed integer overflow is undefined behaviour in C. Some machines trap
on overflow, others discard the overflow like you describe. In that case it
depends on whether the signed integer is using 2's complement, 1's
complement or the signed magnitude system.

In 8-bit 2's complement, 1000 0000 is -128
In 8-bit 1's complement, 1000 0000 is -127
In 8-bit signed magnitude, 1000 0000 is negative zero, which might be a
valid result, or might itself be a trap representation.

There might even be more wacky forms of undefined behaviour that occur on
overflow.

--
Simon.

[Martin Dickopp]

"Arthur J. O'Dwyer" <aj*@nospam.andrew.cmu.edu> writes:

On Mon, 24 May 2004, bnp wrote:

printf("%d",i);

Constraint violation (is that correct?): program output ends
without terminating newline '\n'.

Implementation-defined and possibly undefined behavior. See 7.19.2#2:
"A text stream is an ordered sequence of characters composed into lines,
each line consisting of zero or more characters plus a terminating new-
line character. Whether the last line requires a terminating new-line
character is implementation-defined. [...]"

Martin
--
,--. Martin Dickopp, Dresden, Germany ,= ,-_-. =.
/ ,- ) http://www.zero-based.org/ ((_/)o o(\_))
\ `-' `-'(. .)`-'
`-. Debian, a variant of the GNU operating system. \_/

[buda]

"Ralmin" <ne**@ralminNOSPAM.cc> wrote in message
news:d0******************************@news.teranew s.com...

Yes, signed integer overflow is undefined behaviour in C. Some machines trap on overflow, others discard the overflow like you describe. In that case it depends on whether the signed integer is using 2's complement, 1's
complement or the signed magnitude system.

In 8-bit 2's complement, 1000 0000 is -128
In 8-bit 1's complement, 1000 0000 is -127
In 8-bit signed magnitude, 1000 0000 is negative zero, which might be a
valid result, or might itself be a trap representation.

There might even be more wacky forms of undefined behaviour that occur on
overflow.

--
Simon.

Thanks for the answer.

[CBFalconer]

*** Rude top-posting fixed ***

buda wrote:

"CBFalconer" <cb********@yahoo.com> wrote in message

Pieter Droogendijk wrote:

On Mon, 24 May 2004 04:20:00 -0700, bnp wrote:

I took a test on C.
there was an objective question for program output type.
following is the program:

main()

int main () or int main (void) is preferred.

{

Proper indentation is a Good Thing(tm), even for trivial examples
such as this.

char ch;
int i =2;
for (ch=0;ch<128;ch++)
i+=2;
printf("%d",i);
}
i wrote the answer 256 will be printed.
But our instructor told me that it will be infinite loop.
Is that right, I am not sure of the answer.

Your instructor may have been right. It all depends on CHAR_MAX,
which may be 127 if char is signed. If this is the case, ch will
never be >= 128, and the loop will never end. If CHAR_MAX is
greater than 127 (because it's unsigned, or because char has
more than 8 value bits), then it may print 258 (and will for
sure if you print a newline or flush stdout).

No, in that (signed) case you will overflow ch, and behaviour
becomes undefined. So it may well print "the instructor is full
of it" or do anything else.

So overflow is undefined? I thought that the "overflowed bit" gets
discarded and you end up with the "next" number, which in this
case might be -128 (if char is 8 bits signed, then gets to 127
which is 0111 1111, thus adding one in binary will make it 1000
0000 which translates into -128). I actually expect this to be
"not defined" by the standard, but this is the behavior on most
(if not all) machines I have seen.

Undefined for signed quantities. Defined for unsigned ones. This
is all spelled out in the standard, so there is no need to guess.
Your description is only one form undefined behaviour may take.
Undefined behaviour could also be for the machine to post spam
offering large rewards for the assasination of top-posters.

--
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[Emmanuel Delahaye]

In 'comp.lang.c', bh**********@yahoo.com (bnp) wrote:

I took a test on C.
there was an objective question for program output type.
following is the program:

This program invokes an undefined behaviour. For many reasons, its output is
not predictable.

Here are my comments.

/* -ed- Missing fot printf() (mandatory) */
#include <stdio.h>

int main ()
{
/* -ed- 128 is not guaranteed to fit into a char.
* It fits into an unsigned char.
*/
unsigned char ch;
int i = 2;

for (ch = 0; ch < 128; ch++)
{
i += 2;
}
/* -ed- Curly brackets added for safety and look. */

/* -ed- '\n' added to be sure to see the output.*/
printf ("%d\n", i);

/* -ed- Because main() returns an int */
return 0;
}

Once fixed, the result is 2 + 128 * 2 = 258.

--
-ed- get my email here: http://marreduspam.com/ad672570
The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html
C-reference: http://www.dinkumware.com/manuals/reader.aspx?lib=c99
FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/

[Leor Zolman]

On 24 May 2004 17:33:21 GMT, Da*****@cern.ch (Dan Pop) wrote:

In <47********************************@4ax.com> Leor Zolman <le**@bdsoft.com> writes:

On 24 May 2004 04:20:00 -0700, bh**********@yahoo.com (bnp) wrote:

I took a test on C.
there was an objective question for program output type.
following is the program:

main()
{
char ch;
int i =2;
for (ch=0;ch<128;ch++)
i+=2;
printf("%d",i);
}
i wrote the answer 256 will be printed.
But our instructor told me that it will be infinite loop.
Is that right, I am not sure of the answer.

Kinda tricky.

Not really: the code invokes undefined behaviour at least once, by calling
printf without a proper declaration in scope, so it is not even worth
analysing it: anything can legally happen.

Sure, technically this (and all the rest of it) may be correct. I responded
from an exam question standpoint: "What will it do?" (IOW, "What does it do
for the instructor?"), rather than "What does the Standard say?" (applying
the usual rigor expected for answers to general questions in this group). I
should have prefaced my response accordingly.
-leor

--
Leor Zolman --- BD Software --- www.bdsoft.com
On-Site Training in C/C++, Java, Perl and Unix
C++ users: download BD Software's free STL Error Message Decryptor at:
www.bdsoft.com/tools/stlfilt.html

[Arthur J. O'Dwyer]

On Mon, 24 May 2004, Martin Dickopp wrote:

"Arthur J. O'Dwyer" <aj*@nospam.andrew.cmu.edu> writes:

Constraint violation (is that correct?): program output ends
without terminating newline '\n'.

Implementation-defined and possibly undefined behavior. See 7.19.2#2:
"A text stream is an ordered sequence of characters composed into lines,
each line consisting of zero or more characters plus a terminating new-
line character. Whether the last line requires a terminating new-line
character is implementation-defined. [...]"

Thanks for the quote. But what's the quote that tells us that if
we fail to do something that is, quote, "required," that we invoke
undefined behavior? I don't see anything relevant upon a quick scan
of Appendix J, either...

-Arthur

[Arthur J. O'Dwyer]

On Mon, 24 May 2004, Leor Zolman wrote:

On 24 May 2004 17:33:21 GMT, Da*****@cern.ch (Dan Pop) wrote:

Leor Zolman <le**@bdsoft.com> writes:

On 24 May 2004 04:20:00 -0700, bh**********@yahoo.com (bnp) wrote:

I took a test on C.
there was an objective question for program output type.
following is the program: <snip>i wrote the answer 256 will be printed.
But our instructor told me that it will be infinite loop.

Kinda tricky.
Not really: the code invokes undefined behaviour

Sure, technically this (and all the rest of it) may be correct. I responded
from an exam question standpoint: "What will it do?" (IOW, "What does it do
for the instructor?"), rather than "What does the Standard say?" (applying
the usual rigor expected for answers to general questions in this group). I
should have prefaced my response accordingly.

However --- and I speak from personal experience at high school and
college levels --- it is almost always easier to prove to the instructor
that the code is faulty, than it is to try to guess what the instructor
was thinking.

In this case, the OP had two choices: write down what he thought the
instructor wanted, or raise his hand and say "Excuse me, there seems to
be a bug in this program... could you clarify the problem, please?"
Best case, the instructor realizes the problem is unsolvable and gives
everybody in the class extra credit. Worst case, the instructor says,
"char is unsigned and <stdio.h> is included," and the OP is back where
he started.
The OP had better have hoped for the best-case scenario, since his
guess turned out to be wrong. By drawing attention to the bugs in
the program, he would have maximized his chances of getting credit for
the question.

Again, I speak from experience, and am not being pedantic merely
for pedantry's sake. If the OP can learn to recognize common errors
in C programs, then he stands to benefit in the short term. (In the
long term, he won't be dealing with contrived C programs anymore, and
he'll have to learn common *correct* ways to *write* C programs. But
this is a good way to start. :)

-Arthur

[Old Wolf]

bh**********@yahoo.com (bnp) wrote:

I took a test on C.
there was an objective question for program output type.
following is the program:

main()
{
char ch;
int i =2;
for (ch=0;ch<128;ch++)
i+=2;
printf("%d",i);
}
i wrote the answer 256 will be printed.
But our instructor told me that it will be infinite loop.
Is that right, I am not sure of the answer.

^^^^^^^^^^^^^^^^^^^^^^^^^^^
Good work. Since the behaviour is undefined (if CHAR_MAX is 127),
it is not possible to be sure of the answer.

[Martin Dickopp]

"Arthur J. O'Dwyer" <aj*@nospam.andrew.cmu.edu> writes:

On Mon, 24 May 2004, Martin Dickopp wrote:

"Arthur J. O'Dwyer" <aj*@nospam.andrew.cmu.edu> writes:

>
> Constraint violation (is that correct?): program output ends
> without terminating newline '\n'.

Implementation-defined and possibly undefined behavior. See 7.19.2#2:
"A text stream is an ordered sequence of characters composed into lines,
each line consisting of zero or more characters plus a terminating new-
line character. Whether the last line requires a terminating new-line
character is implementation-defined. [...]"

Thanks for the quote. But what's the quote that tells us that if
we fail to do something that is, quote, "required," that we invoke
undefined behavior?

Assuming the case that the implementation requires a terminating newline
character, the standard doesn't say what should happen if there is no
such character. Therefore, the behavior is undefined since it is not
explicitly defined, as per 4#2: "[...] Undefined behavior is otherwise
indicated in this International Standard [...] by the omission of any
explicit definition of behavior. [...]"

(That's at least how I understand 7.19.2#2.)

AFAIKT, the term "require" isn't explicitly defined in the standard, so
I understand it in its normal English sense (i.e. unlike a "constraint
violation", a "requirement violation" has no special meaning).

Martin
--
,--. Martin Dickopp, Dresden, Germany ,= ,-_-. =.
/ ,- ) http://www.zero-based.org/ ((_/)o o(\_))
\ `-' `-'(. .)`-'
`-. Debian, a variant of the GNU operating system. \_/

[Leor Zolman]

On Mon, 24 May 2004 17:01:45 -0400 (EDT), "Arthur J. O'Dwyer"
<aj*@nospam.andrew.cmu.edu> wrote:

On Mon, 24 May 2004, Leor Zolman wrote:

On 24 May 2004 17:33:21 GMT, Da*****@cern.ch (Dan Pop) wrote:

>Leor Zolman <le**@bdsoft.com> writes:
>>On 24 May 2004 04:20:00 -0700, bh**********@yahoo.com (bnp) wrote:
>>
>>>I took a test on C.
>>>there was an objective question for program output type.
>>>following is the program:<snip> >>>i wrote the answer 256 will be printed.
>>>But our instructor told me that it will be infinite loop.
>>
>>Kinda tricky.
>
>Not really: the code invokes undefined behaviour

Sure, technically this (and all the rest of it) may be correct. I responded
from an exam question standpoint: "What will it do?" (IOW, "What does it do
for the instructor?"), rather than "What does the Standard say?" (applying
the usual rigor expected for answers to general questions in this group). I
should have prefaced my response accordingly.

However --- and I speak from personal experience at high school and
college levels --- it is almost always easier to prove to the instructor
that the code is faulty, than it is to try to guess what the instructor
was thinking.

<OT>
I'm tempted to change the subject now to "[OT]: Challenging instructors" or
something. This could be an interesting topic, but it seems pretty OT.

In this case, the OP had two choices: write down what he thought the
instructor wanted, or raise his hand and say "Excuse me, there seems to
be a bug in this program... could you clarify the problem, please?"
If the OP knew there was a bug. But the question he posted was about what
the program would do. How many students, in that position, and with an
instructor who writes exam questions like /that/ (the declaration of main
was, IMO, particularly egregious), would be likely to detect a "flaw" in
the question? To be able to ask, you have to have a handle on what to ask.
From what I see, the most likely question to come up in this example would
have been regarding the signed-ness of char. I would /hope/ the fact that
this is implementation-dependent would have been discussed in class, but I
wouldn't bet on it. Given that, I'd put the chances near zero that there
was any discussion in that course about how not including <stdio.h> invokes
UB with printf (I can't even say I fully understand that myself right now),
or what happens when the last line of output is unterminated. Unless they'd
had access to a C99 compiler in strict mode, I doubt these issues would
have shown up even if they'd been written into programs.

I get the feeling that if someone /did/ bring up the stdio.h or line
termination issue, the instructor either wouldn't know what the student was
talking about, or brush it off with a roll of the eyes and a "Just
assume...."
Best case, the instructor realizes the problem is unsolvable and gives
everybody in the class extra credit. Worst case, the instructor says,
"char is unsigned and <stdio.h> is included," and the OP is back where
he started.
The OP had better have hoped for the best-case scenario, since his
guess turned out to be wrong. By drawing attention to the bugs in
the program, he would have maximized his chances of getting credit for
the question.
A good instructor loves to be corrected and/or challenged by students, but
I've (unfortunately) also seen some that it would have been a grievous
tactical error to point out some of those issues to. Unfortunately, those
latter types often tend to have a disproportional amount of political clout
in the learning institution, for some Godforsaken reason...

Again, I speak from experience, and am not being pedantic merely
for pedantry's sake. If the OP can learn to recognize common errors
in C programs, then he stands to benefit in the short term. (In the
long term, he won't be dealing with contrived C programs anymore, and
he'll have to learn common *correct* ways to *write* C programs. But
this is a good way to start. :)
Reading this newsgroup could definitely accelerate one's coming-of-age as a
C programmer (though perhaps not as much as posting and then being brave
enough to actually read the responses). At the beginning level, however, I
suspect most students' neurons are busy enough trying to remember how to
define and use pointers, stay within array bounds, understand flow control,
and (with the especially clueless instructors) memorizing the precedence
table, to have the capacity left to pursue distinctions of UB between
signed and unsigned integral values. The ones who do, are probably destined
to be future regulars in this group ;-)
-leor
</OT>

-Arthur

--
Leor Zolman --- BD Software --- www.bdsoft.com
On-Site Training in C/C++, Java, Perl and Unix
C++ users: download BD Software's free STL Error Message Decryptor at:
www.bdsoft.com/tools/stlfilt.html

[Jack Klein]

On Tue, 25 May 2004 00:09:35 +0200, Martin Dickopp
<ex****************@zero-based.org> wrote in comp.lang.c:

"Arthur J. O'Dwyer" <aj*@nospam.andrew.cmu.edu> writes:

On Mon, 24 May 2004, Martin Dickopp wrote:

"Arthur J. O'Dwyer" <aj*@nospam.andrew.cmu.edu> writes:
>
> Constraint violation (is that correct?): program output ends
> without terminating newline '\n'.

Implementation-defined and possibly undefined behavior. See 7.19.2#2:
"A text stream is an ordered sequence of characters composed into lines,
each line consisting of zero or more characters plus a terminating new-
line character. Whether the last line requires a terminating new-line
character is implementation-defined. [...]"

Thanks for the quote. But what's the quote that tells us that if
we fail to do something that is, quote, "required," that we invoke
undefined behavior?

Assuming the case that the implementation requires a terminating newline
character, the standard doesn't say what should happen if there is no
such character. Therefore, the behavior is undefined since it is not
explicitly defined, as per 4#2: "[...] Undefined behavior is otherwise
indicated in this International Standard [...] by the omission of any
explicit definition of behavior. [...]"

(That's at least how I understand 7.19.2#2.)

AFAIKT, the term "require" isn't explicitly defined in the standard, so
I understand it in its normal English sense (i.e. unlike a "constraint
violation", a "requirement violation" has no special meaning).

Martin

Anything that the standard specifies as "implementation-defined", a
term which is precisely defined in the standard, cannot result in
undefined behavior.

The implementation is required to select one of the available choices,
in this case either the last line appears in the output stream if no
terminating new-line is present, or it does not. And the
implementation is required to document its choice, therefore defining
the behavior for that implementation.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html

[Martin Dickopp]

Jack Klein <ja*******@spamcop.net> writes:

On Tue, 25 May 2004 00:09:35 +0200, Martin Dickopp
<ex****************@zero-based.org> wrote in comp.lang.c:

"Arthur J. O'Dwyer" <aj*@nospam.andrew.cmu.edu> writes:

> On Mon, 24 May 2004, Martin Dickopp wrote:
>>
>> "Arthur J. O'Dwyer" <aj*@nospam.andrew.cmu.edu> writes:
>> >
>> > Constraint violation (is that correct?): program output ends
>> > without terminating newline '\n'.
>>
>> Implementation-defined and possibly undefined behavior. See 7.19.2#2:
>> "A text stream is an ordered sequence of characters composed into lines,
>> each line consisting of zero or more characters plus a terminating new-
>> line character. Whether the last line requires a terminating new-line
>> character is implementation-defined. [...]"
>
> Thanks for the quote. But what's the quote that tells us that if
> we fail to do something that is, quote, "required," that we invoke
> undefined behavior?

Assuming the case that the implementation requires a terminating newline
character, the standard doesn't say what should happen if there is no
such character. Therefore, the behavior is undefined since it is not
explicitly defined, as per 4#2: "[...] Undefined behavior is otherwise
indicated in this International Standard [...] by the omission of any
explicit definition of behavior. [...]"

(That's at least how I understand 7.19.2#2.)

AFAIKT, the term "require" isn't explicitly defined in the standard, so
I understand it in its normal English sense (i.e. unlike a "constraint
violation", a "requirement violation" has no special meaning).

Anything that the standard specifies as "implementation-defined", a
term which is precisely defined in the standard, cannot result in
undefined behavior.

The implementation is required to select one of the available choices,
in this case either the last line appears in the output stream if no
terminating new-line is present, or it does not. And the
implementation is required to document its choice, therefore defining
the behavior for that implementation.

Let's assume an implementation that has documented that the last line
requires a terminating newline character. On such an implementation,
the following program is not correct:

#include <stdio.h>
int main (void) { putchar ('x'); return 0; }

I would have thought the behavior of the program is undefined on such an
implementation. If that is not the case, what is the behavior of the
above program on such an implementation?

Martin
--
,--. Martin Dickopp, Dresden, Germany ,= ,-_-. =.
/ ,- ) http://www.zero-based.org/ ((_/)o o(\_))
\ `-' `-'(. .)`-'
`-. Debian, a variant of the GNU operating system. \_/

[Richard Bos]

Martin Dickopp <ex****************@zero-based.org> wrote:

Jack Klein <ja*******@spamcop.net> writes:

The implementation is required to select one of the available choices,
in this case either the last line appears in the output stream if no
terminating new-line is present, or it does not. And the
implementation is required to document its choice, therefore defining
the behavior for that implementation.

Let's assume an implementation that has documented that the last line
requires a terminating newline character. On such an implementation,
the following program is not correct:

#include <stdio.h>
int main (void) { putchar ('x'); return 0; }

I would have thought the behavior of the program is undefined on such an
implementation. If that is not the case, what is the behavior of the
above program on such an implementation?

However that implementation defines it; and note that, because this is
implementation-defined, not undefined, the implementation must define
this some way or other _and_ document this choice. So: read your
implementation's documentation for the answer to your question.

Richard

[Martin Dickopp]

rl*@hoekstra-uitgeverij.nl (Richard Bos) writes:

Martin Dickopp <ex****************@zero-based.org> wrote:

Jack Klein <ja*******@spamcop.net> writes:

> The implementation is required to select one of the available choices,
> in this case either the last line appears in the output stream if no
> terminating new-line is present, or it does not. And the
> implementation is required to document its choice, therefore defining
> the behavior for that implementation.

Let's assume an implementation that has documented that the last line
requires a terminating newline character. On such an implementation,
the following program is not correct:

#include <stdio.h>
int main (void) { putchar ('x'); return 0; }

I would have thought the behavior of the program is undefined on such an
implementation. If that is not the case, what is the behavior of the
above program on such an implementation?

However that implementation defines it; and note that, because this is
implementation-defined, not undefined, the implementation must define
this some way or other _and_ document this choice. So: read your
implementation's documentation for the answer to your question.

I do understand what "implementation-defined" means, but I don't
understand /why/ this is implementation-defined.

The relevant sentence in 7.19.2#2 is: "Whether the last line requires a
terminating new-line character is implementation-defined."

Maybe my understanding of English is faulty, but I would have thought
the above sentence means that the implementation has to choose between
"the last line requires a terminating new-line character" and "the last
line does not require a terminating new-line character".

Why does the sentence imply that in the former case, the implementation
/also/ has to define the behavior if there is no terminating new-line
character, or if it doesn't imply that, what other part of the standard
requires it?

Martin
--
,--. Martin Dickopp, Dresden, Germany ,= ,-_-. =.
/ ,- ) http://www.zero-based.org/ ((_/)o o(\_))
\ `-' `-'(. .)`-'
`-. Debian, a variant of the GNU operating system. \_/

[Arthur J. O'Dwyer]

[N.B: xpost added]

On Tue, 25 May 2004, Richard Bos wrote:

Martin Dickopp <ex****************@zero-based.org> wrote:

Jack Klein <ja*******@spamcop.net> writes:

The implementation is required to select one of the available choices,
in this case either the last line appears in the output stream if no
terminating new-line is present, or it does not. And the
implementation is required to document its choice, therefore defining
the behavior for that implementation.

Let's assume an implementation that has documented that the last line
requires a terminating newline character. On such an implementation,
the following program is not correct:

#include <stdio.h>
int main (void) { putchar ('x'); return 0; }

I would have thought the behavior of the program is undefined on such an
implementation. If that is not the case, what is the behavior of the
above program on such an implementation?

However that implementation defines it; and note that, because this is
implementation-defined, not undefined, the implementation must define
this some way or other _and_ document this choice. So: read your
implementation's documentation for the answer to your question.

And if the implementation's documentation says, "This behavior is
undefined," then it is undefined, right? For precedent, look at the
way implementations define what happens on the overflow of plain
'char' values.

I think this needs clarification. Crossposted to comp.std.c.
One-line summary: What can happen with a program whose output doesn't
end with a newline?

-Arthur

[Richard Bos]

Martin Dickopp <ex****************@zero-based.org> wrote:

rl*@hoekstra-uitgeverij.nl (Richard Bos) writes:

However that implementation defines it; and note that, because this is
implementation-defined, not undefined, the implementation must define
this some way or other _and_ document this choice. So: read your
implementation's documentation for the answer to your question.

I do understand what "implementation-defined" means, but I don't
understand /why/ this is implementation-defined.

The relevant sentence in 7.19.2#2 is: "Whether the last line requires a
terminating new-line character is implementation-defined."

Maybe my understanding of English is faulty, but I would have thought
the above sentence means that the implementation has to choose between
"the last line requires a terminating new-line character" and "the last
line does not require a terminating new-line character".

Why does the sentence imply that in the former case, the implementation
/also/ has to define the behavior if there is no terminating new-line
character, or if it doesn't imply that, what other part of the standard
requires it?

Good point. IYAM, mere decency would dictate that this should not cause
any unpleasant effects beyond what is strictly documented, and that
"whether it needs... is i-d" includes "and what happens if not is also
i-d", but I agree that this is not made explicit.

Richard

[Dan Pop]

In <to********************************@4ax.com> Leor Zolman <le**@bdsoft.com> writes:

On 24 May 2004 17:33:21 GMT, Da*****@cern.ch (Dan Pop) wrote:

In <47********************************@4ax.com> Leor Zolman <le**@bdsoft.com> writes:

On 24 May 2004 04:20:00 -0700, bh**********@yahoo.com (bnp) wrote:

I took a test on C.
there was an objective question for program output type.
following is the program:

main()
{
char ch;
int i =2;
for (ch=0;ch<128;ch++)
i+=2;
printf("%d",i);
}
i wrote the answer 256 will be printed.
But our instructor told me that it will be infinite loop.
Is that right, I am not sure of the answer.

Kinda tricky.
Not really: the code invokes undefined behaviour at least once, by calling
printf without a proper declaration in scope, so it is not even worth
analysing it: anything can legally happen.

Sure, technically this (and all the rest of it) may be correct. I responded
from an exam question standpoint: "What will it do?" (IOW, "What does it do
for the instructor?"), rather than "What does the Standard say?" (applying
the usual rigor expected for answers to general questions in this group).

What makes you think the two answers are any different?
I should have prefaced my response accordingly.

You have actually explained what the instructor expected from the program.
Such an explanation is downright misleading without pointing out the
flaws in his reasoning.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Leor Zolman]

On 25 May 2004 17:13:40 GMT, Da*****@cern.ch (Dan Pop) wrote:

Sure, technically this (and all the rest of it) may be correct. I responded
from an exam question standpoint: "What will it do?" (IOW, "What does it do
for the instructor?"), rather than "What does the Standard say?" (applying
the usual rigor expected for answers to general questions in this group).
What makes you think the two answers are any different?

I have to explain the difference between "What will it do on [your/my]
machine?" vs. "What does the Standard say about this?" ??

I should have prefaced my response accordingly.
You have actually explained what the instructor expected from the program.
Such an explanation is downright misleading without pointing out the
flaws in his reasoning.

His "reasoning" evidently includes domain-specific preconditions about the
platform in use, size of a char, and perhaps even signed-ness of a char.
Given a tacit conspiracy by everyone in the classroom to assume those
preconditions, his reasoning wasn't necessarily flawed.

The next time I teach a C class, there's a good chance some, or even most,
of the issues involved here will not come up. It's just a matter of
choosing one's battles in the theater of time constraints.
-leor

Dan

--
Leor Zolman --- BD Software --- www.bdsoft.com
On-Site Training in C/C++, Java, Perl and Unix
C++ users: download BD Software's free STL Error Message Decryptor at:
www.bdsoft.com/tools/stlfilt.html

[j0mbolar]

Da*****@cern.ch (Dan Pop) wrote in message news:<c8**********@sunnews.cern.ch>...

In <47********************************@4ax.com> Leor Zolman <le**@bdsoft.com> writes:

On 24 May 2004 04:20:00 -0700, bh**********@yahoo.com (bnp) wrote:

I took a test on C.
there was an objective question for program output type.
following is the program:

main()
{
char ch;
int i =2;
for (ch=0;ch<128;ch++)
i+=2;
printf("%d",i);
}
i wrote the answer 256 will be printed.
But our instructor told me that it will be infinite loop.
Is that right, I am not sure of the answer.

Kinda tricky.

Not really: the code invokes undefined behaviour at least once, by calling
printf without a proper declaration in scope, so it is not even worth
analysing it: anything can legally happen.

How do you figure? I see 6.5.2.2#6 says the default argument
promotions occur but it does not mention undefiend behavior
in this case.

First of all, the default "signedness" of the char type is
platform-dependent. If it is 8 bits and "signed", as is the default on
typical PC-based platforms, then this does indeed go into an infinite loop.

Can we have a chapter and verse for that? I naively thought that signed
overflow results in undefined behaviour...

In that case, the range of values for an 8-bit char is -128 to +127.

Can we have a chapter and verse for that? I naively thought that the
standard only guaranteed -127 to 127 and that sign-magnitude and one's
complement implementations are perfectly OK...

It will always be less than +128.

True, but by the time it makes the transition from 127 to whatever value
(if any), anything can happen... including getting out of the loop.

If the default for chars is unsigned, then the program output is 258 [I
didn't figure it out, I just ran it ;-) ]

Maybe, maybe not. As the last line of output is not newline terminated,
there is no guarantee that the program will produce any output at all
(it's an implementation-defined feature).

Whoever wrote this test expecting another answer than "undefined
behaviour" should better start learning C...

Here's a properly rewritten version of this test:

Assuming 8-bit bytes, what is the output of the following program?

#include <stdio.h>

int main()
{
unsigned char ch;
unsigned int i = 2;

for (ch = 0; ch < 256; ch++) i += 2;
printf("%u\n", i);
return 0;
}

Note that if i is plain int, signed overflow will occur inside the
infinite loop, and all the bets are off, again.

Dan

[Eric Sosman]

j0mbolar wrote:

Da*****@cern.ch (Dan Pop) wrote in message news:<c8**********@sunnews.cern.ch>...

Not really: the code invokes undefined behaviour at least once, by calling
printf without a proper declaration in scope, so it is not even worth
analysing it: anything can legally happen.

How do you figure? I see 6.5.2.2#6 says the default argument
promotions occur but it does not mention undefiend behavior
in this case.

Read the paragraph again, with special attention to the
fifth sentence.

--
Er*********@sun.com

[Sam Dennis]

j0mbolar wrote:

the code invokes undefined behaviour at least once, by calling printf
without a proper declaration in scope

How do you figure? I see 6.5.2.2#6 says the default argument
promotions occur but it does not mention undefiend behavior
in this case.

Read on in the same paragraph:

`If the function is defined with a type that includes a prototype, and
either the prototype ends with an ellipsis [...], the behaviour is
undefined.' (Note that we're now talking about the definition, not the
type of the expression denoting the function to be called.)

printf, obviously, is such a function.

--
++acr@,ka"

[Douglas A. Gwyn]

Arthur J. O'Dwyer wrote:

And if the implementation's documentation says, "This behavior is
undefined," then it is undefined, right?

No, "implementation defined" behavior involves a choice
between well-defined behaviors, and the implementation
shall document which choice it makes.

[Martin Dickopp]

"Douglas A. Gwyn" <DA****@null.net> writes:

Arthur J. O'Dwyer wrote:

And if the implementation's documentation says, "This behavior is
undefined," then it is undefined, right?

No, "implementation defined" behavior involves a choice
between well-defined behaviors, and the implementation
shall document which choice it makes.

Since only a part of this thread has been x-posted to comp.std.c, please
allow me to clarify what the issue was. Please consider 7.19.2#2:

| A text stream is an ordered sequence of characters composed into
| lines, each line consisting of zero or more characters plus a
| terminating new-line character. Whether the last line requires a
| terminating new-line character is implementation-defined. [...]

Let's assume an implementation that makes the choice (and documents it)
that the last line requires a terminating new-line character. Is such
an implementation required to also define and document the behavior of a
program which writes to a text stream without terminating the last line
with a new-line character? If so, does such a requirement follow from
the above quoted wording, or from some other text in the standard?

Otherwise, can it be assumed that the behavior of such a program is
undefined on such an implementation, since lack of explicit definition
of behavior in the standard means undefined behavior (4#2)?

Martin
--
,--. Martin Dickopp, Dresden, Germany ,= ,-_-. =.
/ ,- ) http://www.zero-based.org/ ((_/)o o(\_))
\ `-' `-'(. .)`-'
`-. Debian, a variant of the GNU operating system. \_/

[Dan Pop]

In <gj********************************@4ax.com> Leor Zolman <le**@bdsoft.com> writes:

On 25 May 2004 17:13:40 GMT, Da*****@cern.ch (Dan Pop) wrote:

Sure, technically this (and all the rest of it) may be correct. I responded
from an exam question standpoint: "What will it do?" (IOW, "What does it do
for the instructor?"), rather than "What does the Standard say?" (applying
the usual rigor expected for answers to general questions in this group).

What makes you think the two answers are any different?

I have to explain the difference between "What will it do on [your/my]
machine?" vs. "What does the Standard say about this?" ??

I should have prefaced my response accordingly.

You have actually explained what the instructor expected from the program.
Such an explanation is downright misleading without pointing out the
flaws in his reasoning.

His "reasoning" evidently includes domain-specific preconditions about the
platform in use, size of a char, and perhaps even signed-ness of a char.
Given a tacit conspiracy by everyone in the classroom to assume those
preconditions, his reasoning wasn't necessarily flawed.

I thought it was supposed to be a question about a C program, not about
an unspecified implementation...

If it's a question about a C program, your answer is downright wrong,
period.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Leor Zolman]

On 26 May 2004 12:40:05 GMT, Da*****@cern.ch (Dan Pop) wrote:

I thought it was supposed to be a question about a C program, not about
an unspecified implementation...

If it's a question about a C program, your answer is downright wrong,
period.
The OP asked about "program output type". What does the Standard have to
say about /that/? ;-)
-leor

Dan

--
Leor Zolman --- BD Software --- www.bdsoft.com
On-Site Training in C/C++, Java, Perl and Unix
C++ users: download BD Software's free STL Error Message Decryptor at:
www.bdsoft.com/tools/stlfilt.html

[Dan Pop]

In <to********************************@4ax.com> Leor Zolman <le**@bdsoft.com> writes:

On 26 May 2004 12:40:05 GMT, Da*****@cern.ch (Dan Pop) wrote:

I thought it was supposed to be a question about a C program, not about
an unspecified implementation...

If it's a question about a C program, your answer is downright wrong,
period.

The OP asked about "program output type". What does the Standard have to
say about /that/? ;-)

Few things are lamer on Usenet than invoking someone's poor command of the
English language...

The subject line of the thread is clear enough, though.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Leor Zolman]

On 26 May 2004 15:48:32 GMT, Da*****@cern.ch (Dan Pop) wrote:

In <to********************************@4ax.com> Leor Zolman <le**@bdsoft.com> writes:

On 26 May 2004 12:40:05 GMT, Da*****@cern.ch (Dan Pop) wrote:

I thought it was supposed to be a question about a C program, not about
an unspecified implementation...

If it's a question about a C program, your answer is downright wrong,
period.
The OP asked about "program output type". What does the Standard have to
say about /that/? ;-)

Few things are lamer on Usenet than invoking someone's poor command of the
English language...

It never even occurred to me that he had poor command of the English
language. His post looks better in that regard than some (perhaps more than
just some) of my own ;-)

So here's where I think we stand. I'm saying I cannot tell whether the OP
was asking "What does the Standard say about what the output should be", as
you interpret the question (and it is certainly a reasonable
interpretation, especially since that's the core flavor of question this
group deals with day-to-day), or if he's really asking, "How was I
supposed to predict what the output of this program would be on our class
platform?" which, given the quality of the question, strikes me as more
likely to reflect actual intent of the instructor. But of course, I don't
know.
-leor

The subject line of the thread is clear enough, though.

Dan

--
Leor Zolman --- BD Software --- www.bdsoft.com
On-Site Training in C/C++, Java, Perl and Unix
C++ users: download BD Software's free STL Error Message Decryptor at:
www.bdsoft.com/tools/stlfilt.html

[Douglas A. Gwyn]

Martin Dickopp wrote:

| A text stream is an ordered sequence of characters composed into
| lines, each line consisting of zero or more characters plus a
| terminating new-line character. Whether the last line requires a
| terminating new-line character is implementation-defined. [...]
Let's assume an implementation that makes the choice (and documents it)
that the last line requires a terminating new-line character. Is such
an implementation required to also define and document the behavior of a
program which writes to a text stream without terminating the last line
with a new-line character?
No, only whether the last line requires a terminating new-line
character needs to be documented.
Otherwise, can it be assumed that the behavior of such a program is
undefined on such an implementation, since lack of explicit definition
of behavior in the standard means undefined behavior (4#2)?

Yes, and more importantly, if the program behavior depends on
whether or not the last line of an input text stream has a
trailing new-line, it is not a strictly conforming program.
(This is a common bug.)

[Arthur J. O'Dwyer]

On Wed, 26 May 2004, Douglas A. Gwyn wrote:

Martin Dickopp wrote:

Let's assume an implementation that makes the choice (and documents it)
that the last line requires a terminating new-line character. Is such
an implementation required to also define and document the behavior of a
program which writes to a text stream without terminating the last line
with a new-line character?

No, only whether the last line requires a terminating new-line
character needs to be documented.

Otherwise, can it be assumed that the behavior of such a program is
undefined on such an implementation, since lack of explicit definition
of behavior in the standard means undefined behavior (4#2)?

Yes, [...]

FWIW, this is in direct contradiction to the opinion you stated two
messages upthread. Consider it evidence that this area of the Standard
could use some better wording. :)

As I understand the Standard's intent: An implementation must document
the behavior of a program whose output does not end in a newline, in
one of two ways: either that the output is printed, or that the behavior
is undefined. If the implementation documents that the behavior is
undefined, then it is allowed to do anything with the program (obviously).

[Again I mention the similarity to plain-char-overflow, another
situation in which it is implementation-defined whether or not the
behavior is undefined.]

-Arthur

[Eric Sosman]

Arthur J. O'Dwyer wrote:

On Wed, 26 May 2004, Douglas A. Gwyn wrote:

As I understand the Standard's intent: An implementation must document
the behavior of a program whose output does not end in a newline, in
one of two ways: either that the output is printed, or that the behavior
is undefined. [...]

There are certainly more than two possibilities. For
example, here's a third: "An un-terminated line will not
appear on the output stream at all."

fputs("Hello,\nworld!", stdout);
exit(0);

.... could be defined to produce "Hello,\n" and nothing else.
(This is a plausible behavior for a record-oriented file
system.)

--
Er*********@sun.com

[Dave Hansen]

On Wed, 26 May 2004 10:01:42 +0200, Martin Dickopp
<ex****************@zero-based.org> wrote:

[...]

Since only a part of this thread has been x-posted to comp.std.c, please
allow me to clarify what the issue was. Please consider 7.19.2#2:

| A text stream is an ordered sequence of characters composed into
| lines, each line consisting of zero or more characters plus a
| terminating new-line character. Whether the last line requires a
| terminating new-line character is implementation-defined. [...]

Interesting. Since the first occurrence of the word "lines" is in
italics, that sentence must be defining what a "line" is. From my
pedantic-mode reading, a "line" includes the terminating new-line by
definition -- otherwise, it's not a "line."

So if the last line doesn't have a terminating new-line it's not a
line. Since it's presumably the last (zero or more) characters in the
stream, the previous line must be the last line. And _it_ does have a
terminating new-line...

Unless the last line is the first line, in which case, there is no
previous line, and therefore no lines at all. Can a text stream have
zero lines? The above definition does not seem to forbid it
("composed into" rather than "composed of").

OK, OK, just having a little fun. But perhaps the last sentence would
be better worded "Whether a text stream requires a final terminating
new-line character..." because it seems (fairly) obvious that is what
is meant. I thought it might be fixed by changing the first sentence
to "...each line separated from the next by a new-line character," but
that would mean the last line could not possibly be terminated by a
new-line...

Regards,

-=Dave
--
Change is inevitable, progress is not.

[Arthur J. O'Dwyer]

On Wed, 26 May 2004, Eric Sosman wrote:

Arthur J. O'Dwyer wrote:

On Wed, 26 May 2004, Douglas A. Gwyn wrote:

As I understand the Standard's intent: An implementation must document
the behavior of a program whose output does not end in a newline, in
one of two ways: either that the output is printed, or that the behavior
is undefined. [...]

There are certainly more than two possibilities. For
example, here's a third: "An un-terminated line will not
appear on the output stream at all."

I tried and failed to find C&V for something along the lines of
"An implementation is allowed to document its behavior in certain
cases that would otherwise be undefined." In any event, "not
appearing" is certainly a valid effect of undefined behavior,
regardless of whatever the implementation documentation says or
doesn't say.

-Arthur

[Wojtek Lerch]

Arthur J. O'Dwyer wrote:

I tried and failed to find C&V for something along the lines of
"An implementation is allowed to document its behavior in certain
cases that would otherwise be undefined."

An implementation is allowed to do anything it wants to, as long as it
doesn't violate any requirements of the standard. The standard doesn't
forbid documenting anything, does it?

[Eric Sosman]

Arthur J. O'Dwyer wrote:

On Wed, 26 May 2004, Eric Sosman wrote:

Arthur J. O'Dwyer wrote:

On Wed, 26 May 2004, Douglas A. Gwyn wrote:

As I understand the Standard's intent: An implementation must document
the behavior of a program whose output does not end in a newline, in
one of two ways: either that the output is printed, or that the behavior
is undefined. [...]

There are certainly more than two possibilities. For
example, here's a third: "An un-terminated line will not
appear on the output stream at all."

I tried and failed to find C&V for something along the lines of
"An implementation is allowed to document its behavior in certain
cases that would otherwise be undefined." In any event, "not
appearing" is certainly a valid effect of undefined behavior,
regardless of whatever the implementation documentation says or
doesn't say.

"Upon further review," as they say in Murkin football, I
think you may be right. 3.4.1 tells us that implementation-
defined behavior is a subset of unspecified behavior, and 3.4.4
says the latter involves a choice from among two or more
possibilities described in the Standard.

7.19.2/2 says it's implementation-defined whether the final
line does or does not require a terminating newline, and 3.4.1
says the implementation must document its choice. Nothing says
what happens if the implementation chooses "The newline is
required" and the program tries to violate the requirement, so
the behavior thereafter is undefined because the Standard
imposes no requirement (3.4.3).

... which leads to an interesting clash between Standardese
and ordinary English. If the implementation goes on to describe
what happens if the program omits the required newline ("A newline
is synthesized from thin blue air," say), this implementation-
provided definition does not "define" the behavior! We're still
in 3.4.3 territory because the implementation's definition doesn't
meet the requirements of 3.4.4 by making a choice among Standard-
specified behaviors. The behavior is defined by the implementation,
but is not implementation-defined.

Counter-intuitive, but eventually understandable. "After great
pain a formal feeling comes."

--
Er*********@sun.com

[Keith Thompson]

"Arthur J. O'Dwyer" <aj*@nospam.andrew.cmu.edu> writes:
[...]

I tried and failed to find C&V for something along the lines of
"An implementation is allowed to document its behavior in certain
cases that would otherwise be undefined."
I think that's sufficiently obvious that it doesn't need to be stated.
An implementation can document anything it wants to.

On the other hand, in cases where an implementation is required to
document its behavior, it has to follow its own documentation. If an
implementation chooses to document behavior that the standard leaves
undefined, and then doesn't behave as its own documentation specifies,
I'd say that's not a violation of the standard.

Some concrete examples:

Plain char can be either signed or unsigned. If an implementation
makes plain char signed, but its documentation says it's unsigned,
that's a violation of the standard.

Behavior on signed integer overflow is undefined. If an
implementation's documentation says that signed integer overflow wraps
around, but it actually causes a trap, that's not a violation of the
standard (but it's certainly a flaw -- one that could be corrected
simply by removing the statement from the documentation).
In any event, "not
appearing" is certainly a valid effect of undefined behavior,
regardless of whatever the implementation documentation says or
doesn't say.

Agreed.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Joe Wright]

Douglas A. Gwyn wrote:

Martin Dickopp wrote:

| A text stream is an ordered sequence of characters composed into
| lines, each line consisting of zero or more characters plus a
| terminating new-line character. Whether the last line requires a
| terminating new-line character is implementation-defined. [...]
Let's assume an implementation that makes the choice (and documents it)
that the last line requires a terminating new-line character. Is such
an implementation required to also define and document the behavior of a
program which writes to a text stream without terminating the last line
with a new-line character?

No, only whether the last line requires a terminating new-line
character needs to be documented.

Otherwise, can it be assumed that the behavior of such a program is
undefined on such an implementation, since lack of explicit definition
of behavior in the standard means undefined behavior (4#2)?

Yes, and more importantly, if the program behavior depends on
whether or not the last line of an input text stream has a
trailing new-line, it is not a strictly conforming program.
(This is a common bug.)

Well, even if the requirement for trailing new-line is documented by
the implementation, who exactly is the requirement binding upon? The
programmer or the implementation? For example:

FILE *t = fopen("text.txt", "w");
fprintf(t, "Hello world");
fclose(t);

I suppose I have written eleven characters to text.txt and nothing
else. And so it would not be a line because the required '\n' is not
there. And perhaps not even a stream for the same reason. Again, who
is this requirement incumbent upon?

I have a Windows98 system. I open this file with a text editor,
change the w to W and save it.

EDIT.COM doesn't complain about missing '\n' but adds it saving.
notepad.exe doesn't complain and doesn't add it.
vim.exe declares [Incomplete last line] and adds '\n' saving.
wordpad.exe doesn't complain and doesn't add it.
winword.exe doesn't complain about missing '\n' but adds it saving.

As a C programmer of applications and utilities, I write text files
in lines ending in '\n'. Even the last one. I do not place this
restriction on people sending files to me. I will see the last line
as a line whether it has a '\n' or not.

Sorry to be so wordy. I suppose that the requirement for a
terminating '\n' or not, documented or not is not actually imposed
on anyone. I suppose it is a caveat only so that I (programmer) can
take care to the case when it isn't there. I suppose also that there
is no case for the last line not ending in '\n' is a requirement.

--
Joe Wright mailto:jo********@comcast.net
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---

[Thad Smith]

Eric Sosman wrote:

... which leads to an interesting clash between Standardese
and ordinary English. If the implementation goes on to describe
what happens if the program omits the required newline ("A newline
is synthesized from thin blue air," say), this implementation-
provided definition does not "define" the behavior!
It does for that particular implementation, but not for the Standard.
We're still
in 3.4.3 territory because the implementation's definition doesn't
meet the requirements of 3.4.4 by making a choice among Standard-
specified behaviors. The behavior is defined by the implementation,
but is not implementation-defined.
It's a matter of perspective. With respect to the Standard, the
behavior might be defined, implementation-defined, unspecified, or
undefined. With respect to the a particular implementation, behavior
can be defined, unspecified (chosen for bounded possibilities), or
undefined. Any constructs which are unspecified or undefined
by the Standard can, of course, be defined for individual
implementations.
Counter-intuitive, but eventually understandable. "After great
pain a formal feeling comes."

Undefined by the Standard, but defined by the implementation seems a
straight-forward (and useful) concept to me.

Thad

[Thad Smith]

Joe Wright wrote:

Douglas A. Gwyn wrote:

Martin Dickopp wrote:

| A text stream is an ordered sequence of characters composed into
| lines, each line consisting of zero or more characters plus a
| terminating new-line character. Whether the last line requires a
| terminating new-line character is implementation-defined. [...]
Let's assume an implementation that makes the choice (and documents it)
that the last line requires a terminating new-line character. Is such
an implementation required to also define and document the behavior of a
program which writes to a text stream without terminating the last line
with a new-line character?

No, only whether the last line requires a terminating new-line
character needs to be documented.

Otherwise, can it be assumed that the behavior of such a program is
undefined on such an implementation, since lack of explicit definition
of behavior in the standard means undefined behavior (4#2)?

Yes, and more importantly, if the program behavior depends on
whether or not the last line of an input text stream has a
trailing new-line, it is not a strictly conforming program.
(This is a common bug.)

Well, even if the requirement for trailing new-line is documented by
the implementation, who exactly is the requirement binding upon? The
programmer or the implementation?

It is a requirement for the programmer. If it is violated, then the
program hasn't created a proper text stream.

If it were a requirement on the implementation, it would state that when
the stream is closed, if a new-line character were not the last
character one would be added (or maybe that the characters after the
last new-line would be deleted ;-). Sort of like the explicit
gratuitous return 0 for main.

Thad

[CBFalconer]

Joe Wright wrote:

.... snip ...
Well, even if the requirement for trailing new-line is documented
by the implementation, who exactly is the requirement binding
upon? The programmer or the implementation? For example:

FILE *t = fopen("text.txt", "w");
fprintf(t, "Hello world");
fclose(t);

I suppose I have written eleven characters to text.txt and
nothing else. And so it would not be a line because the required
'\n' is not there. And perhaps not even a stream for the same
reason. Again, who is this requirement incumbent upon?

Now precede the fclose(t); line with:

fflush(t);

and I believe the line needs to be written without the \n.

In actual practice I think the standards provision allows for the
fact that, without a final \n (or fflush), the final data may be
left in an internal buffer, and may simply get discarded.

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

[Douglas A. Gwyn]

Arthur J. O'Dwyer wrote:

FWIW, this is in direct contradiction to the opinion you stated two
messages upthread.

No, and actually I don't recall posting previously about
documenting the requirement for a new-line.

Perhaps you were referring to my pointing out that
"implementation defined" involves a choice among valid
alternatives stipulated in the standard, which does not
allow an implementor to choose "undefined behavior"
(unless that is explicitly one of the allowed choices).
There is no contradiction there.

[Douglas A. Gwyn]

Eric Sosman wrote:

Arthur J. O'Dwyer wrote:

On Wed, 26 May 2004, Douglas A. Gwyn wrote:

As I understand the Standard's intent: An implementation must document
the behavior of a program whose output does not end in a newline, in
one of two ways: either that the output is printed, or that the behavior
is undefined. [...]

...

I didn't say that, and in fact I disagree with it.
Please be more careful in your attributions.

[Douglas A. Gwyn]

Joe Wright wrote:

Well, even if the requirement for trailing new-line is documented by the
implementation, who exactly is the requirement binding upon? The
programmer or the implementation? For example:
FILE *t = fopen("text.txt", "w");
fprintf(t, "Hello world");
fclose(t);
I suppose I have written eleven characters to text.txt and nothing else.
And so it would not be a line because the required '\n' is not there.
And perhaps not even a stream for the same reason. Again, who is this
requirement incumbent upon?

It is a requirement imposed on the programmer.
For portability you must assume that a trailing
new-line is always necessary when writing a text
stream, and that the last line might not have a
trailing new-line when reading a text stream.

On some systems, your example would produce no
output (the "partial line" would be discarded).