• State Not Answered
  • Locked Locked
  • Replies 10 replies
  • Subscribers 20 subscribers
  • Views 2815 views
  • Users 0 members are here
Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

sizeof in #if Compiler statement not working

Lars Peterson

Hallo,

I use RealView compiler for c
I like to assert a statement by procompiler

Writing:

int i;
const int Ass_FR = sizeof(i);

#if Ass_FR != 5
  #error "Error!!!"
#endif


is working.

but:

int i;

#if sizeof(i) != 5
  #error "Error!!!"
#endif


not.

He says:
error: #59: function call is not allowed in a constant expression

Is this a bug?

  • 0

    Sorry..
    #if Ass_FR != 0
    is only compiling. But not working.
    How can I assert at compiler time and throw a compiler error?

  • 0 in reply to Lars Peterson

    HI.

    u can not use sizeof in a #if for that

    remembar sizeof is recognized by teh compiler and the #if by teh pre processor.

    Always yo're freind.

    Zeusti.

  • 0 in reply to Advanced Zeusti

    Ok. Next idea.

    i= 5/(sizeof(i) != 4);
    Will throw a division by zeroes WARNING.
    So, what i need (;

    Can I make a local Pre Processer directive, to throw a ERROR ?
    Warnings are easy to oversee by lots of them

  • 0 in reply to Lars Peterson

    Found it (;

    #pragma diag_error 39
        i=(5/(sizeof(int) != 2));

    Looks very strange, but waste no code and get compilererror.

    Thanks for your help.

  • 0 in reply to Lars Peterson

    Looks very strange, but waste no code and get compilererror.

    I'm still not sure what you're actually trying to accomplish.

    And I'm also not sure that your code does what I assume you're trying to do.

  • 0 in reply to Christoph Franck

    My english is not very good, but i try to explain.

    I like to test, if a array or UDT is the expectet size.
    Sometimes you add a field and forgot, that you must adjust other code too.
    Normal, you make a assert statement.
    But you get only a assert warning, if you run the program and this function. And you must run with DEBUG flag.
    But you run only with debug flag, if you got a error.
    To late...

    A normal if statement will waste code space and runtime.

    This code will be removed (optimized) by compiler and give error at compile. No code and time waste.

  • 0 in reply to Lars Peterson

    HI.

    i understand why u want to do it.

    i think i understand what yo're code does.

    but is it guarenteed to work? and onley when compiled?

    if teh optimiser does not remov yo're code then u will have a very very bad run time error.

    Always yo're freind.

    Zeusti.

    /5; // lower flaps 5 degrees
    } // end function mantain flight path

    void enable_auto_pilot ( int

  • 0 in reply to Advanced Zeusti

    Runtimeerror is fatched by code and nice Display Message to user. Only, if the code is used with other compiler it couldn't work.
    Compiler is not very genius:
    if (sizeof(int) != 2) Fehler("xxx");
    will not be removed by optimization.
    The Statement in if is constant.So he must know, that this is never true.

    PS: Found bad bug in compiler
    while(changedbyInt){};
    will only test changedbyInt once in ASM. But changedbyInt is changed by Interrupt.

  • 0 in reply to Lars Peterson

    HI.

    <quote>
    PS: Found bad bug in compiler
    while(changedbyInt){};
    will only test changedbyInt once in ASM. But changedbyInt is changed by Interrupt.
    </quote>

    is yo're variable changedbyInt declared as volatile?

    it should have.

    Always yo're freind.

    Zeusti.

  • 0 in reply to Lars Peterson

    PS: Found bad bug in compiler
    while(changedbyInt){};
    will only test changedbyInt once in ASM. But changedbyInt is changed by Interrupt.    <p>

    No, you didn't find a bug. This is correct and expected behavior - by default, the compiler does not need to consider the possibility of the value of variables being changed outside the regular program flow (e.g. by interrupts, other processes, hardware, etc).

    Using the keyword volatile when declaring the variable will instruct the compiler to assume that the value of the variable may change at any time.