Re: [PoC] Federated Authn/z with OAUTHBEARER

On 30.07.24 00:30, Jacob Champion wrote:
>> But under what circumstances does "the linker doesn't strip out" happen?
>>    If this happens accidentally, then we should have seen some buildfarm
>> failures or something?
> On my machine, for example, I see differences with optimization
> levels. Say you inadvertently call pfree() in a _shlib build, as I did
> multiple times upthread. By itself, that shouldn't actually be a
> problem (it eventually redirects to free()), so it should be legal to
> call pfree(), and with -O2 the build succeeds. But with -Og, the
> exit() check trips, and when I disassemble I see that pg_malloc() et
> all have infected the shared object. After all, we did tell the linker
> to put that object file in, and we don't ask it to garbage-collect
> sections.

I'm tempted to say, this is working as intended.

libpgcommon is built as a static library.  So we can put all the object 
files in the library, and its users only use the object files they 
really need.  So this garbage collection you allude to actually does 
happen, on an object-file level.

You shouldn't use pfree() interchangeably with free(), even if that is 
not enforced because it's the same thing underneath.  First, it just 
makes sense to keep the alloc and free pairs matched up.  And second, on 
Windows there is some additional restriction (vague knowledge) that the 
allocate and free functions must be in the same library, so mixing them 
freely might not even work.