Thread (4 messages) 4 messages, 3 authors, 2019-03-20

Re: [PATCH RFC v2] mac80211: debugfs option to force TX status frames

From: Jeremy Sowden <hidden>
Date: 2019-03-11 14:53:24
Also in: linux-wireless, lkml

On 2019-03-11, at 16:03:38 +0200, Kalle Valo wrote:
ga58taw@mytum.de writes:
quoted
On Thu, Mar 07, 2019 at 05:42:04PM +0200, Kalle Valo wrote:
quoted
quoted
+   len = scnprintf(buf, sizeof(buf), "%d\n",
                   (int)local->force_tx_status);
I wonder about the cast, is it guaranteed that a bool is always of
the same size as an int?
Why is this a problem? If a bool is smaller than an int, the
compiler emits code that will prepend the value of force_tx_status
with zeros.
Let's say that a bool is a byte and int is four bytes. If you use "%d"
I would guess that in that case scnprintf() writes 4 bytes, meaning
that 3 bytes will be overwriting either padding or some other field in
the struct.
It's the value that matters, not the type.  It will only be too big for
the buffer if the result of casting local->force_tx_status to int is
less than -9 or greeater than 99.

  scnprintf(buf, size(buf), "%lld\n", (long long)local->force_tx_status)

would also be fine if the value were in range.  Note also that scnprintf
will not overrun the buffer: it will truncate the string.
But I'm no compiler expert so I'm not going to argue about this
anymore.  I just wanted to point out that that the cast looks
dangerous and I would not do it.
As it happens, arguments to variadic functions are subject to the
"default argument promotions," so if local->force_tx_status is in fact a
bool (I can't find the definition), it would be promoted to int and the
cast is superfluous.

J.

Attachments

Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help