Re: Header conformance/improvements (part 2)

[Daniel Sabogal <dsabogalcc@gmail.com>]

On Fri, Feb 23, 2018 at 2:20 PM, Rich Felker <dalias@libc.org> wrote:
> On Fri, Feb 23, 2018 at 01:32:49PM -0500, Daniel Sabogal wrote:
>
>> tar.h
>> -----
>> * TSVTX
>> this constant is XSI-shaded
>> glibc exposes it with _XOPEN_SOURCE
>
> tar.h is not governed by any modern standard. Not sure if there's any
> reason to change it. I feel like making it depend on FTMs is wrong.

I see that tar.h is specified here:
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/tar.h.html#tag_13_73

>> stropts.h
>> ---------
>> * RPROTMASK
>> this constant is non-standard and not reserved
>> glibc exposes it with _GNU_SOURCE
>
> Aside from the ioctl function, this is all deprecated/removed
> functionality, not governed by any profile of the standards we claim
> to support. Not sure if there's any reason to change it.

This header is obsolescent so it probably doesn't matter.

>> signal.h
>> --------
>> * int sigqueue(pid_t, int, /* const */ union sigval);
>> harmless; it just doesn't reflect http://austingroupbugs.net/view.php?id=844
>
> I don't think this is any actual diference; the const keyword is a nop
> there. Issue 844 is just about the standard gratuitously including a
> do-nothing keyword there.

Right. Keeping the qualifier here is harmless.

>> inttypes.h
>> ----------
>> * wchar_t
>> this symbol is exposed to the ISO C namespace
>> AFAICT, this symbol is CX-shaded, and according to n1570 7.8.2.4p1,
>> it seems to be intended that <stddef.h> be included to expose wchar_t
>
> Ah. This is problematic because functions declared in inttypes.h
> require wchar_t to prototype. Of course a shadow name for the same
> type can be defined (like how va_list is handled) but it's ugly...
>
>> wchar.h
>> -------
>> * FILE
>> this symbol is exposed to the ISO C namespace
>> AFAICT, this symbol is CX-shaded, and according to n1570 7.29.2.1p1,
>> it seems to be intended that <stdio.h> be included to expose FILE
>
> Similar issue. It could be fixed with a shadot typedef or explicit
> "struct _IO_FILE". The latter is ugly and something of a violation of
> the abstraction, I think..

Indeed. I think ISO C should have exposed these data types.