Re: Void typecasting

Discussion in 'C Programming' started by Stefan Ram, May 27, 2014.

  1. Stefan Ram

    Stefan Ram Guest

    For an expression »e«, the statement »e;« will evaluate »e«.
    Just ignore it! What matters is:

    For an expression »e«, the statement »e;« will evaluate »e«.
    If p is 0, then !p is true.
    If p is a pointer to 0, then !*p is true.
     
    Stefan Ram, May 27, 2014
    #1
    1. Advertisements

  2. Stefan Ram

    BartC Guest

    Not always; with:

    double x,y;

    x+y;

    gcc generated no code that I could see. (The same when x,y were
    initialised.) This is with no optimisation.
     
    BartC, May 27, 2014
    #2
    1. Advertisements

  3. Stefan Ram

    James Kuyper Guest

    This may be true with the lowest level of optimization supported by gcc.
    It is, nonetheless, optimized by comparison with the abstract machine
    referred to in the standard. The abstract machine does evaluate x+y, and
    then discards the results. It's only the as-if rule which allows gcc to
    optimize the code by removing the evaluation step.
     
    James Kuyper, May 27, 2014
    #3
  4. Stefan Ram

    Kaz Kylheku Guest

    That behavior falls under what "evaluate" means when there is no side effect
    and the value is not used.

    When the value is not used, the expression needs to have side effects in order
    to make it necessary for evaluation to do something.
    How about:

    volatile unsigned *foo_register = (unsigned *) 0x1234;
    *foo_register;

    Still no code?
     
    Kaz Kylheku, May 27, 2014
    #4
  5. Stefan Ram

    BartC Guest

    That does produce something. As does:

    volatile double x,y; x+y;

    It doesn't actually add them however, just loads and discards x and y in
    turn.

    I tried this because you said it might be necessary to a pop a value which
    is on a stack. Well floating point results might be on an FPU stack, and
    such values *are* popped when doing this (on on my x86 machine):

    double fn(void) { return 0.0;}
    ...
    fn();

    But not with my example of x+y.

    (Using an old non-C compiler of mine however, then the equivalent of double
    x,y; x+y; does exactly what you might expect: evaluate x+y, and leave the
    result in ST0 (top of the FPU stack), perhaps ready for some inline ASM to
    do something with. BTW not popping the FPU stack - ie. making it overflow -
    appears to be harmless for x86.)
     
    BartC, May 28, 2014
    #5
  6. (snip)
    Hmm. Seems to me that it should actually add them.
    As either x or y could be SNaN, or x+y could overflow
    (even though C doesn't have any test for overflow).

    If you don't initialize them to any value, and then add,
    either SNaN or overflow are possible.
    Yes, or you will overflow the x87 stack.
    (Note that if you declare the function as void or int in the
    calling routine, and the compiler doesn't catch it, you can also
    overflow the x87 stack.)
    As well as I know it, there is an interrupt generated if you do
    overflow the stack, which could cause problems. Try calling such
    in a loop, and see what happens.

    As with memory leaks, it might be that nothing happens, but
    the stack is only 8 levels deep, so "something" can happen
    pretty soon.

    -- glen
     
    glen herrmannsfeldt, May 28, 2014
    #6
  7. Stefan Ram

    BartC Guest

    (I tried it 100 million times and nothing interesting happened (even when
    done at the start of an fpu-intensive application). Timing it however, shows
    that it is several times faster if the stack is popped at the end of each
    iteration.)
     
    BartC, May 28, 2014
    #7
    1. Advertisements

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.