[MPlayer-dev-eng] [PATCH] Change lots of defines to one big enum.

[Bryan Henderson]

On 6/19/08, Uoti Urpala <uoti.urpala at pp1.inet.fi> wrote:
> On Thu, 2008-06-19 at 08:58 -0700, Bryan Henderson wrote:
>> On 6/18/08, Michael Niedermayer <michaelni at gmx.at> wrote:
>> > Tell that to the people who designed posix ...
>> > btw:
>> > http://www.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_02.html
>> > contains the list of what posix claims for itself ...
>>
>> The list of what POSIX reserves for itself, in that reference, does
>> not include _t.
>
> It does. Or more precisely, reserved for the standard OR implementations
> of the standard. See the last line of the first table.

I see the last line of the table.  But I also see that the only place
the table is referenced is in statements telling you what MAY be
present in a system header file of a POSIX compliant system.

>>   All it says about _t is that any type declared in a
>> system header file (of a POSIX-compliant system) must end in _t.
>
> Where do you see such a claim? I see no prohibition against declaring a
> type with a different name on that page

   The set of identifiers visible to the application consists of precisely ...

   Implementations may add symbols to the headers shown in the following
   table, provided the identifiers for those symbols either:

   1 ...  or

   2 ...  or

   3. End in the string indicated as a reserved suffix in the table
and do not use
      the reserved prefixes posix_, POSIX_, or _POSIX_, as long as the reserved
      suffix is in that part of the name considered significant by the
implementation.

And _t is in the table.

Ergo, you could not have the type BIGFILE in <stdio.h> and call
yourself POSIX-compliant, but you could have BIGFILE_t.

> (and such a rule without
> exceptions would conflict with the C standard type "FILE").

I oversimplified for the sake of brevity.  The rule does not apply to
types specifically required by the standard, such as FILE.  It also
allows a whole lot of other things that don't end in _t, but all for
very specific purposes.

>>   That
>> doesn't imply an Mplayer header file can't also have a type that ends
>> in _t.
>
> Those identifiers are reserved for the POSIX standard and operating
> systems implementing it.

I can see now I went an entirely wrong direction in arguing this
point.  The fact is that the POSIX standard is inapplicable to
Mplayer.  It specifies OS facilities, not movie players.  It does not
presume to tell you what you may and may not have in an application
header file.  "reserved for POSIX" means the OS can't use it except as
spelled out in POSIX; "reserved for the implementation" means POSIX
can't use it.

However, I can see the value in Mplayer avoiding the names that system
headers are allowed to use, for the sake of avoiding collisions.
Avoiding _t might be going too far, though, considering that it is
widely used outside of system headers and was even before POSIX was
created.