Re: Why is this not a modifiable lvalue.

Discussion in 'C Programming' started by Dan Pop, Jun 27, 2003.

  1. Dan Pop

    Dan Pop Guest

    In <ZqVKa.1432$> "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:
     
    Dan Pop, Jun 27, 2003
    #1
    1. Advertising

  2. Dan Pop

    Dan Pop Guest

    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, Jun 27, 2003
    #2
    1. Advertising

  3. "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
     
    Carsten Hansen, Jun 27, 2003
    #3
  4. 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 =---
     
    Mark McIntyre, Jun 29, 2003
    #4
  5. 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.8), 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
     
    Bruce Wheeler, Jun 30, 2003
    #5
  6. Dan Pop

    Dan Pop Guest

    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:
     
    Dan Pop, Jun 30, 2003
    #6
  7. Dan Pop

    Dan Pop Guest

    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:
     
    Dan Pop, Jun 30, 2003
    #7
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Simon Biber

    Re: Why is this not a modifiable lvalue.

    Simon Biber, Jun 27, 2003, in forum: C Programming
    Replies:
    0
    Views:
    2,361
    Simon Biber
    Jun 27, 2003
  2. Martin Ambuhl

    Re: Why is this not a modifiable lvalue.

    Martin Ambuhl, Jun 27, 2003, in forum: C Programming
    Replies:
    0
    Views:
    705
    Martin Ambuhl
    Jun 27, 2003
  3. Micah Cowan

    Re: Why is this not a modifiable lvalue.

    Micah Cowan, Jun 28, 2003, in forum: C Programming
    Replies:
    1
    Views:
    761
    CBFalconer
    Jun 28, 2003
  4. Mr. SweatyFinger
    Replies:
    2
    Views:
    1,964
    Smokey Grindel
    Dec 2, 2006
  5. Kavya

    lvalue -modifiable and non-modifiable

    Kavya, Nov 6, 2006, in forum: C Programming
    Replies:
    3
    Views:
    438
    Keith Thompson
    Nov 6, 2006
Loading...

Share This Page