POSIX standards nitpick re: the GAWK extension API

[Kenny McCormack]

I've been reading lately where, according to POSIX (not the C standards,
mind you, but POSIX), type names ending in "_t" are reserved and should not
be used by user-space code.

The GAWK extension API uses several of these, e.g., gawk_api_t and
awk_value_t. I seriously doubt there will ever be a clash here, but,
technically, isn't this in violation of the standard?

Note: I realize that GAWK can be compiled/run on non-POSIX platforms, but,
still, I assume POSIX systems are a large part of the target audience.

--
"The anti-regulation business ethos is based on the charmingly naive notion
that people will not do unspeakable things for money." - Dana Carpender

Quoted by Paul Ciszek (pciszek at panix dot com). But what I want to know
is why is this diet/low-carb food author doing making pithy political/economic
statements?

Nevertheless, the above quote is dead-on, because, the thing is - business
in one breath tells us they don't need to be regulated (which is to say:
that they can morally self-regulate), then in the next breath tells us that
corporations are amoral entities which have no obligations to anyone except
their officers and shareholders, then in the next breath they tell us they
don't need to be regulated (that they can morally self-regulate) ...

[Kaz Kylheku]

On 2015-08-01, Kenny McCormack <gaz...@shell.xmission.com> wrote:
> I've been reading lately where, according to POSIX (not the C standards,
> mind you, but POSIX), type names ending in "_t" are reserved and should not
> be used by user-space code.

POSIX implementors should stick to the feature selection macros;
then there is no problem.

If any new public identifier is added to some existing header on or after
November 2017, I don't want to see it unless I have this on the
compiler command line:

-D_POSIX_C_SOURCE=201711L # or greater

If foobar_t is added to POSIX in 2018, and my program happens to use
foobar_t, I should be covered by the above.

When I decide to migrate the program to newer POSIX and raise the
value of that macro, I can deal with the clash then.

> The GAWK extension API uses several of these, e.g., gawk_api_t and
> awk_value_t. I seriously doubt there will ever be a clash here, but,
> technically, isn't this in violation of the standard?

Technically it is.

Technically, though, the standrad has repeatedly intruded into unannounced
namespaces, such as, oh, the namespace [a-zA-Z][a-zA-Z0-9_]+, which you
kind of have to use yourself.

A program written in 1990 could have used an external function sem_open,
for instance.

So the warning that whatever_t might be used by future versions of the
standard or the implementation is good for nothing.

If you heed the warning and call your type whatever_z, that is no guarantee
that POSIX won't have a future identifier.

Feature selection macros are supposed to solve this problem for compile
time identifiers, and weak symbols solve the problem for external names.

POSIX claims the identifiers "fcntl" and "read" for external linkage.
Strictly conforming ISO C programs can use these as external names, and
such programs work fine on your GNU/Linux box based on glibc. Why?
Because 1) "fcntl" and "read" are weak symbols, and 2) the library
doesn't itself call them. If it needs to call read, it instead calls some
internal hygienic name like __libc_read or whatever, so it will not
be thwarted by the program's redefinition of read.

So between that and feature selection macros ("please, only show me POSIX up to
a certain year and month, and no vendor extensions"), we don't need mechanisms
like "stay away from _t names".

[Janis Papanagnou]

On 01.08.2015 21:33, Kenny McCormack wrote:
> I've been reading lately where, according to POSIX (not the C standards,
> mind you, but POSIX), type names ending in "_t" are reserved and should not
> be used by user-space code.
>
> The GAWK extension API uses several of these, e.g., gawk_api_t and
> awk_value_t. I seriously doubt there will ever be a clash here, but,
> technically, isn't this in violation of the standard?
>
> Note: I realize that GAWK can be compiled/run on non-POSIX platforms, but,
> still, I assume POSIX systems are a large part of the target audience.

User defined types ending in _t can be found since decades - that means
pre-POSIX era! - everywhere. If in doubt project specific prefixes are
used, as gawk does, everthing seems okay.

A rationale for that strange sounding POSIX rule would be interesting.

Janis