Line input and implementation-defined behaviour

[Martin Stromberg]

Dan Pop ([email protected]) wrote:
: The C89 text is perfectly clear:

: ... if the value cannot be represented the result is
: implementation-defined.

: So, it is only *the result* that is implementation-defined, not any other
: aspect of the program's behaviour.

So "the result" can't be the programs behaviour but must be the return
value?

Vague.


Right,

MartinS

 

[Dan Pop]

Dan Pop ([email protected]) wrote:
: The C89 text is perfectly clear:

: ... if the value cannot be represented the result is
: implementation-defined.

: So, it is only *the result* that is implementation-defined, not any other
: aspect of the program's behaviour.

So "the result" can't be the programs behaviour but must be the return
value?

Vague.

Not vague at all, if read in context. There is no "return value" at all
involved, BTW.

Dan

 

[=?ISO-8859-1?Q?Johan_Aur=E9r?=]

Dan Pop ([email protected]) wrote:
: The C89 text is perfectly clear:

: ... if the value cannot be represented the result is
: implementation-defined.

: So, it is only *the result* that is implementation-defined, not any other
: aspect of the program's behaviour.

So "the result" can't be the programs behaviour but must be the return
value?

It must be a value, yes.

Vague.

Perhaps, but trying to make sense of isolated sentences from the standard
will seldom get you anywhere. 6.2p.1 says

"Several operators convert operand values from one type to another
^^^^^^^ ^^^^^^
automatically. This subclause specifies the result from such an
^^^^^^
implicit conversion, ..."
^^^^^^^^^^

Since a conversion is defined as an operation that yields a *value*, the
*result* of a conversion must be a value.

 

[Niklas Matthies]

It must be a value, yes.


Perhaps, but trying to make sense of isolated sentences from the standard
will seldom get you anywhere. 6.2p.1 says

"Several operators convert operand values from one type to another
^^^^^^^ ^^^^^^
automatically. This subclause specifies the result from such an
^^^^^^
implicit conversion, ..."
^^^^^^^^^^

Since a conversion is defined as an operation that yields a *value*, the
*result* of a conversion must be a value.

....or a trap representation?

-- Niklas Matthies

 

[lawrence.jones]

In C89, it wasn't entirely clear whether
"implementation-defined behavior" allowed that or not

It was entirely clear that it did.

The C89 text is perfectly clear: [...]
So, it is only *the result* that is implementation-defined, not any other
aspect of the program's behaviour.

Thank you for proving my point, gentlemen.

-Larry Jones

Yep, we'd probably be dead by now if it wasn't for Twinkies. -- Calvin

 

[lawrence.jones]

It's a pity it wasn't disabled by default, with the program
having to do something explicit to enable signal on overflow.

That's up to the implementation. I know of implementations that allow
integer overflow to be detected, but I don't know of any that do so by
default.

-Larry Jones

In my opinion, we don't devote nearly enough scientific research
to finding a cure for jerks. -- Calvin

 

[Martin Stromberg]

Dan Pop ([email protected]) wrote:
: >So "the result" can't be the programs behaviour but must be the return
: >value?
: >
: >Vague.

: Not vague at all, if read in context. There is no "return value" at all
: involved, BTW.

Errhm... For some reason I thought we were talking about strtol() or
similar. Now looking at the whole thread again, I see we wasn't.

Sorry.


Right,

MartinS

 

[Al Grant]

In C89, it wasn't entirely clear whether
"implementation-defined behavior" allowed that or not

It was entirely clear that it did.

The C89 text is perfectly clear: [...]
So, it is only *the result* that is implementation-defined, not any other
aspect of the program's behaviour.

Thank you for proving my point, gentlemen.

You have ignored the rest of my post:

It was also entirely clear that 3.2.1.2 did not use the phrase
"implementation-defined behavior". What it said was "if the
value cannot be represented the result is implementation-defined".

As far as I can tell Dan Pop and I have both read the standard
in the same way. You appear not to have read it at all in that
you are asking about the interpretation of a phrase that doesn't
even occur in the part of the standard under discussion.

 

[Dan Pop]

...or a trap representation?

No such thing in C89, the standard we're talking about.

And I doubt that even in C99, a trap representation is a valid option when
the standard specifies an implementation-defined value.

Dan

 

[Kevin Easton]

That's up to the implementation. I know of implementations that allow
integer overflow to be detected, but I don't know of any that do so by
default.

So there wouldn't have been any impediment to making that the mandated
behaviour then...

- Kevin.