void pointer

I have a test code below: while dereferencing i am using long int instead
of enum type. when long int is used it gives an invalid value 40961. but
in hex the low bit appears to be right always. But in principle, we wanted
to understand why this is happening. we understand that enum types are of
unsigned int types. And in QNX long int, int, unsigned int have 4 bytes
allocated. what makes this difference?

enum testswitch
{
TYPE1,
TYPE2,
MAX_TYPES
};

void *ptr;

void main()
{
unsigned int val=0;
testswitch switchtypes;
//long int switchtypes;
switchtypes=TYPE2;
ptr = (testswitch *)&switchtypes;
val = *(long int *)ptr;
printf(“value:%d\n”,val);
}

“radha krishnan” <radha.nk@geind.ge.com> wrote in message
news:d5vdhr$oho$1@inn.qnx.com

I have a test code below: while dereferencing i am using long int instead
of enum type. when long int is used it gives an invalid value 40961. but
in hex the low bit appears to be right always. But in principle, we wanted
to understand why this is happening.

we understand that enum types are of unsigned int types.

No they are not, by default Watcom will optimize the size of enum to be of
smallest size possible. In your case since the highest value is 2 then it
fits in the C. I’m check the old C++ standard (I don’t have the C or
lastest C++ available) and there is nothing in there that says that enum is
of int size. The standard also says that when casting is involved with enum
variable the enum varaible may contact a different value then the enum.

Basicaly your code is broken because you have made a wrong assumption.
Solutions are:

  • Change your code (this is the only safe and portable option)
  • Use -zq option of watcom to make enum of int size
  • add NOT_USED=MAX_INT at end of enum to make sure watcom uses 4 byte for
    storage



And in QNX long int, int, unsigned int have 4 bytes
allocated. what makes this difference?

enum testswitch
{
TYPE1,
TYPE2,
MAX_TYPES
};

void *ptr;

void main()
{
unsigned int val=0;
testswitch switchtypes;
//long int switchtypes;
switchtypes=TYPE2;
ptr = (testswitch *)&switchtypes;
val = *(long int *)ptr;
printf(“value:%d\n”,val);
}

What target are you compiling for? In QNX integers are 4 bytes only
on 32-bit targets. Look at limits.h.

Regards,
Bill Ghrist

“Mario Charest” postmaster@127.0.0.1 wrote in message
news:d5vi2o$rg5$1@inn.qnx.com

I’m check the old C++ standard (I don’t have the C or
lastest C++ available) and there is nothing in there that says that enum
is
of int size.

C99 6.7.2.2#4:

Each enumerated type shall be compatible with char, a signed integer type,
or an
unsigned integer type. The choice of type is implementation-defined,108) but
shall be
capable of representing the values of all the members of the enumeration.

  1. An implementation may delay the choice of which integer type until all
    enumeration constants have
    been seen.

Mario Charest wrote:

“radha krishnan” <> radha.nk@geind.ge.com> > wrote in message
news:d5vdhr$oho$> 1@inn.qnx.com> …
I have a test code below: while dereferencing i am using long int instead
of enum type. when long int is used it gives an invalid value 40961. but
in hex the low bit appears to be right always. But in principle, we wanted
to understand why this is happening.

we understand that enum types are of unsigned int types.

No they are not, by default Watcom will optimize the size of enum to be of
smallest size possible. In your case since the highest value is 2 then it
fits in the C. I’m check the old C++ standard (I don’t have the C or
lastest C++ available) and there is nothing in there that says that enum is
of int size. The standard also says that when casting is involved with enum
variable the enum varaible may contact a different value then the enum.

Basicaly your code is broken because you have made a wrong assumption.
Solutions are:

  • Change your code (this is the only safe and portable option)
  • Use -zq option of watcom to make enum of int size
  • add NOT_USED=MAX_INT at end of enum to make sure watcom uses 4 byte for
    storage

Tried using zq with cc, but still same problem exists.


And in QNX long int, int, unsigned int have 4 bytes
allocated. what makes this difference?

enum testswitch
{
TYPE1,
TYPE2,
MAX_TYPES
};

void *ptr;

void main()
{
unsigned int val=0;
testswitch switchtypes;
//long int switchtypes;
switchtypes=TYPE2;
ptr = (testswitch *)&switchtypes;
val = *(long int *)ptr;
printf(“value:%dn”,val);
}

