[ECOS] RedBoot sending incorrect TCP window size

[Bart Veer]

>>>>> "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