«

In <ZqVKa.1432$ t> "Russell Hanneken" <> writes:


>"David Crayford" <> wrote in message
>news:aTUKa.2045$. ..
>> I ported some code which compiles ok on my PC using GCC

Try using gcc as a C compiler and it will no longer compile OK.

>> but fails using
>> the mainframe OS/390 and z/OS compilers.
>>
>> static void exchange(void *a, void *b, size_t size) {
>>
>> <snip>
>>
>> *(((int *)a)++) = *((int *)b);
>>
>> produces the following compiler error
>>
>> Operand must be a modifiable lvalue
>>
>> The cast should take care of that, shouldn't it?
>
>According to the C standard:
>
>1. "A cast does not yield an lvalue" (section 6.5.4, footnote 85).
>2. "The operand of the postfix increment or decrement operator . . . shall
>be a modifiable lvalue" (section 6.5.2.4, paragraph 1).
>
>Oddly, none of my Windows compilers seem to have any objection to using the
>result of a cast operation as the operand for a postfix increment operation.
>
>Interesting.

Try using them as C compilers and they should produce one diagnostic.

Most compilers are NOT conforming C compilers *by default*. You have to
check their documentation to figure out how to invoke them as conforming
C compilers (e.g. gcc needs -ansi -pedantic -ffloat-store).

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email:

In <dzZKa.24135$> "Carsten Hansen" <> writes:

>"Dan Pop" <> wrote in message
>news:bdhir9$ipp$...
>>
>> Most compilers are NOT conforming C compilers *by default*. You have to
>> check their documentation to figure out how to invoke them as conforming
>> C compilers (e.g. gcc needs -ansi -pedantic -ffloat-store).
>
>Why is -ffloat-store required? A compliant C implementation is not required
>to adhere to the IEEE floating-point standard is it?

-ffloat-store has precious little to do with IEEE floating-point:

-ffloat-store
Do not store floating point variables in registers.
This prevents undesirable excess precision on ma*
chines such as the 68000 where the floating regis*
ters (of the 68881) keep more precision than a dou*
ble is supposed to have.

This can happen to both IEEE and non-IEEE floating point implementations.

As the man page goes on to say, this is a non-issue for most programs,
but there are rare cases when the exact semantics of f.p. arithmetic,
as defined by the standard, are desired.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email:

"Dan Pop" <> wrote in message
news:bdhr0i$bri$...
> In <dzZKa.24135$> "Carsten
Hansen" <> writes:
>
> >"Dan Pop" <> wrote in message
> >news:bdhir9$ipp$...
> >>
> >> Most compilers are NOT conforming C compilers *by default*. You have
to
> >> check their documentation to figure out how to invoke them as
conforming
> >> C compilers (e.g. gcc needs -ansi -pedantic -ffloat-store).
> >
> >Why is -ffloat-store required? A compliant C implementation is not
required
> >to adhere to the IEEE floating-point standard is it?
>
> -ffloat-store has precious little to do with IEEE floating-point:
>
> -ffloat-store
> Do not store floating point variables in registers.
> This prevents undesirable excess precision on ma*
> chines such as the 68000 where the floating regis*
> ters (of the 68881) keep more precision than a dou*
> ble is supposed to have.
>
> This can happen to both IEEE and non-IEEE floating point implementations.
>
> As the man page goes on to say, this is a non-issue for most programs,
> but there are rare cases when the exact semantics of f.p. arithmetic,
> as defined by the standard, are desired.
>
> Dan
> --
> Dan Pop
> DESY Zeuthen, RZ group
> Email:


If you don't specify it, what part of the C standard is it violating. Do you
have an example?

Carsten Hansen

On Fri, 27 Jun 2003 17:44:05 GMT, in comp.lang.c , "Carsten Hansen"
<> wrote:

>
>"Dan Pop" <> wrote in message
>> As the man page goes on to say, this is a non-issue for most programs,
>> but there are rare cases when the exact semantics of f.p. arithmetic,
>> as defined by the standard, are desired.
>>
>
>If you don't specify it, what part of the C standard is it violating. Do you
>have an example?

Yes, I'd be interested too. AFAIR the standard defines minimum
precisions for types, not maximum.

(And please, lets have a refefence, not ad hominem attacks. )

--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>


----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---

On Sun, 29 Jun 2003 01:47:42 +0100, Mark McIntyre
<> wrote:

>On Fri, 27 Jun 2003 17:44:05 GMT, in comp.lang.c , "Carsten Hansen"
><> wrote:
>
>>
>>"Dan Pop" <> wrote in message
>>> As the man page goes on to say, this is a non-issue for most programs,
>>> but there are rare cases when the exact semantics of f.p. arithmetic,
>>> as defined by the standard, are desired.
>>>
>>
>>If you don't specify it, what part of the C standard is it violating. Do you
>>have an example?
>
>Yes, I'd be interested too. AFAIR the standard defines minimum
>precisions for types, not maximum.
>
>(And please, lets have a refefence, not ad hominem attacks. )
>
>--
>Mark McIntyre

Some relevant sections in the standard are here (from N869).

5.1.2.3 Program execution
....
[#13] EXAMPLE 4 Implementations employing wide registers have
to take care to honor appropriate semantics. Values are
independent of whether they are represented in a register
or in memory. For example, an implicit spilling of a register
is not permitted to alter the value. Also, an explicit store
and load is required to round to the precision of the
storage type. In particular, casts and assignments are
required to perform their specified conversion. For the
fragment
double d1, d2;
float f;
d1 = f = expression;
d2 = (float) expressions;

the values assigned to d1 and d2 are required to have been
converted to float.

6.3.1.5 Real floating types

[#2] When a double is demoted to float or a long double to
double or float, if the value being converted is outside the
range of values that can be represented, the behavior is
undefined. If the value being converted is in the range of
values that can be represented but cannot be represented
exactly, the result is either the nearest higher or nearest
lower value, chosen in an implementation-defined manner.

and footnote 77 in N869 (which is footnote 86 in the Standard).

77)If the value of the expression is represented with
greater precision or range than required by the type
named by the cast (6.3.1., then the cast specifies a
conversion even if the type of the expression is the same
as the named type.

There were a few threads in comp.std.c on this topic last year.
Clive Feather pointed out the above in the thread 'Floating-point
semantics in C' on 4/16/2002.

Regards,
Bruce Wheeler

In <Fn%Ka.24805$> "Carsten Hansen" <> writes:


>"Dan Pop" <> wrote in message
>news:bdhr0i$bri$...
>> In <dzZKa.24135$> "Carsten
>Hansen" <> writes:
>>
>> >"Dan Pop" <> wrote in message
>> >news:bdhir9$ipp$...
>> >>
>> >> Most compilers are NOT conforming C compilers *by default*. You have
>to
>> >> check their documentation to figure out how to invoke them as
>conforming
>> >> C compilers (e.g. gcc needs -ansi -pedantic -ffloat-store).
>> >
>> >Why is -ffloat-store required? A compliant C implementation is not
>required
>> >to adhere to the IEEE floating-point standard is it?
>>
>> -ffloat-store has precious little to do with IEEE floating-point:
>>
>> -ffloat-store
>> Do not store floating point variables in registers.
>> This prevents undesirable excess precision on ma*
>> chines such as the 68000 where the floating regis*
>> ters (of the 68881) keep more precision than a dou*
>> ble is supposed to have.
>>
>> This can happen to both IEEE and non-IEEE floating point implementations.
>>
>> As the man page goes on to say, this is a non-issue for most programs,
>> but there are rare cases when the exact semantics of f.p. arithmetic,
>> as defined by the standard, are desired.
>
>If you don't specify it, what part of the C standard is it violating. Do you
>have an example?

I'm too lazy to search the relevant normative parts, so I'll only
post a relevant example from the standard:

12 EXAMPLE 4 Implementations employing wide registers have to take
care to honor appropriate semantics. Values are independent
of whether they are represented in a register or in memory. For
example, an implicit spilling of a register is not permitted to
alter the value. Also, an explicit store and load is required
to round to the precision of the storage type. In particular,
casts and assignments are required to perform their specified
conversion. For the fragment

double d1, d2;
float f;
d1 = f = expression;
d2 = (float) expressions;

the values assigned to d1 and d2 are required to have been
converted to float.

Without -ffloat-store, gcc on x86 will often perform optimisations not
allowed by the text quoted above (e.g. using a temporary float may not
result in reduced precision and casts to lower precision may often be
ignored).

Dik Winter could tell you a lot more on this topic, as he spent some time
actually investigating the issue.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email:

In <> Mark McIntyre <> writes:

>On Fri, 27 Jun 2003 17:44:05 GMT, in comp.lang.c , "Carsten Hansen"
><> wrote:
>
>>
>>"Dan Pop" <> wrote in message
>>> As the man page goes on to say, this is a non-issue for most programs,
>>> but there are rare cases when the exact semantics of f.p. arithmetic,
>>> as defined by the standard, are desired.
>>>
>>
>>If you don't specify it, what part of the C standard is it violating. Do you
>>have an example?
>
>Yes, I'd be interested too. AFAIR the standard defines minimum
>precisions for types, not maximum.

How are you supposed to read my reply?

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: