This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: RedBoot sending incorrect TCP window size
>>>>> "Grant" == Grant Edwards <grante@visi.com> writes:
Grant> On Thu, Feb 08, 2001 at 09:15:29PM +0100, Donnat Eric wrote:
>> > All occurrences of "sizeof (eth_header_t)" in net.h, tcp.c, udp.c
>> > need to be replace by a hard coded constant. I'll send a patch
>> > later today...
>>
>> You can always avoid the hard coded constant by computing the
>> "real" limit of the struct as the offset to the last field +
>> the size of this last field. This should always work if the
>> last field is not a struct/bitfield ! (See stddef.h)
Grant> For some things that might be a better solution. On a more
Grant> pragmatic note, the size of an Ethernet header is etched in
Grant> billions of pieces of silicon spread all over the world.
Grant> It's 14. Always. Everywhere. It's not going to change.
>> To finnish with the "sizeof" story, you will see with following
>> sample that the reported value of sizeof is compatible with the
>> data representation and obviously with pointer arithmetic. Look
>> at gernerated asm.
Grant> I agree that the sizeof value is consistent with the code
Grant> generated by the compiler. It's just not consistent with
Grant> the size of an Ethernet header. :)
I suspect that there have been arguments about the behaviour of
sizeof() in gcc since the early days of the compiler. In fact the
issue will have arisen with most C compilers. There simply is no good
solution. The definition of sizeof() in the C specification is not
sufficiently precise. Sometimes you want sizeof(struct) to be a
minimal value, 14 bytes in your case, and for different structures you
may want a value of 16 bytes that takes external padding into account,
e.g. for figuring out what is using up all of the heap. Most C
programmers get caught out by this problem sooner or later.
Possibly there should be a gcc extension __packed_sizeof(), returning a
number that excludes external padding. This would not be a complete
solution: people would still use sizeof() in a non-portable fashion.
However it might make it easier to write portable code.
Any further discussion of such an extension should happen in the
appropriate gcc mailing list.
Bart