you probably need
cc -Wc,-ei
or
cc -WC,-ei

ps: please read docs on compiler options


radha krishnan wrote:

Mario Charest wrote:


“radha krishnan” <> radha.nk@geind.ge.com> > wrote in message
news:d5vdhr$oho$> 1@inn.qnx.com> …

I have a test code below: while dereferencing i am using long int instead
of enum type. when long int is used it gives an invalid value 40961. but
in hex the low bit appears to be right always. But in principle, we wanted
to understand why this is happening.


we understand that enum types are of unsigned int types.


No they are not, by default Watcom will optimize the size of enum to be of
smallest size possible. In your case since the highest value is 2 then it
fits in the C. I’m check the old C++ standard (I don’t have the C or
lastest C++ available) and there is nothing in there that says that enum is
of int size. The standard also says that when casting is involved with enum
variable the enum varaible may contact a different value then the enum.


Basicaly your code is broken because you have made a wrong assumption.
Solutions are:

\

  • Change your code (this is the only safe and portable option)
  • Use -zq option of watcom to make enum of int size
  • add NOT_USED=MAX_INT at end of enum to make sure watcom uses 4 byte for
    storage


    Tried using zq with cc, but still same problem exists.



    And in QNX long int, int, unsigned int have 4 bytes
    allocated. what makes this difference?

enum testswitch
{
TYPE1,
TYPE2,
MAX_TYPES
};

void *ptr;

void main()
{
unsigned int val=0;
testswitch switchtypes;
//long int switchtypes;
switchtypes=TYPE2;
ptr = (testswitch *)&switchtypes;
val = *(long int *)ptr;
printf(“value:%dn”,val);
}









\

radha krishnan wrote:

Mario Charest wrote:
Basicaly your code is broken because you have made a wrong assumption.
Solutions are:

  • Change your code (this is the only safe and portable option)
  • Use -zq option of watcom to make enum of int size
  • add NOT_USED=MAX_INT at end of enum to make sure watcom uses 4 byte for
    storage


    Tried using zq with cc, but still same problem exists.

And you tried nothing else? You do realise everyone is telling you your code is broken don’t you? Try adding some size and address testing to prove that your assumptions are wrong …

printf(" Sizes of: testswitch=%d, int=%d, longint=%d\n", sizeof(testswitch), sizeof(int), sizeof(long int));
printf(“Addresses of: switchtype=%p, *ptr=%p, (longint)ptr=%p\n”, &switchtypes, ptr, (long int *)ptr);


Evan

PS: The above is untested.

On Thu, 12 May 2005 07:34:38 -0500, Mario Charest postmaster@127.0.0.1
wrote:
the -zq option means operate quietly
try -Wc,-ei

“radha krishnan” <> radha.nk@geind.ge.com> > wrote in message
news:d5vdhr$oho$> 1@inn.qnx.com> …
I have a test code below: while dereferencing i am using long int
instead
of enum type. when long int is used it gives an invalid value 40961. but
in hex the low bit appears to be right always. But in principle, we
wanted
to understand why this is happening.

we understand that enum types are of unsigned int types.

No they are not, by default Watcom will optimize the size of enum to be
of
smallest size possible. In your case since the highest value is 2 then it
fits in the C. I’m check the old C++ standard (I don’t have the C or
lastest C++ available) and there is nothing in there that says that enum
is
of int size. The standard also says that when casting is involved with
enum
variable the enum varaible may contact a different value then the enum.

Basicaly your code is broken because you have made a wrong assumption.
Solutions are:

  • Change your code (this is the only safe and portable option)
  • Use -zq option of watcom to make enum of int size
  • add NOT_USED=MAX_INT at end of enum to make sure watcom uses 4 byte for
    storage



    And in QNX long int, int, unsigned int have 4 bytes
    allocated. what makes this difference?

enum testswitch
{
TYPE1,
TYPE2,
MAX_TYPES
};

void *ptr;

void main()
{
unsigned int val=0;
testswitch switchtypes;
//long int switchtypes;
switchtypes=TYPE2;
ptr = (testswitch *)&switchtypes;
val = *(long int *)ptr;
printf(“value:%d\n”,val);
}




\


Using M2, Opera’s revolutionary e-mail client: http://www.opera.com/m2/

As suggeted tried with -WC, -ei, its working now.
Thanks for your help. Also tried printing all the addresses

