pkarashchenko commented on a change in pull request #5154:
URL: https://github.com/apache/incubator-nuttx/pull/5154#discussion_r778149092
##########
File path: include/nuttx/net/usrsock.h
##########
@@ -227,9 +228,9 @@ begin_packed_struct struct usrsock_message_req_ack_s
{
struct usrsock_message_common_s head;
- uint8_t xid;
- uint8_t reserved;
- int32_t result;
+ int16_t reserved;
Review comment:
Such so called "optimization" costed me a lot when I was building
communication in multi-core system between 32-bit and 64-bit cores :) and I
would not recommend to apply it in any types generic communication.
I see that no "usrsock_swapX" interface is not available, so the interface
currently supports messaging between same endian systems (that is friendly
speaking not always true for some multi-core systems).
I will let other reviewers to comment on this.
What I'm curious why in some cases the elements are sorted in type size
increase and in other with type size decrease? Like here and
```
begin_packed_struct struct usrsock_request_common_s
{
uint64_t xid;
int8_t reqid;
int8_t reserved;
} end_packed_struct;
```
And
```
begin_packed_struct struct usrsock_request_sendto_s
{
struct usrsock_request_common_s head;
int16_t usockid;
int32_t flags;
uint32_t buflen;
uint16_t addrlen;
} end_packed_struct;
begin_packed_struct struct usrsock_request_recvfrom_s
{
struct usrsock_request_common_s head;
int16_t usockid;
int32_t flags;
uint32_t max_buflen;
uint16_t max_addrlen;
} end_packed_struct;
```
even do not care about sorting.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
