> > > One reason such things aren't as noticable is because most network
> > > protocols put the members in decreasing order of size, in an attempt
> > > to satisty the requirements for alignment and such, and inhibit any
> > > such compiler-specific :) things.
> >
> > ? Low level network protocol
> > > anyway) and to make sure I still understood it. Do you have a glibc
> > > source, too?
> >
> > There are many glibc sources (different versions) -- I
> > have the source of a large number of them.
> Oops I meant to note that I found it (glibc doc, section on c language
> foo).
>
> On that
On Wed, May 24, 2006 at 08:14:01PM +0200, Michael Kerrisk wrote:
> > > This macro is useful because the sizes of the fields that compose
> > > a structure can vary across implementations,
> > > and compilers may insert different numbers of padding
> > s/numbers/amounts/
>
> Umm. "number of ... by
> On Wed, May 24, 2006 at 08:14:01PM +0200, Michael Kerrisk wrote:
> > > > This macro is useful because the sizes of the fields that compose
> > > > a structure can vary across implementations,
> > > > and compilers may insert different numbers of padding
> > > s/numbers/amounts/
> >
> > Umm. "nu
On Wed, May 24, 2006 at 08:32:17PM +0200, Michael Kerrisk wrote:
> > > > anyway) and to make sure I still understood it. Do you have a glibc
> > > > source, too?
> > >
> > > There are many glibc sources (different versions) -- I
> > > have the source of a large number of them.
> > Oops I meant to
> > This macro is useful because the sizes of the fields that compose
> > a structure can vary across implementations,
> > and compilers may insert different numbers of padding
> s/numbers/amounts/
Umm. "number of ... bytes" seems more correct than
"amount of ... bytes".
M
--
Michael Kerrisk
m
6 matches
Mail list logo