enum testswitch
4 {
5 TYPE1=0,
6 TYPE2,
7 TYPE3,
8 MAX_TYPES
9 };
10 typedef enum testswitch Switches;
11
12 void *ptr;
13
14 void main()
15 {
16 int val=0;
17 //testswitch switchtypes;
18 Switches switchtypes;
19 switchtypes = TYPE2;
20 printf(“sizeofenum:%ld\n”, sizeof(testswitch));
21 ptr = &switchtypes;
22 printf(“Sizes of: testswitch:%d, int:%d, longint:%d\n”,
sizeof(Switches)
23 printf(“Address in ptr:%u\n”, ptr);
24 printf(“Address of ptr:%u\n”, &ptr);
25 printf(“Value of *(int *)ptr:%d\n”, *((int *)
ptr));
26 printf(“Value of switchtypes:%d\n”, switchtypes);
27 printf(“Address of switchtypes:%u\n”,
&switchtypes);
28 printf(“Value in Address of switchtypes:%d\n”, *
(&switchtypes));
29 printf(“Address of (int *)ptr:%u\n”, (int *)ptr);
30 val = *((int *)ptr);
31 printf(“value:%d\n”,val);
32
33 }

sizeofenum:1
Sizes of: testswitch:1, int:4, longint:4
Address in ptr:40460
Address of ptr:50212
Value of *(int *)ptr:40449
Value of switchtypes:1
Address of switchtypes:40460
Value in Address of switchtypes:1
Address of (int *)ptr:40460
value:40449
This is the result without -WC,-ei option.

Below are the results with -WC, -ei option:-
sizeofenum:4
Sizes of: testswitch:4, int:4, longint:4
Address in ptr:40452
Address of ptr:50212
Value of *(int *)ptr:1
Value of switchtypes:1
Address of switchtypes:40452
Value in Address of switchtypes:1
Address of (int *)ptr:40452
value:1

How is cc different from wcc in QNX?

One more thing noticed, wrote a test program wherein
char c=‘A’;
int a;
float f ;
when the address was printed:
sizeof(char):1
ADdr of int :40456
ADdr of char c:40468
ADdr of char ch:40464
ADdr of float :40460
eventhough sizofchar is 1 byte, 4 bytes are allocated, as we can see that
ch:addr 40464 and c address 40468?
How this address are allocated? as per sizeof(char) one a single byte to
be allocated?

something wrong with my assumption, again!!

Thanks in advance,
Radha

Wojtek Lerch wrote:

“Mario Charest” postmaster@127.0.0.1 wrote in message
news:d5vi2o$rg5$> 1@inn.qnx.com> …
I’m check the old C++ standard (I don’t have the C or
lastest C++ available) and there is nothing in there that says that enum
is
of int size.

C99 6.7.2.2#4:

Each enumerated type shall be compatible with char, a signed integer type,
or an
unsigned integer type. The choice of type is implementation-defined,108) but
shall be
capable of representing the values of all the members of the enumeration.

  1. An implementation may delay the choice of which integer type until all
    enumeration constants have
    been seen.

radha krishnan <radha.nk@geind.ge.com> wrote:

How is cc different from wcc in QNX?

cc is a front-end to Watcom’s compiler chain (wcc/wcc386, wlink)
that passes a set of QNX-specific options and shortcuts a variety
of other options, providing a more normal “Unix C compiler” style
of options. (Especially to wlink.)

One more thing noticed, wrote a test program wherein
char c=‘A’;
int a;
float f ;
when the address was printed:
sizeof(char):1
ADdr of int :40456
ADdr of char c:40468
ADdr of char ch:40464
ADdr of float :40460
eventhough sizofchar is 1 byte, 4 bytes are allocated, as we can see that
ch:addr 40464 and c address 40468?
How this address are allocated? as per sizeof(char) one a single byte to
be allocated?

To access a 4-byte value (e.g. int) that is not 4-byte aligned is a
VERY SLOW operation. So, as a general rule the compiler will store
all elements in memory that is aligned to their size. The char was
given one byte, then 3 bytes were skipped in order to make the int
be properly aligned.

If you had done something like:

char c;
char d;
int a;

I would expect that you would see d one byte later than c.

And, if you had done:

char c[4];
int a;

You would definitely have seen a still only 4 bytes later than
c, showing that each char only gets one byte.

-David

David Gibbs
QNX Training Services
dagibbs@qnx.com