Warnings Compiling openssl 1.0.2d

classic Classic list List threaded Threaded
30 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Warnings Compiling openssl 1.0.2d

Tom Browder
I get the following warnings from compiling the latest openssl with gcc 4.7.2:

ec_key.c: In function 'EC_KEY_set_public_key_affine_coordinates':
ec_key.c:369:26: warning: variable 'is_char_two' set but not used
[-Wunused-but-set-variable]

ecp_nistp224.c: In function 'batch_mul':
ecp_nistp224.c:1105:29: warning: array subscript is above array bounds
[-Warray-bounds]

ecp_nistp256.c: In function 'batch_mul':
ecp_nistp256.c:1631:28: warning: array subscript is above array bounds
[-Warray-bounds]

ecp_nistp521.c: In function 'batch_mul':
ecp_nistp521.c:1457:29: warning: array subscript is above array bounds
[-Warray-bounds]

I'm not real current with C so I'm not in a great position to
criticize, but can't those warnings (if there is truly no problem) be
eliminated (at least in gcc) with a pragma?

Thanks.

Best regards,

-Tom
_______________________________________________
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Warnings Compiling openssl 1.0.2d

Viktor Dukhovni
On Thu, Jul 09, 2015 at 09:47:00AM -0500, Tom Browder wrote:

> I get the following warnings from compiling the latest openssl with gcc 4.7.2:
>
> ecp_nistp224.c: In function 'batch_mul':
> ecp_nistp224.c:1105:29: warning: array subscript is above array bounds
> [-Warray-bounds]

In my copy of 1.0.2d, line 1105 of that file is in select_point(),
not batch_mul().  Are you sure you're compiling the right code?

--
        Viktor.
_______________________________________________
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Warnings Compiling openssl 1.0.2d

Matt Caswell-2
In reply to this post by Tom Browder


On 09/07/15 15:47, Tom Browder wrote:
> I get the following warnings from compiling the latest openssl with gcc 4.7.2:
>
> ec_key.c: In function 'EC_KEY_set_public_key_affine_coordinates':
> ec_key.c:369:26: warning: variable 'is_char_two' set but not used
> [-Wunused-but-set-variable]

I don't get this by default, but can force it by compiling with no-ec2m.
I assume that is what you are using? Its harmless but should be fixed.


>
> ecp_nistp224.c: In function 'batch_mul':
> ecp_nistp224.c:1105:29: warning: array subscript is above array bounds
> [-Warray-bounds]
>
> ecp_nistp256.c: In function 'batch_mul':
> ecp_nistp256.c:1631:28: warning: array subscript is above array bounds
> [-Warray-bounds]
>
> ecp_nistp521.c: In function 'batch_mul':
> ecp_nistp521.c:1457:29: warning: array subscript is above array bounds
> [-Warray-bounds]

These only get compiled with enable-ec_nistp_64_gcc_128, but even with
that I don't see these warnings. Perhaps a gcc issue fixed in later
versions? I'm using gcc 4.9.2

Matt
_______________________________________________
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Warnings Compiling openssl 1.0.2d

Tom Browder
In reply to this post by Viktor Dukhovni
On Thu, Jul 9, 2015 at 10:22 AM, Viktor Dukhovni
<[hidden email]> wrote:
> On Thu, Jul 09, 2015 at 09:47:00AM -0500, Tom Browder wrote:
...
>> ecp_nistp224.c: In function 'batch_mul':
>> ecp_nistp224.c:1105:29: warning: array subscript is above array bounds
...
> In my copy of 1.0.2d, line 1105 of that file is in select_point(),
> not batch_mul().  Are you sure you're compiling the right code?

Yes, and you're right about the function--weird, but maybe Matt's
e-mail points out the real problem.

Thanks, Viktor.

-Tom
_______________________________________________
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Warnings Compiling openssl 1.0.2d

Tom Browder
In reply to this post by Matt Caswell-2
On Thu, Jul 9, 2015 at 10:25 AM, Matt Caswell <[hidden email]> wrote:

