HPUX and Compaq problem-urgent

Hi All
Following is the lines of code which simply makes a structure of 1 bit member and 7 bit is unused.Then the structure is initialised with char pointer.The output on HPUX(BIG Endian) and Compaq(Little Endian) are different.On HPUX it gives zero and Compaq it gives 1. I never thought that the bit reading/writing within a byte will be different.Can U help me in understanding this behaviour.

I am looking at Endian issue on two platforms.

#include <stdio.h>

main(){

struct single_t{
unsigned int sh:1;
unsigned int unused:7;
};

struct single_t single,*ptr;

char ch=(char)1;
printf("%d",ch);

ptr=(struct single_t *)&ch;
printf("\nValue from C is %d",ptr->sh);

}

It is not legal to cast a pointer to char to be a pointer to a structure and then dereference it. When you break rules like that you get non-portable code. If you want your code to be portable, it's this easy: obey the rules.

As to understanding the behavior, the c standard does not specify which bits get allocated first with bit fields. The two compiler writers chose different paths.

Hi perderabo
The previuos "c" code was for just testing the machine behaviour.Actually the problem is as follows:
I am getting data on X.25 line which is read into a structure of following type-
struct track_number_t{
unsigned int sb:3;
unsigned int sttn:1;
unsigned int STR:12;
};
I am wondering what changes I will have to do so that the present Compaq running code should work on HPUX also. The above format refers to one type in ASTERIX 030 format used in eurocontrol standards.

I had written another code in which I have reversed the structure members delacration order on HPUX.After doing reverse I get the same output as on Compaq.Original code is in Ada and I am trying to simulate things in C for finding a solution.

#include <iostream>

main(){
struct track_number_t{
unsigned int sb:3;
unsigned int sttn:1;
unsigned int STR:12;
};
struct rev_track_number_t{
unsigned int STR:12;
unsigned int sttn:1;
unsigned int sb:3;
};
track_number_t track_number,*track_ptr;
//char *str="A8";
char *str="AA";
track_ptr = (track_number_t *)str;
std::cout << "Value of sb is "<< track_ptr->sb;
std::cout << std::endl << "value of sttn is "<< track_ptr->sttn;
std::cout<< std::endl<< "Value of STR is "<< track_ptr->STR;

//Steps on reversed struct
rev_track_number_t rev_track_number,*rev_track_ptr;
rev_track_ptr = (rev_track_number_t *)str;
std::cout<<std::endl<<"Printing reversed struct memebrs";
std::cout << "Value of sb is "<< rev_track_ptr->sb;
std::cout << std::endl << "value of sttn is "<< rev_track_ptr->sttn;
std::cout<< std::endl<< "Value of STR is "<< rev_track_ptr->STR;

}

Hope to hear from you soon.

You are still dereferencing a pointer after an illegal promotion. That is still illegal. And on an HP, you're risking a segmentation fault.

But the larger issue is that you are assuming that the internal layout of a structure is portable. It's not. Reversing the order of elements may indeed solve the problem of moving from compaq to hp. But you have traded one non-portable program for another. Next time, you may need to port to another box that leaves a gap between bit-fields. What then?

That was real quick :slight_smile:
Here are few more clarifications from my side
1)I am using chararcter or char array to simulate memory. As I said before that the data is coming from external line and I will be reading memory and assinging values to my structure members. (This I guess happens in any communication...wild guess).
2) As the communication is in octets i again presume that the octets coming one after another will be stored in consecutive locations and then assinged to local variables.

3)internal layout of a structure is portable. It's not
layout is standarderised and I am trying to allign my structure according to the standard.

4)To be concise if i can have a clear picture of what all happens when I transfer the single structure(using X.25 and not transfering it directly..just to make myself clear to u) from compaq to Hp system. Assume the structure I mentioned before. Now as the standard aslo demands the members should have same value on the two systems. for the same reason I am declaring my structures on compaq and hp differently so that in the end the members have same value.

Thanks a lot for ur time...can i request some more time from U :slight_smile:

1) You actually are dumping a collection of bits into a structure and then you are using the individual members. If you would do what you actually said in paragraph one, there would be no problem. Breaking the data up as it arrives and storing it into the individual members is the way to go.

2) I would hope so :smiley:

3) I know. You're hardly alone. But the practice still saddens me. I'll get over it.

4) You would be better off to stop thinking like that. You don't transfer a structure from one system to another. You tranfer a collection of data that might be called a frame, or a packet, or a cell, or a datagram. The data might be stored in structures at both ends. But the data comes out of the structure and is used to assemble a packet. The packet arrives at the other end. The data gets broken up and stored back into a similiar structure. I know, you want the packet to be the structure. I know it looks attractive to do that. I know it looks like it saves a lot of effort. But this why you're having trouble now.

Suppose, for a minute, that c had nothing called a structure. How would you write the code then? For the most part, that is what you should do. That would force you to code the algorithms correctly. Then go back and use structures only to organize collections of variables. That is all that structures are intended to do.

At this time I would like to clear myself of few more communications doubt..elaborating on ur 4th reply only for the present one...
I have to send following information to some application

unsigned int sb:3;
unsigned int sttn:1;
unsigned int STR:12;

forming a packet or frame may mean formaing an array of bytes and sending it.I guess this is what a data-packet may mean.Later on OS will hadd header and tail and form packet to gogogogo......
So ultimately my data is in form of array of bytes. Am i right..I doubt?

Anyways I have to transfer above information. I discuss two ways which are purely my theoritical assumption as i have not worked on communication protocol stacks or same before....
1)I will simply read sb and sttn as one byte char and STR as 2 single byte char.This will make an array of 4 bytes for me.This data frame i shall simply pass on to OS to send via network.singles bytes may be reassembled properly at other end but problems arise for STR being sent as 2 singlt byte chars.Which byte will be sent first?How the two bytes will be stored relatively?How it will be read at other end? So i see problems..

2)Other way is ..combine them into a structure as follows
struct track_number_t{
unsigned int sb:3;
unsigned int sttn:1;
unsigned int STR:12;
};

and send the bytes as chars or octets as is said in communication world. Here again the issue arises of which byte is transmitted first and how it is read.

Now when U say structures are not transmitted across network then what are the headers..eg TCP-IP header has address fields,packet number fields,check sum and bla bla ...I agree that at applicaion level we don't have to worry about headers and all but these are also programmed by some programmers which may not be called application programmer...how do they take care of endian issues...any idea.

Next i shall reply after 6 hours of sleep. I remember long bakc also U tried ur best to explain TCP-IP transmission to me but some how that is still not clear to me and the more I think I get confused.....

you shall hear from me after I get up :slight_smile:

Thanks a lot for ur patience...discussions on other points if any later...
Shobhit

Can i request some more explainations on above..please
Shobhit