Обсуждение: unconstify()/unvolatize() vs g++/clang++

Hi,

AFAICS you can't use unconstify()/unvolatize() in a static inline
function in a .h file, or in a .cpp file, because
__builtin_types_compatible_p is only available in C, not C++.  Seems
like a reasonable thing to want to be able to do, no?  I'm not
immediately sure what the right fix is; would #if
defined(HAVE__BUILTIN_TYPES_COMPATIBLE_P) && !defined(__cplusplus)
around the relevant versions of constify()/unvolatize() be too easy?

HAVE__BUILTIN_TYPES_COMPATIBLE_P is also tested in relptr.h, but only
for further preprocessor stuff, not in functions that the compiler
will see, so cpluspluscheck doesn't have anything to reject, and
nothing will break unless someone writing C++ code actually tries to
use relptr_access().  I think we can live with that one?

On 11.12.23 01:42, Thomas Munro wrote:
> AFAICS you can't use unconstify()/unvolatize() in a static inline
> function in a .h file, or in a .cpp file, because
> __builtin_types_compatible_p is only available in C, not C++.  Seems
> like a reasonable thing to want to be able to do, no?  I'm not
> immediately sure what the right fix is; would #if
> defined(HAVE__BUILTIN_TYPES_COMPATIBLE_P) && !defined(__cplusplus)
> around the relevant versions of constify()/unvolatize() be too easy?

That seems right to me.

If you are slightly more daring, you can write an alternative definition 
in C++ using const_cast?

On Mon, Dec 11, 2023 at 10:17 PM Peter Eisentraut <peter@eisentraut.org> wrote:
> If you are slightly more daring, you can write an alternative definition
> in C++ using const_cast?

Oh, yeah, right, that works for my case.   I can't think of any
reasons not to do this, but IANAC++L.

On Mon, Dec 11, 2023 at 11:32 PM Thomas Munro <thomas.munro@gmail.com> wrote:
> On Mon, Dec 11, 2023 at 10:17 PM Peter Eisentraut <peter@eisentraut.org> wrote:
> > If you are slightly more daring, you can write an alternative definition
> > in C++ using const_cast?
>
> Oh, yeah, right, that works for my case.   I can't think of any
> reasons not to do this, but IANAC++L.

And pushed.  Thanks!