Re: typecasting...
On Apr 30, 5:31 am, "Jim Langston" <tazmas...@rocketmail.com> wrote:
"aki" <akhileshrawat...@gmail.com> wrote in message
news:1177835325.342195.269310@n59g2000hsh.googlegroups.com...
i am receiving a buffer from network as char pointer. char
* buffer; this is an argument of my function. well i want
to decode this buffer. buffer contain a packet with
different fields as code of size 1 byte contain inter value
identifier of size 1 byte contain integer value and length
of size 2 byte. contain integer value.
as struct lcpHeader
{
uint8_t code;
uint8_t identifier;
uint16_t length;
};
i want to access it all fields.
1) code field
struct lcpHeader *hdr;
hdr=(struct lcpHeader*)buffer;
when i do switch(hdr->code)
will it give integer value contained in the code....?
how to access other fielsd?
i hope i have made clear what i wann do?
Do a sizeof kpHeader and make sure it's 32.
I don't know of any platform today where this is the case. On
most platforms, I'd expect a size of 4, but of course, there's
absolutely no guarantee. (Note that by using the integral types
from C99, he has ensured 8 bit bytes... and that the code won't
compile on every platform.)
It may be different although it
seems like it may be okay in this instance. I'm talking about padding
spaces. Lets say, for example, you had a structure:
struct kpHeader
{
uint8_t Code;
uint32_t Length;
};
You might think the sizeof that woudl be 40, but might be suprised that t=
he
size (on my platform) would be 64.
You must have a really exotic machine. On all of my systems
(PC's and Sparc based, 32 and 64 bits, Windows, Linux and
Solaris), it's 8.
That's why it's generally not a good
idea to try to cast socket data into a structure as padding may throw it
off. I do not know if your system is 32 bit aligned, 16 bit, etc...For t=
he
most part, two bytes followed by a short (16 bit) should fit in 32 bits, =
but
there is no guarantee.
The alignment is only part of the problem. There's also the
question of representation of the values. He still has problems
with regards to byte order, however, and if he tries the above
for an Internet protocol, on a PC, it won't work.
The only real solution is to access the buffer one byte at a
time, and use the individual bytes to build up the target data
type. For an Internet protocol, a two byte integral field
starting at offset 2 could be read by:
(buffer[ 2 ] & 0xFF) << 8 | (buffer[ 1 ] & 0xFF)
(I generally try to declare such buffers as unsigned char,
rather than plain char, so as to not need the "& 0xFF" all over
the place.)
The correct way to read his structure would be:
struct lcpHeader
getHeader(
unsigned char buffer )
{
lcpHeader result = {} ;
result.code = buffer[ 0 ] ;
result.identifier = buffer[ 1 ] ;
result.length = (buffer[ 2 ] << 8) | buffer[ 3 ] ;
return result ;
}
This, of course, supposes that the types in the transmission
buffer are also unsigned (or at least limited to non-negative
values), and that the protocol uses the standard Internet
protocol representations (which is far from universal). It
works regardless of the size or representation of the internal
types, and regardless of what padding might have been inserted
by the compiler.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34