Hi,
On 2026-09-15 10:03:57 +0200, Peter Eisentraut wrote:
> From d5384f9e391a10177fd7bf06c866e62834f52896 Mon Sep 17 00:00:00 2001
> From: Peter Eisentraut <peter@eisentraut.org>
> Date: Tue, 15 Sep 2026 08:43:09 +0200
> Subject: [PATCH v2 5/8] Change float{4,8}in_internal take const char * input
> argument
>
> This makes the function signature match strtof()/strtod().
> float4
> -float4in_internal(char *num, char **endptr_p,
> +float4in_internal(const char *num, char **endptr_p,
> const char *type_name, const char *orig_string,
> struct Node *escontext)
> {
it's somewhat gross to have an API that has char **endptr_p point into a const
char *...
> @@ -269,37 +269,37 @@ float4in_internal(char *num, char **endptr_p,
> if (pg_strncasecmp(num, "NaN", 3) == 0)
> {
> val = get_float4_nan();
> - endptr = num + 3;
> + endptr = unconstify(char *, num) + 3;
> }
> else if (pg_strncasecmp(num, "Infinity", 8) == 0)
> {
> val = get_float4_infinity();
> - endptr = num + 8;
> + endptr = unconstify(char *, num) + 8;
> }
> ...
I don't like that this is adding a large number of unconstify()s. The only
thing that makes it a bit awkward to make endptr const itself is
endptr_p. It'd be tempting to just remove it, most callers don't even use it -
but unfortunately it looks like single_decode() does.
It seems like it'd be less ugly to just unconstify the two places that
actually need it (the call to strtod() and the assignment to *endptr_p).
> From bb7d887646ec7f1a83d1a5f9e370861a82c86ff8 Mon Sep 17 00:00:00 2001
> From: Peter Eisentraut <peter@eisentraut.org>
> Date: Tue, 15 Sep 2026 08:43:09 +0200
> Subject: [PATCH v2 7/8] Additional unvolatize uses
>
> Add some uses of unvolatize to silence warnings that would be
> triggered by -Wcast-qual.
>
> Note that the MemSet() calls would be normal "discards qualifier"
> warnings if memset() (or another function with a prototype, not a
> macro) were used.
ISTM just about all these volatiles are just pointless magic-wand
volatiles. volatile doesn't fix memory ordering (except on msvc), assigning
volatile to entire struct is bogus hokus pokus.
The fact that we have to unvolatize them shows that we are fundamentally not
relying on the guarantees of volatile, the invoked functions don't know about
the volatile!
Greetings,
Andres Freund