Re: Large writable variables - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Large writable variables
Date
Msg-id 20181017200200.t752esxtgnefktu3@alap3.anarazel.de
Whole thread Raw
In response to Re: Large writable variables  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Responses Re: Large writable variables  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
List pgsql-hackers
On 2018-10-17 21:06:13 +0200, Peter Eisentraut wrote:
> On 16/10/2018 08:30, Andres Freund wrote:
> > This just reminded me that a couple times I wanted a cast that casts
> > away const, but otherwise makes sure the type stays the same. I don't
> > think there's a way to do that in C, but we can write one that verifies
> > the cast doesn't do something bad if gcc is used:
> > 
> > #if defined(HAVE__BUILTIN_TYPES_COMPATIBLE_P)
> > #define unconstify(cst, var) StaticAssertExpr(__builtin_types_compatible_p(__typeof(var), const cst), "wrong
cast"),(cst) (var)
 
> > #else
> > #define unconstify(cst, var) ((cst) (var))
> > #endif
> > 
> > Does anybody besides me see value in adding a cleaned up version of
> > that?
> 
> I've had the attached patch lying around.

Heh.


> As you can see there, there are a few places where it could be useful,
> but not too many.

Yea.

> The name CONST_CAST() is adapted from C++.
> 
> Your version with __builtin_types_compatible_p() doesn't work for
> casting between char * and const char *, so it wouldn't be very useful.

Huh, why wouldn't it work for char *? Seems to work fine for me?


> +/*
> + * Safer casting -- use this for casting away const or volatile.  It ensures
> + * that the source and target types are otherwise compatible.
> + */
> +#define CONST_CAST(t, x) ((void)((t)0 == (x)), (t)(x))
> +

Has the advantage that it probably works for globals, but OTOH, it only
works correctly for pointers, and it doesn't reliably trigger warnigns /
errors.

Greetings,

Andres Freund


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: DSM robustness failure (was Re: Peripatus/failures)
Next
From: Thomas Munro
Date:
Subject: Re: DSM robustness failure (was Re: Peripatus/failures)