Re: open_safer on amd64

[Ben Pfaff]

Eric Blake <address@hidden> writes:

> In earlier versions of POSIX, the intent was that mode_t could
> be narrower than int, and that all programmers had to use only symbolic
> constants in that argument.  But POSIX 2008 changed its stance by adding
> these words:
>
> The <sys/stat.h> header shall define the following symbolic constants for
> the file mode bits encoded in type mode_t, with the indicated numeric
> values. These macros shall expand to an expression which has a type that
> allows them to be used, either singly or OR'ed together, as the third
> argument to open() without the need for a mode_t cast. The values shall be
> suitable for use in #if preprocessing directives.

I don't see how this bans "short" as the type for mode_t.
"short" promotes to "int" when passed as a varargs argument.

> which effectively requires that mode_t and int be compatible types when
> passed through va_arg.  

Isn't that a separate issue?  Passing "short" as the type
argument to va_arg is banned not because of what it promotes to
but because the type passed to va_arg must be the type after
promotion, i.e. "int" in the case of a short passed in.

> POSIX 2008 also recognized traditional open-coding
> (like 0660) instead of symbolic macros for mode_t values.

I guess this means that mode_t can't be, say, "long", since
open-coded 0660 wouldn't promote to "long".
-- 
"[Modern] war is waged by each ruling group against its own subjects,
 and the object of the war is not to make or prevent conquests of territory,
 but to keep the structure of society intact."
--George Orwell, _1984_