>
>
> On 09/07/15 15:47, Tom Browder wrote:
>> I get the following warnings from compiling the latest openssl with gcc 4.7.2:
>>
>> ec_key.c: In function 'EC_KEY_set_public_key_affine_coordinates':
>> ec_key.c:369:26: warning: variable 'is_char_two' set but not used
>> [-Wunused-but-set-variable]
>
> I don't get this by default, but can force it by compiling with no-ec2m.
> I assume that is what you are using? Its harmless but should be fixed.

Yes, you are correct.  I should have been more specific: I am using
openssl version 1.0.2d, and here is my configuration script:

$ cat openssl-config.sh
SSLDIR=/opt/openssl
./config \
    no-ec2m                         \
    no-rc5                          \
    no-idea                         \
    threads                         \
    zlib-dynamic                    \
    shared                          \
    --prefix=${SSLDIR}              \
    --openssldir=${SSLDIR}          \
    enable-ec_nistp_64_gcc_128

>> ecp_nistp521.c: In function 'batch_mul':
>> ecp_nistp521.c:1457:29: warning: array subscript is above array bounds
>> [-Warray-bounds]

> These only get compiled with enable-ec_nistp_64_gcc_128, but even with
> that I don't see these warnings. Perhaps a gcc issue fixed in later
> versions? I'm using gcc 4.9.2

Hm, I've been looking for an excuse to build the latest gcc, now I have.

But I haven't tried clang yet so here goes...

Thanks, Matt.

Best,

-Tom
_______________________________________________
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Warnings Compiling openssl 1.0.2d

Viktor Dukhovni
In reply to this post by Tom Browder
On Thu, Jul 09, 2015 at 11:50:25AM -0500, Tom Browder wrote:

> On Thu, Jul 9, 2015 at 10:22 AM, Viktor Dukhovni
> <[hidden email]> wrote:
> > On Thu, Jul 09, 2015 at 09:47:00AM -0500, Tom Browder wrote:
> ...
> >> ecp_nistp224.c: In function 'batch_mul':
> >> ecp_nistp224.c:1105:29: warning: array subscript is above array bounds
> ...
> > In my copy of 1.0.2d, line 1105 of that file is in select_point(),
> > not batch_mul().  Are you sure you're compiling the right code?
>
> Yes, and you're right about the function--weird, but maybe Matt's
> e-mail points out the real problem.

That surely means that you're compiling some patched version or
not even 1.0.2d.

--
        Viktor.
_______________________________________________
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Warnings Compiling openssl 1.0.2d

Tom Browder
On Thu, Jul 9, 2015 at 12:00 PM, Viktor Dukhovni
<[hidden email]> wrote:
> On Thu, Jul 09, 2015 at 11:50:25AM -0500, Tom Browder wrote:
>> On Thu, Jul 9, 2015 at 10:22 AM, Viktor Dukhovni
>> <[hidden email]> wrote:
>> > On Thu, Jul 09, 2015 at 09:47:00AM -0500, Tom Browder wrote:
>> Yes, and you're right about the function--weird, but maybe Matt's
>> e-mail points out the real problem.
>
> That surely means that you're compiling some patched version or
> not even 1.0.2d.

No, it's the correct version.

