«

Dan Pop () 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

In <blei40$7u2$> (Martin Stromberg) writes:

>Dan Pop () 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
--
Dan Pop
DESY Zeuthen, RZ group
Email:

On Wed, 1 Oct 2003, Martin Stromberg wrote:

> Dan Pop () 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.

--

On 2003-10-01 14:36, Johan Aurér <> wrote:
> On Wed, 1 Oct 2003, Martin Stromberg wrote:
[...]
>> 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.

....or a trap representation?

-- Niklas Matthies

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

In comp.std.c Al Grant <> wrote:
>
> It was entirely clear that it did.

In comp.std.c Dan Pop <> wrote:
>
> 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

In comp.std.c Kevin Easton <kevin@-nospam-pcug.org.au> wrote:
>
> 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

Dan Pop () wrote:
: In <blei40$7u2$> (Martin Stromberg) writes:
: >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

wrote in message news:<aqnr41->...
> I wrote:
> >
> > In C89, it wasn't entirely clear whether
> > "implementation-defined behavior" allowed that or not
>
> In comp.std.c Al Grant <> wrote:
> >
> > It was entirely clear that it did.
>
> In comp.std.c Dan Pop <> wrote:
> >
> > 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.

In <> Niklas Matthies <> writes:

>On 2003-10-01 14:36, Johan Aurér <> wrote:
>> On Wed, 1 Oct 2003, Martin Stromberg wrote:
>[...]
>>> 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.
>
>...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
--
Dan Pop
DESY Zeuthen, RZ group
Email:

In comp.lang.c wrote:
> In comp.std.c Kevin Easton <kevin@-nospam-pcug.org.au> wrote:
>>
>> 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.

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

- Kevin.