I've lied to the compiler and now it won't trust me

[Adam Warner]

Hi all,

When adding variable length arrays to my program I created the elements as
type struct o *. This is because /most/ of the time the VLAs contains
pointers to struct o objects (these objects are as stringently aligned as
any C type in the implementation). Occasionally a single element is
actually a pointer to another VLA of pointers to struct o objects (and
occasionally I'm storing an integer index (of type ptrdiff_t) as an
immediate object).

Casting a pointer to an integer is no problem. But GCC will not compile my
program when I tell it that an element of an array is actually a pointer
to the same type of array:

void heap_trace_stack(struct o **ret0) {
//Follow local variables
if (ret0[-2]!=NULL) {
struct o **var=(struct o **) *ret0[-2]; //Line 207
index num_var=(index) var[0];
...
}
...
}

The code above has been passed a VLA offset to the first element of a
particular category (&ret0[0]). If the element at the legal index position
-2 is not NULL then it's actually a pointer to another VLA of the same
type. The line 207 cast is rejected by GCC as an error (gcc-3.4 -std=c99
-O2 -Wall):

heap.c: In function `heap_trace_stack':
heap.c:207: error: cannot convert to a pointer type

If I have to change the VLAs to elements of type void ** then I'll have to
declare many variables as pointers (to pointers ...) to void; and castings
to struct o * will cascade though the program and it will become far less
type safe as a whole.

Perhaps this is the C way. Advice appreciated.

Regards,
Adam

[Jens.Toerring]

Adam Warner <us****@consulting.net.nz> wrote:

When adding variable length arrays to my program I created the elements as
type struct o *. This is because /most/ of the time the VLAs contains
pointers to struct o objects (these objects are as stringently aligned as
any C type in the implementation). Occasionally a single element is
actually a pointer to another VLA of pointers to struct o objects (and
occasionally I'm storing an integer index (of type ptrdiff_t) as an
immediate object).
I hope you never will have to port your program... Why don't you simply
use an array of unions? And how do you figure out what's the type of a
certain element when you pass it to another function, as you seem to
do? You have a good chance that you can't distinguish i.e. the ptrdiff_t
value 0 from a NULL pointer... And determining if something is a pointer
to a structure or a pointer to an array of structures is impossible,
even if you use some platform-specific extra information (like that you
know that a ptrdiff_t value must always be a small value and memory
addresses are always larger).
Casting a pointer to an integer is no problem. But GCC will not compile my
program when I tell it that an element of an array is actually a pointer
to the same type of array: void heap_trace_stack(struct o **ret0) {
//Follow local variables
if (ret0[-2]!=NULL) {
struct o **var=(struct o **) *ret0[-2]; //Line 207
While a negative array index looks definitely strange I have to take
your word that it's correct. But the problem you ask about is that
ret0 is of type 'struct o **'. Then 'ret0[-2]' is of type 'struct o *'
and finally '*ret[-2]' is of type 'struct o'. And the compiler doesn't
like to cast a structure to pointer to pointer to structure, which
seems to be rather reasonable - what would be the value of a structure
that would have to be assigned to the pointer?
The code above has been passed a VLA offset to the first element of a
particular category (&ret0[0]). If the element at the legal index position
-2 is not NULL then it's actually a pointer to another VLA of the same
type.

Sorry, but all of this sounds like a real maintainance nightmare in the
making. I hope _you_ still understand all the non-standard and weird
stuff you seem to be doing there in just a few days...

Regards, Jens
--
\ Jens Thoms Toerring ___ Je***********@physik.fu-berlin.de
\__________________________ http://www.toerring.de

[Adam Warner]

On Fri, 04 Feb 2005 11:38:22 +0000, Jens.Toerring wrote:

Adam Warner <us****@consulting.net.nz> wrote:

When adding variable length arrays to my program I created the elements as
type struct o *. This is because /most/ of the time the VLAs contains
pointers to struct o objects (these objects are as stringently aligned as
any C type in the implementation). Occasionally a single element is
actually a pointer to another VLA of pointers to struct o objects (and
occasionally I'm storing an integer index (of type ptrdiff_t) as an
immediate object).
I hope you never will have to port your program...

Try to avoid jumping to misconclusions. My request concerns a type issue
I'm experiencing. Once resolved this will again be portable C99 code.
Why don't you simply use an array of unions?
Try overlaying a VLA of length m+n+3 with these types:

| struct o *** | m | struct o *[m] | n | struct o *[n] |
-2 -1 0 m m+1 m+n
^pointer to this position is passed.
And how do you figure out what's the type of a certain element when you
pass it to another function, as you seem to do?
It's aways passed at a particular offset.
You have a good chance that you can't distinguish i.e. the ptrdiff_t
value 0 from a NULL pointer...
There's no chance involved. The type depends on the array position.
And determining if something is a pointer to a structure or a pointer to
an array of structures is impossible, even if you use some
platform-specific extra information (like that you know that a ptrdiff_t
value must always be a small value and memory addresses are always
larger).
I know what they are by their index position. I just have to coerce the
compiler into believing me.

Casting a pointer to an integer is no problem. But GCC will not compile
my program when I tell it that an element of an array is actually a
pointer to the same type of array:

void heap_trace_stack(struct o **ret0) {
//Follow local variables
if (ret0[-2]!=NULL) {
struct o **var=(struct o **) *ret0[-2]; //Line 207

While a negative array index looks definitely strange I have to take
your word that it's correct. But the problem you ask about is that ret0
is of type 'struct o **'. Then 'ret0[-2]' is of type 'struct o *' and
finally '*ret[-2]' is of type 'struct o'.

Then I may be following one too many levels of indirection!
And the compiler doesn't like to cast a structure to pointer to pointer
to structure, which seems to be rather reasonable - what would be the
value of a structure that would have to be assigned to the pointer?

It's only generally reasonable if the type system can process the original
data layout. What should be the type of my original VLA? void *** where
every element is cast to its correct type? I'd prefer an array of struct o
*vla[m+n+3] where I only have to cast index positions -2, -1 and m to
their correct type (after offsetting the pointer into the array).

Regards,
Adam

[Jens.Toerring]

Adam Warner <us****@consulting.net.nz> wrote:

On Fri, 04 Feb 2005 11:38:22 +0000, Jens.Toerring wrote:

Adam Warner <us****@consulting.net.nz> wrote:

When adding variable length arrays to my program I created the elements as
type struct o *. This is because /most/ of the time the VLAs contains
pointers to struct o objects (these objects are as stringently aligned as
any C type in the implementation). Occasionally a single element is
actually a pointer to another VLA of pointers to struct o objects (and
occasionally I'm storing an integer index (of type ptrdiff_t) as an
immediate object).

I hope you never will have to port your program... Try to avoid jumping to misconclusions. My request concerns a type issue
I'm experiencing. Once resolved this will again be portable C99 code.

Why don't you simply use an array of unions? Try overlaying a VLA of length m+n+3 with these types: | struct o *** | m | struct o *[m] | n | struct o *[n] |
-2 -1 0 m m+1 m+n
^pointer to this position is passed.

And how do you figure out what's the type of a certain element when you
pass it to another function, as you seem to do?

It's aways passed at a particular offset. You have a good chance that you can't distinguish i.e. the ptrdiff_t
value 0 from a NULL pointer... There's no chance involved. The type depends on the array position. And determining if something is a pointer to a structure or a pointer to
an array of structures is impossible, even if you use some
platform-specific extra information (like that you know that a ptrdiff_t
value must always be a small value and memory addresses are always
larger).

<rearranged>
I know what they are by their index position. I just have to coerce the
compiler into believing me.
<rearranged>
It's only generally reasonable if the type system can process the original
data layout. What should be the type of my original VLA? void *** where
every element is cast to its correct type? I'd prefer an array of struct o
*vla[m+n+3] where I only have to cast index positions -2, -1 and m to
their correct type (after offsetting the pointer into the array).

Admitedly I don't understand what you try to do there, but why use a VLA
of structure pointers for something that rather clearly isn't one? As far
as I can see you just want some memory area with m+n+3 times the size of
th largest entity you want to store there. Using a VLA of unions would
simplify things a lot, because then it's clear what type is accessed
by accessing the appropriate union member and you don' have to "lie"
to the compiler.

If you had e.g.

union omg {
struct o ***o3;
size_t count;
struct o **o2;
};

and

union omg omg_vla[ m + n + 3 ];

which should take exactly as much space as your *vla[m+n+3]. Then you
could call the function as

heap_stack_trace( omg_vla + 2 );

and use instead of

void heap_trace_stack(struct o **ret0) {
//Follow local variables
if (ret0[-2]!=NULL) {
struct o **var=(struct o **) *ret0[-2]; //Line 207
void heap_trace_stack( union omg *ret0 )
if ( ret0[ -2 ] != NULL ) {
struct o **var = *ret0[ -2 ].o3;

so you don't need a single cast and hopefully things are easier to
understand for someone else (and possibly for you in the long run;-)

BTW, you can "repair" your original code
struct o **var=(struct o **) *ret0[-2]; //Line 207

by using instead
<
struct o **var = * ( struct o *** ) ret0[ -2 ];

since 'struct O ***' is what you seem to have storted at ret0[-2].

Regards, Jens
--
\ Jens Thoms Toerring ___ Je***********@physik.fu-berlin.de
\__________________________ http://www.toerring.de

[Adam Warner]

On Fri, 04 Feb 2005 14:12:08 +0000, Jens.Toerring wrote:

Admitedly I don't understand what you try to do there, but why use a VLA
of structure pointers for something that rather clearly isn't one? As far
as I can see you just want some memory area with m+n+3 times the size of
the largest entity you want to store there. Using a VLA of unions would
simplify things a lot, because then it's clear what type is accessed by
accessing the appropriate union member and you don' have to "lie" to the
compiler.

If you had e.g.

union omg {
struct o ***o3;
size_t count;
struct o **o2;
};

and

union omg omg_vla[ m + n + 3 ];

which should take exactly as much space as your *vla[m+n+3].

That's fantastic! I finally understand your point thanks Jens. This will
be my first use of a top level union. I've used unions within structures
but I overlooked the flipside.

Many thanks,
Adam

[Jens.Toerring]

Je***********@physik.fu-berlin.de wrote:

void heap_trace_stack( union omg *ret0 )
if ( ret0[ -2 ] != NULL ) {

This must of course be

if ( ret0[ -2 ].o3 != NULL ) {

I hope you sptted that;-)
Regards, Jens

--
\ Jens Thoms Toerring ___ Je***********@physik.fu-berlin.de
\__________________________ http://www.toerring.de

[Jonathan Bartlett]

void heap_trace_stack(struct o **ret0) {
//Follow local variables
if (ret0[-2]!=NULL) {
struct o **var=(struct o **) *ret0[-2]; //Line 207
index num_var=(index) var[0];
...
}
...
}

Line 207 you are converting a struct itself into a pointer, which is the
problem.

ret0[-2] returns a "struct o *"
*ret0[-2] returns a "struct o", which can't possibly be cast into a pointer.

Perhaps you meant to do:

(struct o **) ret0[2]

Perhaps?

Anyway, that is what I think the problem is, at least, whatever the fix is.

Jon
----
Learn to program using Linux assembly language
http://www.cafeshops.com/bartlettpublish.8640017