Opened 14 years ago
Closed 14 years ago
#270 closed defect (fixed)
udp_sendto_message() leaves data_fragment_size uninitialized
Reported by: | Jakub Jermář | Owned by: | Petr Koupy |
---|---|---|---|
Priority: | major | Milestone: | 0.5.0 |
Component: | helenos/net/udp | Version: | |
Keywords: | Cc: | ||
Blocker for: | Depends on: | ||
See also: |
Description
udp_sendto_message() is supposed to set its output argument data_fragment_size uninitialized, but it never does so.
Attachments (1)
Change History (5)
comment:1 by , 14 years ago
Milestone: | 0.4.3 → 0.5.0 |
---|
comment:2 by , 14 years ago
Owner: | set to |
---|---|
Status: | new → assigned |
by , 14 years ago
Attachment: | ticket270.patch added |
---|
comment:3 by , 14 years ago
comment:4 by , 14 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
Actually, the caller can receive both 0 and an actual data fragment size. If it receives 0, it does not attempt to modify its current cached value of data fragment size. On the other hand, a non-zero value will result in the client updating its value.
The meaning of data fragment size is that it tells the socket layer what is the maximum data size that can be sent over the lower protocol layers without causing fragmentation, eliminating thus some number of extra data copies.
I set this to what IP told UDP is the IP's maximum content size. Note that there is some commented code in UDP which seems to be able to determine the device's MTU, in which case (and if the code was not commented out) the MTU size would be used instead.
Fixed in changeset:mainline,914.
Fixed uninitialized out variable inside udp_sendto_message(). The only caller -
udp_process_client_messages() - was working correctly just because it has
initialized the parameter by itself before calling udp_sendto_message().
Actual correction seems to be quite trivial. NULL initialization was simply
moved from one place to another.