This is the mail archive of the 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: [RFC v5 01/21] sunrpc/clnt_udp: Ensure total_deadline is initalised

On 9/5/19 9:02 AM, Joseph Myers wrote:
> On Thu, 5 Sep 2019, Alistair Francis wrote:
>> On Thu, Aug 29, 2019 at 10:34 AM Zack Weinberg <> wrote:
>>> On Thu, Aug 29, 2019 at 1:22 PM Joseph Myers <> wrote:
>>>> On Thu, 29 Aug 2019, Alistair Francis wrote:
>>>> The long pole is definitely the ml2014 build environment, unless for some reason we need the new version of pip first? I don't actually know.  I'm assu
>>>>> Even though total_deadline won't be accessed uninitalised GCC can still
>>>>> complain that it is accessed unitalised, to avod those errors let's make
>>>>> sure we initalise it to 0.
>>>> It's glibc practice (although missing from
>>>> <>) that we *don't*
>>>> add initializations like that to avoid warnings.
>>> Although this has historically been glibc practice, I think it is
>>> unwisely incautious, and we should change the policy to be that we
>>> *do* add initializations whenever the compiler thinks a variable even
>>> _might_ be used uninitialized.
>> Does that mean this patch is ok?
> No.  You can't deduce consensus like that from two different views on a 
> patch or a convention.  Even if we were to change the convention regarding 
> how to silence such warnings, I see reason to have any less requirement 
> for comments explaining why the warning is a false positive and that the 
> initializer is only there to silence a warning than there is for the 
> DIAG_* macros.
BTW, has a bug been filed against GCC for the bogus warning?


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