Understanding a simple C program

[Keith Thompson]

Is an implementation allowed to say that the behavior of leaving off
the terminating newline is dependent on things outside the scope of
the C compiler?

For example, suppose you are sending the output to a printer, which
won't print the last line if it's not newline-terminated, even though
the C implementation guarantees that it will send everything up to
the final non-newline character? However, if going to the screen,
the output will be just fine.

One solution in that case would be to say that the trailing new-line
is required (leaving the behavior undefined if it's missing), and then
go ahead and describe what happens in some cases.

Though if the documentation made a more realistic statement that the
trailing new-line is not required if you're writing to a file, but
leaving it off might have unpredictable consequences if you're writing
to a device, I for one wouldn't complain.

 

[Richard Bos]

That turns out to be a poor example. If a value outside the range of
a signed type is converted to that type, the behavior is not
undefined; either the result is an implementation-defined value, or an
implementation-defined signal is raised.

Then Appendix J of the Standard needs fixing, since:

# — Conversion to or from an integer type produces a value outside the
# range that can be represented (6.3.1.4).

Admittedly, once I'd picked this example, I did not then check to see
whether 6.3.1.4 says what I thought it says. What it does say is that
when 40000.0 (note decimal) is converted to int and INT_MAX is 32767,
the behaviour is undefined. For 40000 /sans/ decimal, the paragraph
above says what you says it does. I find _this_ inconsistency even worse
than the one between integer-to-int conversion and int overflow.

Richard

 

[Keith Thompson]

Then Appendix J of the Standard needs fixing, since:

# -- Conversion to or from an integer type produces a value outside the
# range that can be represented (6.3.1.4).

Admittedly, once I'd picked this example, I did not then check to see
whether 6.3.1.4 says what I thought it says. What it does say is that
when 40000.0 (note decimal) is converted to int and INT_MAX is 32767,
the behaviour is undefined. For 40000 /sans/ decimal, the paragraph
above says what you says it does. I find _this_ inconsistency even worse
than the one between integer-to-int conversion and int overflow.

Ick. I'll post to comp.std.c.

 

[Nick Keighley]

You should never have to worry about the compiler in either defined or
undefined situations

what?

the compiler is (usually) the expression of the implementation.
If a program exhibits undefined behaviour then the implementation
is unconstrained in what it may do. The compiler can do anything.
So why don't I have to worry about the compiler?

 

[Chris Dollin]

the compiler is (usually) the expression of the implementation.
If a program exhibits undefined behaviour then the implementation
is unconstrained in what it may do. The compiler can do anything.
So why don't I have to worry about the compiler?

Because you use only the undefined behaviour that your implementations
define?

[A compiler isn't free to do "anything". It's only free to do "anything"
/as far as the C standard is concerned/. Actual compilers usually
operate under additional restraints, for example, they don't generate
code that causes your computer to travel faster than light or
rewrite your DNA, and some external identifiers may be defined as
having potentially useful effects such as changing the colour of
a screen pixel.]