wireguard (gcc13): cast enum limits members to int in prints
Commit Message
Since gcc13, each member of an enum has the same type as the enum [1]. And
that is inherited from its members. Provided "REKEY_AFTER_MESSAGES = 1ULL
<< 60", the named type is unsigned long.
This generates warnings with gcc-13:
error: format '%d' expects argument of type 'int', but argument 6 has type 'long unsigned int'
Cast the enum members to int when printing them.
Alternatively, we can cast it to ulong (to silence gcc < 12) and use %lu.
Alternatively, we can move REKEY_AFTER_MESSAGES away from the enum.
[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36113
Cc: Martin Liska <mliska@suse.cz>
Cc: "Jason A. Donenfeld" <Jason@zx2c4.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Eric Dumazet <edumazet@google.com>
Cc: Jakub Kicinski <kuba@kernel.org>
Cc: Paolo Abeni <pabeni@redhat.com>
Cc: wireguard@lists.zx2c4.com
Cc: netdev@vger.kernel.org
Signed-off-by: Jiri Slaby (SUSE) <jirislaby@kernel.org>
---
drivers/net/wireguard/timers.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
Comments
Hi Jiri,
On Mon, Oct 31, 2022 at 12:44:24PM +0100, Jiri Slaby (SUSE) wrote:
> Since gcc13, each member of an enum has the same type as the enum [1]. And
> that is inherited from its members. Provided "REKEY_AFTER_MESSAGES = 1ULL
> << 60", the named type is unsigned long.
>
> This generates warnings with gcc-13:
> error: format '%d' expects argument of type 'int', but argument 6 has type 'long unsigned int'
>
> Cast the enum members to int when printing them.
>
> Alternatively, we can cast it to ulong (to silence gcc < 12) and use %lu.
> Alternatively, we can move REKEY_AFTER_MESSAGES away from the enum.
>
> [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36113
Huh, interesting situation. It's interesting that 1<<60 even works at
all on old gccs. I guess that in this case, it just takes the type of
the actual constant, rather than of the enum type?
Either way, I'll apply (a version of) your patch and push it back out on
the next wireguard fixup series.
Thanks for this.
Jason
Hi,
On 31. 10. 22, 14:07, Jason A. Donenfeld wrote:
> On Mon, Oct 31, 2022 at 12:44:24PM +0100, Jiri Slaby (SUSE) wrote:
>> Since gcc13, each member of an enum has the same type as the enum [1]. And
>> that is inherited from its members. Provided "REKEY_AFTER_MESSAGES = 1ULL
>> << 60", the named type is unsigned long.
>>
>> This generates warnings with gcc-13:
>> error: format '%d' expects argument of type 'int', but argument 6 has type 'long unsigned int'
>>
>> Cast the enum members to int when printing them.
>>
>> Alternatively, we can cast it to ulong (to silence gcc < 12) and use %lu.
>> Alternatively, we can move REKEY_AFTER_MESSAGES away from the enum.
>>
>> [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36113
>
> Huh, interesting situation. It's interesting that 1<<60 even works at
> all on old gccs. I guess that in this case, it just takes the type of
> the actual constant, rather than of the enum type?
Exactly, on gcc <= 12, every enum member has a type depending solely on
its value. And yes, using anything outside <INT_MIN, INT_MAX> is
undefined (but obviously works). As well as using anything else than
_constants_.
thanks,
From: Jiri Slaby (SUSE)
> Sent: 31 October 2022 11:44
>
> Since gcc13, each member of an enum has the same type as the enum [1]. And
> that is inherited from its members. Provided "REKEY_AFTER_MESSAGES = 1ULL
> << 60", the named type is unsigned long.
>
> This generates warnings with gcc-13:
> error: format '%d' expects argument of type 'int', but argument 6 has type 'long unsigned int'
>
> Cast the enum members to int when printing them.
>
> Alternatively, we can cast it to ulong (to silence gcc < 12) and use %lu.
> Alternatively, we can move REKEY_AFTER_MESSAGES away from the enum.
I'd suggest moving the 'out of range' value out of the enum.
Otherwise integer promotion to 'long' might happen elsewhere
and the effects might not be desirable.
It is a shame that gcc doesn't force you to add the type
to 'big enums' (or emit a warning) so that the behavioural
change is properly detected.
From reading the gcc bug it seems that C++ has a syntax for that.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
@@ -46,7 +46,7 @@ static void wg_expired_retransmit_handshake(struct timer_list *timer)
if (peer->timer_handshake_attempts > MAX_TIMER_HANDSHAKES) {
pr_debug("%s: Handshake for peer %llu (%pISpfsc) did not complete after %d attempts, giving up\n",
peer->device->dev->name, peer->internal_id,
- &peer->endpoint.addr, MAX_TIMER_HANDSHAKES + 2);
+ &peer->endpoint.addr, (int)MAX_TIMER_HANDSHAKES + 2);
del_timer(&peer->timer_send_keepalive);
/* We drop all packets without a keypair and don't try again,
@@ -64,7 +64,7 @@ static void wg_expired_retransmit_handshake(struct timer_list *timer)
++peer->timer_handshake_attempts;
pr_debug("%s: Handshake for peer %llu (%pISpfsc) did not complete after %d seconds, retrying (try %d)\n",
peer->device->dev->name, peer->internal_id,
- &peer->endpoint.addr, REKEY_TIMEOUT,
+ &peer->endpoint.addr, (int)REKEY_TIMEOUT,
peer->timer_handshake_attempts + 1);
/* We clear the endpoint address src address, in case this is
@@ -94,7 +94,8 @@ static void wg_expired_new_handshake(struct timer_list *timer)
pr_debug("%s: Retrying handshake with peer %llu (%pISpfsc) because we stopped hearing back after %d seconds\n",
peer->device->dev->name, peer->internal_id,
- &peer->endpoint.addr, KEEPALIVE_TIMEOUT + REKEY_TIMEOUT);
+ &peer->endpoint.addr,
+ (int)(KEEPALIVE_TIMEOUT + REKEY_TIMEOUT));
/* We clear the endpoint address src address, in case this is the cause
* of trouble.
*/
@@ -126,7 +127,7 @@ static void wg_queued_expired_zero_key_material(struct work_struct *work)
pr_debug("%s: Zeroing out all keys for peer %llu (%pISpfsc), since we haven't received a new one in %d seconds\n",
peer->device->dev->name, peer->internal_id,
- &peer->endpoint.addr, REJECT_AFTER_TIME * 3);
+ &peer->endpoint.addr, (int)REJECT_AFTER_TIME * 3);
wg_noise_handshake_clear(&peer->handshake);
wg_noise_keypairs_clear(&peer->keypairs);
wg_peer_put(peer);