Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Packed structs vs. unpacked structs: what's the difference?

Reply
Thread Tools

Packed structs vs. unpacked structs: what's the difference?

 
 
Jack Klein
Guest
Posts: n/a
 
      04-09-2006
On Sun, 09 Apr 2006 12:16:53 -0400, CBFalconer <(E-Mail Removed)>
wrote in comp.lang.c:

> Jack Klein wrote:
> > "pemo" <(E-Mail Removed)> wrote in comp.lang.c:
> >

> ... snip ...
> >>
> >> int main(void)
> >> {
> >> printf("sizeof(s1) is %d, sizeof(s2) is %d\n", sizeof(s1), sizeof(s2));

> >
> > This of course invokes undefined behavior twice, passing a size_t
> > to printf() with a conversion specifier of "%d". While the exact
> > type of size_t is implementation-defined, it is guaranteed never
> > to be a signed int.
> >
> > Either cast to int with "%d", or, even better, cast to unsigned
> > long and use "%lu".
> >
> > And yes, there are platforms where this will break, because size_t
> > is equivalent to unsigned long and long is physically larger than int.
> >
> >> return 0;
> >> }

>
> The advantages of unbridled pedantry. The difference between
> running and non-running code is one pedant.


Chuck, this time you've just gotten too obscure for me. Are you
agreeing with me, or with pemo?

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html
 
Reply With Quote
 
 
 
 
CBFalconer
Guest
Posts: n/a
 
      04-09-2006
Jack Klein wrote:
> CBFalconer <(E-Mail Removed)> wrote in comp.lang.c:
>> Jack Klein wrote:
>>> "pemo" <(E-Mail Removed)> wrote in comp.lang.c:
>>>

>> ... snip ...
>>>>
>>>> int main(void)
>>>> {
>>>> printf("sizeof(s1) is %d, sizeof(s2) is %d\n", sizeof(s1), sizeof(s2));
>>>
>>> This of course invokes undefined behavior twice, passing a size_t
>>> to printf() with a conversion specifier of "%d". While the exact
>>> type of size_t is implementation-defined, it is guaranteed never
>>> to be a signed int.
>>>
>>> Either cast to int with "%d", or, even better, cast to unsigned
>>> long and use "%lu".
>>>
>>> And yes, there are platforms where this will break, because size_t
>>> is equivalent to unsigned long and long is physically larger than int.
>>>
>>>> return 0;
>>>> }

>>
>> The advantages of unbridled pedantry. The difference between
>> running and non-running code is one pedant.

>
> Chuck, this time you've just gotten too obscure for me. Are you
> agreeing with me, or with pemo?


You And taking a dig at pemos sig. And creating a new measure.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>
Also see <http://www.safalra.com/special/googlegroupsreply/>


 
Reply With Quote
 
 
 
 
pemo
Guest
Posts: n/a
 
      04-09-2006
CBFalconer wrote:
> Jack Klein wrote:
>> CBFalconer <(E-Mail Removed)> wrote in comp.lang.c:
>>> Jack Klein wrote:
>>>> "pemo" <(E-Mail Removed)> wrote in comp.lang.c:
>>>>
>>> ... snip ...
>>>>>
>>>>> int main(void)
>>>>> {
>>>>> printf("sizeof(s1) is %d, sizeof(s2) is %d\n", sizeof(s1),
>>>>> sizeof(s2));
>>>>
>>>> This of course invokes undefined behavior twice, passing a size_t
>>>> to printf() with a conversion specifier of "%d". While the exact
>>>> type of size_t is implementation-defined, it is guaranteed never
>>>> to be a signed int.
>>>>
>>>> Either cast to int with "%d", or, even better, cast to unsigned
>>>> long and use "%lu".
>>>>
>>>> And yes, there are platforms where this will break, because size_t
>>>> is equivalent to unsigned long and long is physically larger than
>>>> int.
>>>>
>>>>> return 0;
>>>>> }
>>>
>>> The advantages of unbridled pedantry. The difference between
>>> running and non-running code is one pedant.

>>
>> Chuck, this time you've just gotten too obscure for me. Are you
>> agreeing with me, or with pemo?

>
> You


Aw, that's a shame - for a second there I was thinking, that's one less of
them, and one more of us!

> And taking a dig at pemos sig. And creating a new measure.


btw, *pemos* requires an apostrophe as it's /possessive/. Sorry - just a bit
picky on grammar


--
==============
Not a pedant
==============


 
Reply With Quote
 
Nick Keighley
Guest
Posts: n/a
 
      04-10-2006

