This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH 10/12] Warn when gettimeofday is called with non-null tzp argument.


On Wed, Aug 21, 2019 at 11:30 AM Adhemerval Zanella
<adhemerval.zanella@linaro.org> wrote:
> On 20/08/2019 10:21, Zack Weinberg wrote:
> > At this stage I don’t think we can issue warnings for settimeofday
> > with a non-null tzp argument, nor for arbitrary use of struct
> > timezone.  But we can warn about gettimeofday with non-null tzp.
> >
> > This uses a macro instead of an inline (fortify-style) function
> > because I got false positives with an inline, even with GCC 9.
>
> Would be troublesome to add a check for the new warning?

Do we have any infrastructure for testing for warnings?  I don't know about any.

> Also is the
> false positive a GCC defect or something limited with the inline
> usage?

I didn't look into it in any detail, but the uses of __warndecl +
__builtin_constant_p in bits/string2.h inlines all follow the pattern

    __extern_always_inline T func (ptr)
    {
      if (__builtin_constant_p (ptr) && something_else_p (ptr))
__issue_warning ();
      ...
    }

that is, issue a warning if ptr is a compile-time constant with some
property.  What we want for gettimeofday is just the opposite,

    if (! (__builtin_constant_p (ptr) && ptr == NULL)) __issue_warning ();

that is, warn whenever ptr is _not_ a compile-time NULL.  I wouldn't
be surprised if GCC's earliest unreachable-code removal passes, the
ones that happen early enough to prevent __attribute__((warning))
diagnostics from triggering, were tuned precisely for what
bits/string2.h does, and don't handle this inverse case properly.

zw


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]