Re: [musl] [PATCH] Expose the fopencookie() data types more generally

[Rich Felker <dalias@libc.org>]

On Fri, Mar 31, 2023 at 12:35:36AM +0000, John Scott wrote:
> Hi,
> 
> We're allowed to expose these data types in POSIX-conforming
> applications since they're implementation-reserved, and I think it's
> a good idea. My use case is that I want to check for fopencookie()
> via dlsym() without defining _GNU_SOURCE, and having the definition
> of cookie_io_functions_t would be helpful for its usage.
> 
> You may pull the signed commit from https://git.sr.ht/~jscott/musl-libc or use the following patch
> 
> From f5f6db0d02db40dde067a3ad0a7fbd74f6019dd4 Mon Sep 17 00:00:00 2001
> From: John Scott <jscott@posteo.net>
> Date: Thu, 30 Mar 2023 20:26:13 -0400
> Subject: [PATCH] Expose the fopencookie() data types more generally
> 
> These data types end in _t and so can be exposed even when strict
> POSIX conformance is sought. This might be useful for an application
> that doesn't want other side effects of defining _GNU_SOURCE, but
> which still wants to use fopencookie().

While strictly speaking this is true, the "*_t is reserved" rule is
rather controversial, and probably not good to rely on without really
good reason. Even if you are dynamically binding to a symbol for
nonstandard functionality like this, you still should be explicitly
requesting that you want declarations for its
types/constants/whatever, or, in this case since the types are not
even opaque but explictly defined (and have to be, because you have to
be able to define functions with matching signatures), you can just
ignore the typedefs and write out the type to avoid depending on
declarations in the header.

Rich