Skip to content

Conversation

@jukkar
Copy link
Member

@jukkar jukkar commented Nov 18, 2020

llvm uses wrong int type for some reason, force cast to uint16_t

Fixes #29997

Signed-off-by: Jukka Rissanen jukka.rissanen@linux.intel.com

llvm uses wrong int type for some reason, force cast to uint16_t

Fixes zephyrproject-rtos#29997

Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
@galak galak added the Trivial Changes that can be reviewed by anyone, i.e. doc changes, minor build system tweaks, etc. label Nov 18, 2020
(_conn), net_pkt_get_len((_conn)->send_data), \
conn->unacked_len, conn->send_win, \
conn_mss((_conn))); \
(uint16_t)conn_mss((_conn))); \
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How can llvm be complaining about this? conn_mss produces either a value from tcp_options::mss which is uint16_t, or a constant that's explicitly cast to uint16_t. Is a preprocessor define causing something to not be what it appears to be?

Within that limit: ideally the code would not be assuming that uint16_t is a short. If the h length modifier is to be used, the argument should be cast to unsigned short. Otherwise just use %u, it'll work out due to the implicit conversion to int (and, if the value actually isn't representable in uint16_t the resulting output might show what's going on).

Not blocking, just don't think this has been fully investigated.

@nashif nashif merged commit 753412b into zephyrproject-rtos:master Nov 19, 2020
@jukkar jukkar deleted the bug-29997-wrong-int-type-used branch July 6, 2021 14:12
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

area: Networking Trivial Changes that can be reviewed by anyone, i.e. doc changes, minor build system tweaks, etc.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

format specifies type 'unsigned short' but the argument has type 'int' error in network stack

5 participants