Fri 10 Aug 2007 03:38:26 PM UTC, comment #11:
I think size_t would be the most portable choice personally. size_t is part of the C standard (including older ANSI C).
|
Fri 10 Aug 2007 03:19:20 PM UTC, comment #10:
So, do you suggest changing the size parameter to size_t?
|
Mon 30 Jul 2007 04:17:06 PM UTC, comment #9:
Note that a signed int may be as small as 32768 on a 16-bit architecture.
The C standard says that size_t is defined to be an unsigned integer type. I'm not definite whether it really means "an" integer type, as opposed to specifically "unsigned int", but I believe the former, which means it may be larger than an unsigned int.
|
Thu 21 Jun 2007 09:21:50 PM UTC, comment #8:
Since size_t seems more used on socket layer, change netconn_write with a int or a s32_t is good for me.
|
Thu 21 Jun 2007 08:19:41 PM UTC, comment #7:
Since the question on size_t is not really related to this bug, I'm closing this as fixed.
|
Thu 21 Jun 2007 07:37:49 PM UTC, comment #6:
OK, I've changed it now. The only problem is: which type should we use? I had this discussion previously (I think it was with Dmitry Potapov): opengroup.org says the len arguments for the socket functions should be size_t. At that time, I've favoured 'int' but now I think it is really better to convert them to size_t.
So api_msg_msg.msg.w.len would have to be size_t also. My problem is: how big is size_t?
I've made it 'int' until we have decided.
|
Wed 20 Jun 2007 03:14:21 PM UTC, comment #5:
Sure,I'll patch my code for now.
Thanks,
-Srinivas.
|
Wed 20 Jun 2007 03:05:59 PM UTC, comment #4:
If you really want, we will wait, but I think that change the netconn_write's parameter won't interact a lot with your job on #20021. So, Srinivas, patch your code, but don't worry, we keep this item opened.
|
Wed 20 Jun 2007 02:58:17 PM UTC, comment #3:
Keep in mind that I'm currently changing netconn_write because of bug #20021! This includes moving much of the processing into do_write (or api_msg.c, at least).
I think netconn_write can be changed to have an u32_t (or int?) argument, but please wait until bug #20021 is fixed!
|
Wed 20 Jun 2007 02:27:14 PM UTC, comment #2:
Since the "cut" in segment is already done in netconn_write, and that "size" is compare to tcp_sndbuf (which is a u16_t), I think we can change ...
err_t netconn_write(struct netconn conn, const void dataptr, u16_t size, u8_t copy)
in...
err_t netconn_write(struct netconn conn, const void dataptr, u32_t size, u8_t copy)
This is not a big change...
|
Wed 20 Jun 2007 02:13:27 PM UTC, comment #1:
I'd guess the initial reason is both the 'lw' in lwIP's name together with the assumption you'd never send that much data and the fact that the tcp header also has an u16_t for its length. Since netconn api was built on the existing tcp_write, it has taken over the u16_t. I personally don't see a problem in that, only lwip_send should check the value and call netconn_write multiple times to be correct (or at least assert or return a return value.
|
Wed 20 Jun 2007 02:04:25 PM UTC, original submission:
lwip_send() takes the 'size' parameter as 'int' where as netconn_write(..,u16_t size,..) and
tcp_enqueue(..,u16_t len,..)
takes it as unsigned short or u16_t. This results in truncating the data block size if the data size is greater than 2^16. (On a architecture where short is 16 bit)
Is there any reason for keeping the 'size' as u16_t in the netconn and tcp functions?
-Srinivas.
|