Richard G. Riley wrote:
> On 2006-04-09, Nick Keighley <(E-Mail Removed)> wrote:
> > pete wrote:
> >> Richard G. Riley wrote:
> >> > On 2006-04-09, Daniel Rudy <(E-Mail Removed)> wrote:


> >> > > What is the difference between packed and unpacked structs?
> >> >
> >> > The packed keyword
> >>
> >> > I have no idea on the "standardness" of "packed".
> >>
> >> It's not standard C.

> >
> > ...and hence should be avoided if possible. "pragma pack" and their ilk
> > may slow your program at a slight saving in space and a loss of
> > portability.

>
> Pack is their for a reason : and not, I think, generally for saving
> space. It is to enable a structure to correctly map to correct byte/word/etc
> fields in protocol packets for example. Portability is not necessarily
> an issue in these cases.


why is portability not an issue for protocol stacks?

--
Nick Keighley

 
Reply With Quote
 
slebetman@yahoo.com
Guest
Posts: n/a
 
      04-10-2006
Nick Keighley wrote:
> Richard G. Riley wrote:
> > On 2006-04-09, Nick Keighley <(E-Mail Removed)> wrote:
> > > pete wrote:
> > >> Richard G. Riley wrote:
> > >> > On 2006-04-09, Daniel Rudy <(E-Mail Removed)> wrote:

>
> > >> > > What is the difference between packed and unpacked structs?
> > >> >
> > >> > The packed keyword
> > >>
> > >> > I have no idea on the "standardness" of "packed".
> > >>
> > >> It's not standard C.
> > >
> > > ...and hence should be avoided if possible. "pragma pack" and their ilk
> > > may slow your program at a slight saving in space and a loss of
> > > portability.

> >
> > Pack is their for a reason : and not, I think, generally for saving
> > space. It is to enable a structure to correctly map to correct byte/word/etc
> > fields in protocol packets for example. Portability is not necessarily
> > an issue in these cases.

>
> why is portability not an issue for protocol stacks?


Mainly because most things that can run TCP/IP will first make it a
priority to port gcc. So as long as the code is as portable as gcc is
it doesn't matter if other compilers can't use the code. Systems where
gcc is not appropriate, such as embedded microcontrollers, tend to also
be very resource constrained and requires a very different
implementation of the protocol stack anyway. Actually, IMHO, the number
one reason why the TCP/IP stack is written that way is historical. The
BSD stack was written that way and is considered by most in the
networking community as the canonical implementation. So you find that
the Linux and Windows TCP/IP stack are also written using this
nonstandard, nonportable* convention.

* Note: It's funny to call this nonstandard practice nonportable since
it has been ported to almost all existing OSes, Unix-like or otherwise.
The only stupid thing is that you have to do lots of #ifdef because
Microsoft's VC++ and gcc both have this feature but with different
syntax.

 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      04-10-2006
"(E-Mail Removed)" <(E-Mail Removed)> writes:
> Nick Keighley wrote:
>> Richard G. Riley wrote:

[...]
>> > Pack is their for a reason : and not, I think, generally for
>> > saving space. It is to enable a structure to correctly map to
>> > correct byte/word/etc fields in protocol packets for
>> > example. Portability is not necessarily an issue in these cases.

>>
>> why is portability not an issue for protocol stacks?

>
> Mainly because most things that can run TCP/IP will first make it a
> priority to port gcc. So as long as the code is as portable as gcc is
> it doesn't matter if other compilers can't use the code. Systems where
> gcc is not appropriate, such as embedded microcontrollers, tend to also
> be very resource constrained and requires a very different
> implementation of the protocol stack anyway.

[...]

I've used Unix systems (Cray Unicos) to which gcc has not been ported,
and other systems (AIX, arguably Solaris) where the gcc implementation
is not nearly as good as the "native" C compiler (or so I've heard; I
haven't measured it myself).

I suspect that most packet layouts are such that ordinary structure
declarations will map to them correctly. The choice of types for the
members won't be portable of course, but if there are no gaps within
the packet layout, and all the components of the packet are properly
aligned relative to the start of the packet, packing shouldn't be
necessary. (I think.)

--
Keith Thompson (The_Other_Keith) http://www.velocityreviews.com/forums/(E-Mail Removed) <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
packed structs JohnF C Programming 35 10-16-2012 04:13 PM
uint32_t 0x80000000 unpacked as 0x7FFFFFFF A. Farber Perl Misc 11 04-04-2009 07:07 PM
Converting Pack/Unpacked EBCDIC file to ASCII kristenzhang@gmail.com Java 9 02-24-2005 05:31 PM
const structs in other structs Chris Hauxwell C Programming 6 04-27-2004 07:03 PM
structs with fields that are structs Patricia Van Hise C Programming 5 04-05-2004 01:37 AM



Advertisments