Warnings with gcc 15.2

[monnerat]

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

[bagder]

The question is why you would use uint32_t for this variable when the libcurl API expects a long?

[monnerat]

Because you now have defined struct auth fields as uint32_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]

Because you now have defined struct auth fields as uint32_ts.

Your example above is not libcurl code though!?

this makes these constants hardly usable in our own code base.

Yes I am aware, but that's not a compiler error or warning, that's mostly a nuisance.

[monnerat]

Your example above is not libcurl code though!?

Not officially. It appeared in the personal safeauth branch that I continue to keep up to date.

that's not a compiler error or warning, that's mostly a nuisance.

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]

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.

How do you mean?

[monnerat]

How do you mean?

Something like

#define CURLAUTH_DOMAIN       (((unsigned long) 0xffffffff)
#define CURLAUTH_ANY          ((~CURLAUTH_DIGEST_IE) & CURLAUTH_DOMAIN)
#define CURLAUTH_ANYSAFE      (~(CURLAUTH_BASIC | CURLAUTH_DIGEST_IE) & \
                               CURLAUTH_DOMAIN)