Re: Small memory fixes for pg_createsubcriber

Tom Lane <tgl@sss.pgh.pa.us> writes:

> =?utf-8?Q?Dagfinn_Ilmari_Manns=C3=A5ker?= <ilmari@ilmari.org> writes:
>> Tom Lane <tgl@sss.pgh.pa.us> writes:
>>> libpq-fe.h has to be compilable by application code that has never
>>> heard of pg_config.h let alone c.h, so we'd have to tread carefully
>>> about not breaking that property.  But it seems like this would be
>>> worth looking into.
>
>> The fallback code isn't exactly complicated, so we could just duplicate
>> it in libpq-fe.h:
>
>> #ifndef __has_attribute
>> #define __has_attribute(attribute) 0
>> #endif
>
> The problem with that approach is the likelihood of stomping on
> symbols that a calling application will use later.  I think we
> really need a controlling #ifdef check on some PG_FOO symbol
> that we can be sure no outside application will have defined.
> Roughly speaking,
>
> #ifdef PG_USE_ALLOCATOR_CHECKS

As long as we're not checking for too many attributes, we could avoid
introducing the __has_attribute symbol by doing:

#if defined(__has_attribute) && __has_attribute(malloc)

> #define pg_attribute_malloc __attribute__((malloc))
> ...
> #else
> #define pg_attribute_malloc
> ...
> #endif
>
> and then we could make definition of PG_USE_ALLOCATOR_CHECKS
> be conditional on having the right compiler behavior, rather
> than trusting that a nest of #ifdef checks is sufficient to
> detect that.

But I just looked at the clang attribute docs
(https://clang.llvm.org/docs/AttributeReference.html#malloc), and it
only has the argumentless version, not the one that that declares the
matching deallocator, so you're right we need a more comprehensive
check.

> 			regards, tom lane

- ilmari