Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Re: Why is this not a modifiable lvalue.

Reply
Thread Tools

Re: Why is this not a modifiable lvalue.

 
 
Dan Pop
Guest
Posts: n/a
 
      06-27-2003
In <ZqVKa.1432$(E-Mail Removed) t> "Russell Hanneken" <(E-Mail Removed)> writes:


>"David Crayford" <(E-Mail Removed)> wrote in message
>news:aTUKa.2045$(E-Mail Removed). ..
>> 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: http://www.velocityreviews.com/forums/(E-Mail Removed)
 
Reply With Quote
 
 
 
 
Dan Pop
Guest
Posts: n/a
 
      06-27-2003
In <dzZKa.24135$(E-Mail Removed)> "Carsten Hansen" <(E-Mail Removed)> writes:

>"Dan Pop" <(E-Mail Removed)> wrote in message
>news:bdhir9$ipp$(E-Mail Removed)...
>>
>> 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: (E-Mail Removed)
 
Reply With Quote
 
 
 
 
Carsten Hansen
Guest
Posts: n/a
 
      06-27-2003

"Dan Pop" <(E-Mail Removed)> wrote in message
news:bdhr0i$bri$(E-Mail Removed)...
> In <dzZKa.24135$(E-Mail Removed)> "Carsten

Hansen" <(E-Mail Removed)> writes:
>
> >"Dan Pop" <(E-Mail Removed)> wrote in message
> >news:bdhir9$ipp$(E-Mail Removed)...
> >>
> >> 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: (E-Mail Removed)



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

Carsten Hansen


 
Reply With Quote
 
Mark McIntyre
Guest
Posts: n/a
 
      06-29-2003
On Fri, 27 Jun 2003 17:44:05 GMT, in comp.lang.c , "Carsten Hansen"
<(E-Mail Removed)> wrote:

>
>"Dan Pop" <(E-Mail Removed)> 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 =---
 
Reply With Quote
 
Bruce Wheeler
Guest
Posts: n/a
 
      06-30-2003
On Sun, 29 Jun 2003 01:47:42 +0100, Mark McIntyre
<(E-Mail Removed)> wrote:

>On Fri, 27 Jun 2003 17:44:05 GMT, in comp.lang.c , "Carsten Hansen"
><(E-Mail Removed)> wrote:
>
>>
>>"Dan Pop" <(E-Mail Removed)> 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

 
Reply With Quote
 
Dan Pop
Guest
Posts: n/a
 
      06-30-2003
In <Fn%Ka.24805$(E-Mail Removed)> "Carsten Hansen" <(E-Mail Removed)> writes:


>"Dan Pop" <(E-Mail Removed)> wrote in message
>news:bdhr0i$bri$(E-Mail Removed)...
>> In <dzZKa.24135$(E-Mail Removed)> "Carsten

>Hansen" <(E-Mail Removed)> writes:
>>
>> >"Dan Pop" <(E-Mail Removed)> wrote in message
>> >news:bdhir9$ipp$(E-Mail Removed)...
>> >>
>> >> 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: (E-Mail Removed)
 
Reply With Quote
 
Dan Pop
Guest
Posts: n/a
 
      06-30-2003
In <(E-Mail Removed)> Mark McIntyre <(E-Mail Removed)> writes:

>On Fri, 27 Jun 2003 17:44:05 GMT, in comp.lang.c , "Carsten Hansen"
><(E-Mail Removed)> wrote:
>
>>
>>"Dan Pop" <(E-Mail Removed)> 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: (E-Mail Removed)
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
findcontrol("PlaceHolderPrice") why why why why why why why why why why why Mr. SweatyFinger ASP .Net 2 12-02-2006 03:46 PM
lvalue -modifiable and non-modifiable Kavya C Programming 3 11-06-2006 10:33 PM
Re: Why is this not a modifiable lvalue. Micah Cowan C Programming 1 06-28-2003 06:05 PM
Re: Why is this not a modifiable lvalue. Martin Ambuhl C Programming 0 06-27-2003 06:17 PM
Re: Why is this not a modifiable lvalue. Simon Biber C Programming 0 06-27-2003 11:12 AM



Advertisments