Repository navigation
Warnings with gcc 15.2 #20242
Description
I did this
Compiling the following minimal program with gcc 15.2:
#include <stdint.h>
#include "curl/curl.h"
int
main()
{
uint32_t auth = CURLAUTH_ANY;
auth &= CURLAUTH_ANYSAFE;
}
issues the following warning:
warning: conversion from ‘long unsigned int’ to ‘uint32_t’ {aka ‘unsigned int’} changes value from ‘18446744073709551599’ to ‘4294967279’ [-Woverflow]
7 | uint32_t auth = CURLAUTH_ANY;
| ^~~~~~~~~~~~
Using options -Wno-overflow -Wconversion:
warning: conversion from ‘long unsigned int’ to ‘uint32_t’ {aka ‘unsigned int’} changes the value of ‘18446744073709551598’ [-Wconversion]
9 | auth &= CURLAUTH_ANYSAFE;
| ^~~~~~~~~~~~~~~~
IMO, curl.h computed constants should not have bits set outside their normal type domain. This is true at least for negated bit masks: aka:
#define CURLAUTH_ANY (~CURLAUTH_DIGEST_IE)
#define CURLAUTH_ANYSAFE (~(CURLAUTH_BASIC | CURLAUTH_DIGEST_IE))
#define CURLSSH_AUTH_ANY ~0L /* all types supported by server */
The case of
#define CURLPROTO_ALL (~0L) /* enable everything */
is unclear as long as we do not yet define protocol numbers > 31.
I expected the following
No warnings.
curl/libcurl version
8.15.0
operating system
Fedora 43
Activity
bagder commentedon Jan 11, 2026
The question is why you would use
uint32_tfor this variable when the libcurl API expects a long?monnerat commentedon Jan 11, 2026
Because you now have defined
struct authfields asuint32_ts.Of course, the caller is not aware of that in the context of a use with
curl_easy_setopt(), but this makes these constants hardly usable in our own code base.bagder commentedon Jan 11, 2026
Your example above is not libcurl code though!?
Yes I am aware, but that's not a compiler error or warning, that's mostly a nuisance.
monnerat commentedon Jan 11, 2026
Not officially. It appeared in the personal
safeauthbranch that I continue to keep up to date.Totally agreed, like many of these newly introduced warnings. But I guess our opinion has little weight against people wanting to turn C into a strong-typed language :-(
To come back to the original problem: why not masking off unused bits in the constant definitions ? This would resolve the problem without other drawback than a slightly less readable
url.h.bagder commentedon Jan 11, 2026
How do you mean?
monnerat commentedon Jan 11, 2026
Something like
include: mask *_ANY bitmasks to 32 bits
include: mask computed bitmasks to 32 bits
lib: store ssh auth types as long
lib: store ssh auth types as long
include: mask computed auth/proto bitmasks to 32 bits
include: mask computed auth/proto bitmasks to 32 bits
include: mask computed auth/proto bitmasks to 32 bits
include: mask computed auth/proto bitmasks to 32 bits