preprozessor and #define Problem

Discussion in 'C Programming' started by Daniel Wild, Jun 25, 2004.

  1. Daniel Wild

    Daniel Wild Guest

    Hello,

    I have a problem with a macro which will return a pointer.
    In the header trolley_position_SL_GR is defined:
    #define trolley_position_SL_GR ((real_T*) ssGetPWorkValue(S,4))

    The function ssGetPWorkValue return a pointer on real_T. If I use something
    like:

    real_T *test;
    test = (real_T*) ssGetPWorkValue(S,4);
    //or
    test = *((real_T*) ssGetPWorkValue(S,4)+4); // for example

    everything works fine.
    If I use:
    teal_T *test;
    test = *(trolley_position_SL_GR+6);
    Now, I get a segmentation fault and if I set it in brackets like :
    test = *((trolley_position_SL_GR)+6);
    it works!

    Can someone explain this phenomenon?´I use Visual Studio 6 as c-compiler.

    Thank you,

    Daniel
    Daniel Wild, Jun 25, 2004
    #1
    1. Advertising

  2. Daniel Wild <> scribbled the following:
    > Hello,


    > I have a problem with a macro which will return a pointer.
    > In the header trolley_position_SL_GR is defined:
    > #define trolley_position_SL_GR ((real_T*) ssGetPWorkValue(S,4))


    > The function ssGetPWorkValue return a pointer on real_T. If I use something
    > like:


    > real_T *test;
    > test = (real_T*) ssGetPWorkValue(S,4);
    > //or
    > test = *((real_T*) ssGetPWorkValue(S,4)+4); // for example


    > everything works fine.
    > If I use:
    > teal_T *test;
    > test = *(trolley_position_SL_GR+6);
    > Now, I get a segmentation fault and if I set it in brackets like :
    > test = *((trolley_position_SL_GR)+6);
    > it works!


    > Can someone explain this phenomenon?´I use Visual Studio 6 as c-compiler.


    I can't explain it, but I noticed that you're assigning a value of type
    real_T into a variable of type real_T *. Depending on what type real_T
    is, this might cause undefined behaviour.

    --
    /-- Joona Palaste () ------------- Finland --------\
    \-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
    "The question of copying music from the Internet is like a two-barreled sword."
    - Finnish rap artist Ezkimo
    Joona I Palaste, Jun 25, 2004
    #2
    1. Advertising

  3. "Daniel Wild" <> wrote in message
    news:cbh3ln$4los7$-saarland.de...
    > Hello,
    >
    > I have a problem with a macro which will return a pointer.
    > In the header trolley_position_SL_GR is defined:
    > #define trolley_position_SL_GR ((real_T*) ssGetPWorkValue(S,4))
    >
    > The function ssGetPWorkValue return a pointer on real_T.


    Then why do you cast it's return value?

    > If I use something like:
    >
    > real_T *test;
    > test = (real_T*) ssGetPWorkValue(S,4);
    > //or
    > test = *((real_T*) ssGetPWorkValue(S,4)+4); // for example
    >
    > everything works fine.
    > If I use:
    > teal_T *test;
    > test = *(trolley_position_SL_GR+6);
    > Now, I get a segmentation fault and if I set it in brackets like :
    > test = *((trolley_position_SL_GR)+6);
    > it works!
    >
    > Can someone explain this phenomenon?´


    Please post the smallest _compilable_ snippet that exhibits the problem. Don't retype, use
    copy and paste. [Merely getting the code to postable form may well provide you with the
    answer.]

    > I use Visual Studio 6 as c-compiler.


    If that's relevant, then chances are you're posting to the wrong group.

    --
    Peter
    Peter Nilsson, Jun 26, 2004
    #3
  4. Daniel Wild

    Minti Guest

    "Daniel Wild" <> wrote in message news:<cbh3ln$4los7$-saarland.de>...
    > Hello,
    >
    > I have a problem with a macro which will return a pointer.
    > In the header trolley_position_SL_GR is defined:
    > #define trolley_position_SL_GR ((real_T*) ssGetPWorkValue(S,4))
    >
    > The function ssGetPWorkValue return a pointer on real_T. If I use something
    > like:
    >
    > real_T *test;
    > test = (real_T*) ssGetPWorkValue(S,4);
    > //or
    > test = *((real_T*) ssGetPWorkValue(S,4)+4); // for example

    ^
    Invalid Indirection, compiler ought to give a warning here. (*)

    >
    > everything works fine.
    > If I use:
    > teal_T *test;

    ^^^^
    real_T

    > test = *(trolley_position_SL_GR+6);


    test = * ( ((real_T*) ssGetPWorkValue(S,4)) + 6 )

    Read (*).

    > Now, I get a segmentation fault and if I set it in brackets like :
    > test = *((trolley_position_SL_GR)+6);


    test = * ( ( ((real_T*) ssGetPWorkValue(S,4)) + 6 );

    Read (*).

    The fact that your program does not quite @work fine@ means that you
    probably made a typo. Please @copy paste@ the code.

    --
    Imanpreet Singh Arora
    isingh AT acm DOT org
    Minti, Jun 26, 2004
    #4
  5. Daniel Wild

    Minti Guest

    "Peter Nilsson" <> wrote in message news:<40dcd6d8$>...
    > "Daniel Wild" <> wrote in message
    > news:cbh3ln$4los7$-saarland.de...
    > > Hello,
    > >
    > > I have a problem with a macro which will return a pointer.
    > > In the header trolley_position_SL_GR is defined:
    > > #define trolley_position_SL_GR ((real_T*) ssGetPWorkValue(S,4))
    > >
    > > The function ssGetPWorkValue return a pointer on real_T.

    >
    > Then why do you cast it's return value?
    >
    > > If I use something like:
    > >
    > > real_T *test;
    > > test = (real_T*) ssGetPWorkValue(S,4);
    > > //or
    > > test = *((real_T*) ssGetPWorkValue(S,4)+4); // for example
    > >
    > > everything works fine.
    > > If I use:
    > > teal_T *test;
    > > test = *(trolley_position_SL_GR+6);
    > > Now, I get a segmentation fault and if I set it in brackets like :
    > > test = *((trolley_position_SL_GR)+6);
    > > it works!
    > >
    > > Can someone explain this phenomenon?´

    >
    > Please post the smallest _compilable_ snippet that exhibits the problem. Don't retype, use
    > copy and paste. [Merely getting the code to postable form may well provide you with the
    > answer.]
    >
    > > I use Visual Studio 6 as c-compiler.

    >
    > If that's relevant, then chances are you're posting to the wrong group.


    Why can't this point be relevant in c.l.c? OP posted strictly
    conforming code, unless of course you consider using user defined
    types, directive or functions in c.l.c to be invalid. It is obviously
    quite certain/obvious that OP thought that this comment might help in
    better diagnosis of the problem.

    Comments like these are 100% irrelevent and just waste my precious
    little 28kbps bandwidth.

    I am not impressed.

    --
    Imanpreet Singh Arora
    isingh AT acm DOT org
    Minti, Jun 26, 2004
    #5
  6. "Minti" <> wrote in message
    news:...
    > "Peter Nilsson" <> wrote in message

    news:<40dcd6d8$>...
    > > ...
    > > Please post the smallest _compilable_ snippet that exhibits the problem.
    > > Don't retype, use copy and paste. [Merely getting the code to postable
    > > form may well provide you with the answer.]
    > >
    > > > I use Visual Studio 6 as c-compiler.

    > >
    > > If that's relevant, then chances are you're posting to the wrong group.

    >
    > Why can't this point be relevant in c.l.c? OP posted strictly
    > conforming code, unless of course you consider using user defined
    > types, directive or functions in c.l.c to be invalid. It is obviously
    > quite certain/obvious that OP thought that this comment might help in
    > better diagnosis of the problem.
    >
    > Comments like these are 100% irrelevent and just waste my precious
    > little 28kbps bandwidth.
    >
    > I am not impressed.


    I'm not impressed with your assertion that the OP posted strictly conforming code,
    particularly as in another post you point out typos and a required diagnostic.

    You seem to have posted in angst over false premises. I'm afraid that's a waste of
    everyone's bandwidth.

    --
    Peter
    Peter Nilsson, Jun 27, 2004
    #6
  7. Daniel Wild

    Minti Guest

    "Peter Nilsson" <> wrote in message news:<>...
    > "Minti" <> wrote in message
    > news:...
    > > "Peter Nilsson" <> wrote in message

    > news:<40dcd6d8$>...
    > > > ...
    > > > Please post the smallest _compilable_ snippet that exhibits the problem.
    > > > Don't retype, use copy and paste. [Merely getting the code to postable
    > > > form may well provide you with the answer.]
    > > >
    > > > > I use Visual Studio 6 as c-compiler.
    > > >
    > > > If that's relevant, then chances are you're posting to the wrong group.

    > >
    > > Why can't this point be relevant in c.l.c? OP posted strictly
    > > conforming code, unless of course you consider using user defined
    > > types, directive or functions in c.l.c to be invalid. It is obviously
    > > quite certain/obvious that OP thought that this comment might help in
    > > better diagnosis of the problem.
    > >
    > > Comments like these are 100% irrelevent and just waste my precious
    > > little 28kbps bandwidth.
    > >
    > > I am not impressed.

    >
    > I'm not impressed with your assertion that the OP posted strictly conforming code,
    > particularly as in another post you point out typos and a required diagnostic.
    >
    > You seem to have posted in angst over false premises. I'm afraid that's a waste of
    > everyone's bandwidth.



    Well it depends on what the meaning of "strictly conforming" is?. When
    I said strictly conforming I _obviously_ meant that that the code did
    not contain any feature that we might consider to be non standard. Non
    standard as in having void main() etc. Yes bad terminology but why do
    you think I should accept my mistake when you don't yours.

    --
    Imanpreet Singh Arora
    isingh AT acm DOT org
    Minti, Jun 27, 2004
    #7
  8. "Minti" <> wrote...
    > "Peter Nilsson" <> wrote...
    > > "Minti" <> wrote...
    > > > "Peter Nilsson" <> wrote...
    > > > > ...
    > > > > Please post the smallest _compilable_ snippet that exhibits the
    > > > > problem. Don't retype, use copy and paste. [Merely getting the
    > > > > code to postable form may well provide you with the answer.]
    > > > >
    > > > > > I use Visual Studio 6 as c-compiler.
    > > > >
    > > > > If that's relevant, then chances are you're posting to the wrong
    > > > > group.
    > > >
    > > > Why can't this point be relevant in c.l.c? OP posted strictly
    > > > conforming code, unless of course you consider using user defined
    > > > types, directive or functions in c.l.c to be invalid. It is
    > > > obviously quite certain/obvious that OP thought that this comment
    > > > might help in better diagnosis of the problem.
    > > >
    > > > Comments like these are 100% irrelevent and just waste my precious
    > > > little 28kbps bandwidth.
    > > >
    > > > I am not impressed.

    > >
    > > I'm not impressed with your assertion that the OP posted strictly
    > > conforming code, particularly as in another post you point out typos
    > > and a required diagnostic.
    > >
    > > You seem to have posted in angst over false premises. I'm afraid
    > > that's a waste of everyone's bandwidth.

    >
    > Well it depends on what the meaning of "strictly conforming" is?


    Try the one in the standards.

    > When I said strictly conforming I _obviously_ meant that that the code'
    > did not contain any feature that we might consider to be non standard.
    > Non standard as in having void main() etc.


    Does your version of 'strictly conforming' include assignments involving incompatible
    pointer types?

    > Yes bad terminology but why do you think I should accept my mistake when
    > you don't yours.


    What mistake have I made?

    You talked about considering 'user defined types, directive or functions in c.l.c to be
    invalid'. Nowhere in my post did I say that was the case.

    As far as I'm concerned, OP's can use as many functions and types as they like, so long as
    they can be put in terms of ISO C and so long as the posted code is compilable or
    trivially made compilable. Having to guess function prototypes and user types is not
    something I consider acceptable. The less an OP defines, the less likely an ISO C answer
    is going to be redily forthcoming.

    Consider...

    int foo(void *); /* this is ok */
    typedef struct some_struct *real_T;

    __cdecl __int64 foo(void *) /* this isn't */
    typedef void * far real_T;

    In the case of the former, where is the implementation relevant?

    For the latter, do you really want clc to answer questions based on that?

    --
    Peter
    Peter Nilsson, Jun 28, 2004
    #8
  9. Daniel Wild

    Dan Pop Guest

    In <40dcd6d8$> "Peter Nilsson" <> writes:

    >"Daniel Wild" <> wrote in message
    >news:cbh3ln$4los7$-saarland.de...
    >
    >> I use Visual Studio 6 as c-compiler.

    >
    >If that's relevant, then chances are you're posting to the wrong group.


    How can the OP know whether it's relevant or not? Since he doesn't, it's
    safer to mention it.

    Dan
    --
    Dan Pop
    DESY Zeuthen, RZ group
    Email:
    Dan Pop, Jun 28, 2004
    #9
    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. prettysmurfed
    Replies:
    3
    Views:
    10,302
    MPBroida
    Oct 24, 2003
  2. theotyflos
    Replies:
    3
    Views:
    466
    Thomas Matthews
    Feb 19, 2004
  3. robin liu
    Replies:
    3
    Views:
    821
    Robin Liu
    Apr 21, 2006
  4. _mario.lat

    help: define problem and meaning of {{{ and }}}.

    _mario.lat, May 27, 2007, in forum: C Programming
    Replies:
    4
    Views:
    347
    Keith Thompson
    May 27, 2007
  5. Brian Takita

    #define _ and #define __

    Brian Takita, Jan 23, 2006, in forum: Ruby
    Replies:
    0
    Views:
    460
    Brian Takita
    Jan 23, 2006
Loading...

Share This Page