But just now, after building gcc-5.2.0 and using it to rebuild
openssl, all the warnings went away just as Matt said (although the
jobserver doesn't work for some reason).

Best regards,

-Tom
_______________________________________________
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Warnings Compiling openssl 1.0.2d

Tom Browder
On Sun, Jul 19, 2015 at 11:00 AM, Tom Browder <[hidden email]> wrote:
> On Thu, Jul 9, 2015 at 12:00 PM, Viktor Dukhovni
>> That surely means that you're compiling some patched version or
>> not even 1.0.2d.
>
> No, it's the correct version.
>
> But just now, after building gcc-5.2.0 and using it to rebuild
> openssl, all the warnings went away just as Matt said (although the
> jobserver doesn't work for some reason).

I lied.  After rebuilding gcc 5.2.0 and rechecking I get the following
warnings from building 1.0.2d:

ec_key.c: In function 'EC_KEY_set_public_key_affine_coordinates':
ec_key.c:369:26: warning: variable 'is_char_two' set but not used
[-Wunused-but-set-variable]
     int ok = 0, tmp_nid, is_char_two = 0;
                          ^
d1_both.c: In function 'dtls1_retransmit_message':
d1_both.c:1261:9: warning: 'save_write_sequence' may be used
uninitialized in this function [-Wmaybe-uninitialized]
         memcpy(s->s3->write_sequence, save_write_sequence,
         ^

Best,

-Tom
_______________________________________________
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Warnings Compiling openssl 1.0.2d

Matt Caswell-2


On 21/07/15 15:33, Tom Browder wrote:

> On Sun, Jul 19, 2015 at 11:00 AM, Tom Browder <[hidden email]> wrote:
>> On Thu, Jul 9, 2015 at 12:00 PM, Viktor Dukhovni
>>> That surely means that you're compiling some patched version or
>>> not even 1.0.2d.
>>
>> No, it's the correct version.
>>
>> But just now, after building gcc-5.2.0 and using it to rebuild
>> openssl, all the warnings went away just as Matt said (although the
>> jobserver doesn't work for some reason).
>
> I lied.  After rebuilding gcc 5.2.0 and rechecking I get the following
> warnings from building 1.0.2d:
>
> ec_key.c: In function 'EC_KEY_set_public_key_affine_coordinates':
> ec_key.c:369:26: warning: variable 'is_char_two' set but not used
> [-Wunused-but-set-variable]
>      int ok = 0, tmp_nid, is_char_two = 0;


Like I said in my original email this one is due to compiling with
no-ec2m. Its harmless (but should be fixed).


>                           ^
> d1_both.c: In function 'dtls1_retransmit_message':
> d1_both.c:1261:9: warning: 'save_write_sequence' may be used
> uninitialized in this function [-Wmaybe-uninitialized]
>          memcpy(s->s3->write_sequence, save_write_sequence,
>          ^

This one is entirely bogus. "save_write_sequence" is initialized on line
1241. The compiler just isn't clever enough to figure that out.

Matt

_______________________________________________
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Warnings Compiling openssl 1.0.2d

Jeffrey Walton-3
>>                           ^
>> d1_both.c: In function 'dtls1_retransmit_message':
>> d1_both.c:1261:9: warning: 'save_write_sequence' may be used
>> uninitialized in this function [-Wmaybe-uninitialized]
>>          memcpy(s->s3->write_sequence, save_write_sequence,
>>          ^
>
> This one is entirely bogus. "save_write_sequence" is initialized on line
> 1241. The compiler just isn't clever enough to figure that out.

Right. But we need to learn to work with our tools :) The other option
throws the baby out with the bath water by disabling warnings. Or, it
leaves the problem in places so thousands or millions of folks have to
look at the issue and clear it.

Just initialize it and let the optimizer do its job. It should
identify the dead store (the unneeded initialization) and optimize it
out.

Jeff
_______________________________________________
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Warnings Compiling openssl 1.0.2d

Matt Caswell-2


On 21/07/15 20:54, Jeffrey Walton wrote:

>>>                           ^
>>> d1_both.c: In function 'dtls1_retransmit_message':
>>> d1_both.c:1261:9: warning: 'save_write_sequence' may be used
>>> uninitialized in this function [-Wmaybe-uninitialized]
>>>          memcpy(s->s3->write_sequence, save_write_sequence,
>>>          ^
>>
>> This one is entirely bogus. "save_write_sequence" is initialized on line
>> 1241. The compiler just isn't clever enough to figure that out.
>
> Right. But we need to learn to work with our tools :) The other option
> throws the baby out with the bath water by disabling warnings. Or, it
> leaves the problem in places so thousands or millions of folks have to
> look at the issue and clear it.

Agree to a point. I always config with --strict-warnings to add dev team
flags (as do the rest of the dev team). Amongst other things this adds
-Werror to treat all warnings as errors, so if a warning occurs then we
know about it and squash it. However that of course only catches
warnings for the particular platforms and compiler versions that the dev
team uses. There will always be warnings that we don't see that others
do. We could spend a huge amount of time tracking all of those down for
little benefit.

Matt
_______________________________________________
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Warnings Compiling openssl 1.0.2d

Tom Browder
In reply to this post by Matt Caswell-2
On Tue, Jul 21, 2015 at 2:16 PM, Matt Caswell <[hidden email]> wrote:

> On 21/07/15 15:33, Tom Browder wrote:
>> On Sun, Jul 19, 2015 at 11:00 AM, Tom Browder <[hidden email]> wrote:
>> I lied.  After rebuilding gcc 5.2.0 and rechecking I get the following
>> warnings from building 1.0.2d:
>>
>> d1_both.c: In function 'dtls1_retransmit_message':
>> d1_both.c:1261:9: warning: 'save_write_sequence' may be used
>> uninitialized in this function [-Wmaybe-uninitialized]
>>          memcpy(s->s3->write_sequence, save_write_sequence,
>>          ^
>
> This one is entirely bogus. "save_write_sequence" is initialized on line
> 1241. The compiler just isn't clever enough to figure that out.

Um, that initialization is in an if block, so that's not guaranteed, right?

-Tom
_______________________________________________
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Warnings Compiling openssl 1.0.2d

Jeffrey Walton-3
In reply to this post by Matt Caswell-2
On Tue, Jul 21, 2015 at 4:06 PM, Matt Caswell <[hidden email]> wrote:

>
>
> On 21/07/15 20:54, Jeffrey Walton wrote:
>>>>                           ^
>>>> d1_both.c: In function 'dtls1_retransmit_message':
>>>> d1_both.c:1261:9: warning: 'save_write_sequence' may be used
>>>> uninitialized in this function [-Wmaybe-uninitialized]
>>>>          memcpy(s->s3->write_sequence, save_write_sequence,
>>>>          ^
>>>
>>> This one is entirely bogus. "save_write_sequence" is initialized on line
>>> 1241. The compiler just isn't clever enough to figure that out.
>>
>> Right. But we need to learn to work with our tools :) The other option
>> throws the baby out with the bath water by disabling warnings. Or, it
>> leaves the problem in places so thousands or millions of folks have to
>> look at the issue and clear it.
>
> Agree to a point. I always config with --strict-warnings to add dev team
> flags (as do the rest of the dev team).

This is a good point. You are saying "trust the developers, they know
what is best." I'm fine with that because they really do know what's
best. No one knows the code better.

... Then C&A creeps in. For some companies, they have to acceptance
test libraries before using them. Its a matter of governance, polices
and procedures. If an organization's bar is lower than OpenSSL's, then
everything is fine. If the bar is higher, then its a pain pint.

Folks like Rich Salz knows exactly what I am talking about and
experiences the pain points regularly. (I've worn Rich's hat and
walked in his shoes).

> We could spend a huge amount of time tracking all of those down for
> little benefit.

To play devil's advocate, To Whom? If 10,000 people each spend 15
minutes looking at (and re-analyzing) one warning, then the community
collectively lost 4,000 man hours. 2 minutes for a dev to clear the
issue once versus 4,000 man hours seems like a very good return on
investment.

And to be fair, I just cleared a similar warning in Crypto++:
https://github.com/weidai11/cryptopp/commit/d04b813e8b078e717992b86b8b6103db0bd2cec3.
I new damn well all those variables were initialized, and the problem
was with analyzer's inter-procedural analysis.

For the d04b813e8 commit, I had to analyze it to ensure it was not a
legitimate squawk. But my choices after analyzing it were: (1) spend
30 seconds on the clear-commit-push cycle; or (2) allow the community
to spend countless hours reanalyzing it, and spend countless hours
explaining the reason for the dirty compile on the mailing list
(q.v.!). I opted for (1) because it was easier on me, and
organizations don't have to worry about C&A and governance issues.

Like I said, its learning to play well with your tools :)

Jeff
_______________________________________________
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Warnings Compiling openssl 1.0.2d

Jeffrey Walton-3
In reply to this post by Tom Browder
> I'm not real current with C so I'm not in a great position to
> criticize, but can't those warnings (if there is truly no problem) be
> eliminated (at least in gcc) with a pragma?
>
Sadly, no.

GCC pragmas to manage warnings are almost useless. Its been broken for
years. See:

  * https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53431
  * https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66943

I even offered to start a bounty and pay a GCC dev to fix the "pragma
GCC diagnostic" gear (managing warnings are that important to me):

  * https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66943#c8

Jeff
_______________________________________________
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Warnings Compiling openssl 1.0.2d

Jeffrey Walton-3
In reply to this post by Tom Browder
On Tue, Jul 21, 2015 at 4:40 PM, Tom Browder <[hidden email]> wrote:

> On Tue, Jul 21, 2015 at 2:16 PM, Matt Caswell <[hidden email]> wrote:
>> On 21/07/15 15:33, Tom Browder wrote:
>>> On Sun, Jul 19, 2015 at 11:00 AM, Tom Browder <[hidden email]> wrote:
>>> I lied.  After rebuilding gcc 5.2.0 and rechecking I get the following
>>> warnings from building 1.0.2d:
>>>
>>> d1_both.c: In function 'dtls1_retransmit_message':
>>> d1_both.c:1261:9: warning: 'save_write_sequence' may be used
>>> uninitialized in this function [-Wmaybe-uninitialized]
>>>          memcpy(s->s3->write_sequence, save_write_sequence,
>>>          ^
>>
>> This one is entirely bogus. "save_write_sequence" is initialized on line
>> 1241. The compiler just isn't clever enough to figure that out.
>
> Um, that initialization is in an if block, so that's not guaranteed, right?
>
Was that a -Wmaybe-uninitialized?

A neat trick: open Configure, copy your linux-86_64 configure line,
rename it to something like linux-analyze, and then change the
compiler to ccc-analyze. ccc-analyze is LLVM's static analyzer, and it
gives you the graph of the steps that arrive at the conclusion.

Finally, run `./Configure linux-analyze`, `make` and then `make test'.
Then, copy/paste the output. You don't have to explain anything.

Jeff
_______________________________________________
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Warnings Compiling openssl 1.0.2d

Salz, Rich
If it's a simple matter of adding "=0" in the declaration, we should just fix the darn thing.

--  
Senior Architect, Akamai Technologies
IM: [hidden email] Twitter: RichSalz

_______________________________________________
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Warnings Compiling openssl 1.0.2d

Jeffrey Walton-3
On Tue, Jul 21, 2015 at 5:56 PM, Salz, Rich <[hidden email]> wrote:
> If it's a simple matter of adding "=0" in the declaration, we should just fix the darn thing.
>
You know... if OpenSSL changes its policies so that C99 is the
baseline, then you get to initialize all variables when declared.

I think its the default for many compilers from either the compiler
build or the SPEC file. So its something that's broadly already in
practice. Its a small leap to codify it.

For the stragglers, I don't think its a stretch to ask C99 in 2015.

Jeff
_______________________________________________
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Warnings Compiling openssl 1.0.2d

Salz, Rich
> For the stragglers, I don't think its a stretch to ask C99 in 2015.

We agreed to support Netware; does it have C99?  Anyone know?

_______________________________________________
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Warnings Compiling openssl 1.0.2d

Matt Caswell-2
In reply to this post by Tom Browder


On 21/07/15 21:40, Tom Browder wrote:

> On Tue, Jul 21, 2015 at 2:16 PM, Matt Caswell <[hidden email]> wrote:
>> On 21/07/15 15:33, Tom Browder wrote:
>>> On Sun, Jul 19, 2015 at 11:00 AM, Tom Browder <[hidden email]> wrote:
>>> I lied.  After rebuilding gcc 5.2.0 and rechecking I get the following
>>> warnings from building 1.0.2d:
>>>
>>> d1_both.c: In function 'dtls1_retransmit_message':
>>> d1_both.c:1261:9: warning: 'save_write_sequence' may be used
>>> uninitialized in this function [-Wmaybe-uninitialized]
>>>          memcpy(s->s3->write_sequence, save_write_sequence,
>>>          ^
>>
>> This one is entirely bogus. "save_write_sequence" is initialized on line
>> 1241. The compiler just isn't clever enough to figure that out.
>
> Um, that initialization is in an if block, so that's not guaranteed, right?

Right, the initialization is in an if block. But the use on 1261 is also
in an if block. The conditions for each of the two if blocks are
identical. So both will be executed or neither will be executed
(assuming nothing changes the state so that the conditions evaluate
differently between the first and second if - which it doesn't).

Matt

_______________________________________________
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Warnings Compiling openssl 1.0.2d

Matt Caswell-2
In reply to this post by Jeffrey Walton-3


On 21/07/15 21:44, Jeffrey Walton wrote:

> On Tue, Jul 21, 2015 at 4:06 PM, Matt Caswell <[hidden email]> wrote:
>>
>>
>> On 21/07/15 20:54, Jeffrey Walton wrote:
>>>>>                           ^
>>>>> d1_both.c: In function 'dtls1_retransmit_message':
>>>>> d1_both.c:1261:9: warning: 'save_write_sequence' may be used
>>>>> uninitialized in this function [-Wmaybe-uninitialized]
>>>>>          memcpy(s->s3->write_sequence, save_write_sequence,
>>>>>          ^
>>>>
>>>> This one is entirely bogus. "save_write_sequence" is initialized on line
>>>> 1241. The compiler just isn't clever enough to figure that out.
>>>
>>> Right. But we need to learn to work with our tools :) The other option
>>> throws the baby out with the bath water by disabling warnings. Or, it
>>> leaves the problem in places so thousands or millions of folks have to
>>> look at the issue and clear it.
>>
>> Agree to a point. I always config with --strict-warnings to add dev team
>> flags (as do the rest of the dev team).
>
> This is a good point. You are saying "trust the developers, they know
> what is best." I'm fine with that because they really do know what's
> best. No one knows the code better.
>
> ... Then C&A creeps in. For some companies, they have to acceptance
> test libraries before using them. Its a matter of governance, polices
> and procedures. If an organization's bar is lower than OpenSSL's, then
> everything is fine. If the bar is higher, then its a pain pint.
>
> Folks like Rich Salz knows exactly what I am talking about and
> experiences the pain points regularly. (I've worn Rich's hat and
> walked in his shoes).
>
>> We could spend a huge amount of time tracking all of those down for
>> little benefit.
>
> To play devil's advocate, To Whom? If 10,000 people each spend 15
> minutes looking at (and re-analyzing) one warning, then the community
> collectively lost 4,000 man hours. 2 minutes for a dev to clear the
> issue once versus 4,000 man hours seems like a very good return on
> investment.
>
> And to be fair, I just cleared a similar warning in Crypto++:
> https://github.com/weidai11/cryptopp/commit/d04b813e8b078e717992b86b8b6103db0bd2cec3.
> I new damn well all those variables were initialized, and the problem
> was with analyzer's inter-procedural analysis.
>
> For the d04b813e8 commit, I had to analyze it to ensure it was not a
> legitimate squawk. But my choices after analyzing it were: (1) spend
> 30 seconds on the clear-commit-push cycle; or (2) allow the community
> to spend countless hours reanalyzing it, and spend countless hours
> explaining the reason for the dirty compile on the mailing list
> (q.v.!). I opted for (1) because it was easier on me, and
> organizations don't have to worry about C&A and governance issues.
>
> Like I said, its learning to play well with your tools :)

Well I think what your saying is that we should play well with other
people's tools! My tools (and presumably the rest of the dev team's as
well) don't report this warning. Collectively the dev team expect a
build to work with --strict-warnings which means that there should be no
warnings reported at all for the team. That's quite a high bar to reach
because we've all got slightly different set ups, so every now and then
we encounter a problem that one person on the team gets but others
don't. No matter how high we set the bar though there is always going to
be some system somewhere that still reports a warning. We are never
going to be able to eradicate that.

I get your point about the time people spend on looking at a warning
adding up (although somehow I just don't buy the idea that 10,000 people
are going to spend 15 minutes each looking at it). I'm not arguing that
we shouldn't fix warnings when we become aware of them - particularly if
we think there is a real problem or the warning is coming from a common
tool chain. I'm just saying that pro-actively tracking them down so that
it always cleanly compiles with no warnings for everyone is not likely
to be a useful use of time (and is actually not realistic anyway).

Matt




_______________________________________________
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
12