preprozessor and #define Problem

[Daniel Wild]

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

 

[Joona I Palaste]

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.

 

[Peter Nilsson]

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.

 

[Minti]

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.

 

[Minti]

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.

 

[Peter Nilsson]

"Peter Nilsson" <[email protected]> wrote in message

...
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.

 

[Minti]

"Peter Nilsson" <[email protected]> wrote in message

...
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.

 

[Peter Nilsson]

...
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?

 

[Dan Pop]

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