Re: [PATCH v2 0/3] fcntl fortification

[Florian Weimer <fweimer@redhat.com>]

* Sergey Bugaev via Libc-alpha:

> 2. There is a __fcntl_types_compatible () macro which is a thin wrapper
>    over __builtin_types_compatible_p () in plain C, and uses an
>    std::is_same_v-like check (using partial template specialization) in
>    C++. Importantly, it uses __typeof () even in C++ (not decltype ()),
>    because we don't want the extra references appended to our type. For
>    example, we want 'int', not 'const int &' or 'int &&'.

I think you should avoid using __typeof, otherwise we need to add
another GCC check.  If you need to use decltype, you'll have to add a
__cplusplus version check.

> 5. Here's the fcntl () macro in all of its horrible glory:
>
>    #define fcntl(fd, cmd, ...)
>      (__VA_OPT__ (0 ?) __fcntl_2_inline (fd, cmd)

I think we should avoid the new __fcntl_2 symbol because it an
unnecessary optimization.

> 6. __fcntl_warn () is basically the same as __fcntl_alias (), except
>    it's defined with __warnattr. So you get a warning (not a hard error)
>    on type mismatch. This is in line with how pointer type mismatch is
>    handled elsewhere in C / GCC. You can of course escalate this to an
>    error with -Werror if you want to. Forgeting an argument when it's
>    required is still a hard error (__errordecl).

It would very nice if we could generate the appropriate warning for C
(-Wincompatible-pointer-types).  This is what I tried to do, but it
might actually be impossible.

Should we generate errors for C++?  It requires compatible pointer
types, after all.

> I have only really tested with (modern) GCC. I briefly checked with
> Clang, but the fortification doesn't seem to get enabled at all; perhaps
> it's failing some other check.

Which Clang version?

Siddhesh, maybe you could look at this?

Thanks,
Florian