|
From: | address@hidden |
Subject: | Re: [lwip-devel] netconn/socket: converting len argument to size_t |
Date: | Sat, 14 Feb 2009 14:20:19 +0100 |
User-agent: | Thunderbird 2.0.0.19 (Macintosh/20081209) |
bill wrote:
-----Original Message----- No, since tcp_pcb->snd_buf is an u16_t (like Jacob wrote in his last mail), 64k-1 is the limit. I was only speaking of *if* that was possible, one needed to change tcp_write, but without that, changing tcp_write to accept an u32_t is not necessary. SimonWhy not simply make it unsigned so that it follows the native processor register size for the given platform? Isn't a system really constrained on memory more likely to have sizeof(unsigned) == sizeof(u16_t) anyway? Is it really any more efficient to call tcp_write once with a large block of data versus letting the stack call back to tcp_sent a couple or few times?
Please don't get me wrong: I didn't want to suggest converting the length parameter for TCP to u32_t! For me it's fine like it is now: the other APIs can handle blocks of more than 64K.
However, if someone wanted to use window-scaling there would be many places where the current data types could not be sufficient. Personally, I don't think that fits into the current lwIP strategy of 'lw'...
I guess the idea of converting variables to native size could have a positive impact on code size in many places, but the code also gets less testable if the size of a data type is unknown.
Simon
[Prev in Thread] | Current Thread | [Next in Thread] |