Re: [openssl-users] Warnings Compiling openssl 1.0.2d
On Wed, Jul 22, 2015 at 6:40 AM, Jakob Bohm jb-open...@wisemo.com wrote: On 22/07/2015 01:21, Jeffrey Walton wrote: For the stragglers, I don't think its a stretch to ask C99 in 2015. Visual Studio is often used on Windows, and it is not C99. Oh my, I was not aware it was still struggling for C99 :) I guess Microsoft is still putting their energies into the one-size, tablet interface known as Windows 8, fits all, even on desktops without a touchscreen. On the good side, MSVC does not need to be 100% compliant. It just needs to support initialization at time of declaration. That particular feature works. Isn't that a C89 (or maybe even KR) feature? I thought that was C99. I think Ben Laurie even corrected me with some OpenSSL sample code because I initialized a variable without using -std=c99. There is another problem though: Blindly initializing every variable with dummy values (because the correct value comes from one or more if() branches), only achieves two things, both bad: - It hides correct warnings in case one of those if() branches forgets to set the variable, before it is read. - It potentially confuses less-than-halting-problem- solving optimizers to needlessly generate code that allocates and initializes the variable because they cannot detect (within their compile time resource limits) that the dummy value is (hopefully) never used. The second problem is almost guaranteed to happen on any compiler/option combination that would otherwise falsely warn about the variable being maybe- uninitialized. This is because most compilers generate that warning as a side effect of the optimizer trying to figure out if the garbage or dummy value will be used by the code. What, exactly is the problem? The program is in a known state. As far as I know, that's the best state to be in. And that's why managed languages like Java and .Net are so popular. When a variable is declared, it gets placed in a known state immediately. It relieves the programmer of remembering pesky details like, remember to initialize your variables to a known state. Jeff ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Warnings Compiling openssl 1.0.2d
On 22/07/2015 01:27, Jeffrey Walton wrote: 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. Ah, OK. So its being reported in GCC 5.1 via -Wmaybe-unitialized (I suspect). That may point to an issue in OpenSSL's engineering process. There may be a gap because no one is running, say Fedora 22 or Debian 8 (I think Debian 8 provides GCC 5.1). F.Y.I. Debian 8 (Jessie) uses GCC 4.9.2 Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Warnings Compiling openssl 1.0.2d
On 22/07/2015 01:21, Jeffrey Walton wrote: For the stragglers, I don't think its a stretch to ask C99 in 2015. Visual Studio is often used on Windows, and it is not C99. Oh my, I was not aware it was still struggling for C99 :) I guess Microsoft is still putting their energies into the one-size, tablet interface known as Windows 8, fits all, even on desktops without a touchscreen. On the good side, MSVC does not need to be 100% compliant. It just needs to support initialization at time of declaration. That particular feature works. Isn't that a C89 (or maybe even KR) feature? There is another problem though: Blindly initializing every variable with dummy values (because the correct value comes from one or more if() branches), only achieves two things, both bad: - It hides correct warnings in case one of those if() branches forgets to set the variable, before it is read. - It potentially confuses less-than-halting-problem- solving optimizers to needlessly generate code that allocates and initializes the variable because they cannot detect (within their compile time resource limits) that the dummy value is (hopefully) never used. The second problem is almost guaranteed to happen on any compiler/option combination that would otherwise falsely warn about the variable being maybe- uninitialized. This is because most compilers generate that warning as a side effect of the optimizer trying to figure out if the garbage or dummy value will be used by the code. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Warnings Compiling openssl 1.0.2d
On 22/07/2015 13:14, Jeffrey Walton wrote:
On Wed, Jul 22, 2015 at 6:40 AM, Jakob Bohm jb-open...@wisemo.com wrote:
On 22/07/2015 01:21, Jeffrey Walton wrote:
For the stragglers, I don't think its a stretch to ask C99 in 2015.
Visual Studio is often used on Windows, and it is not C99.
Oh my, I was not aware it was still struggling for C99 :) I guess
Microsoft is still putting their energies into the one-size, tablet
interface known as Windows 8, fits all, even on desktops without a
touchscreen.
On the good side, MSVC does not need to be 100% compliant. It just
needs to support initialization at time of declaration. That
particular feature works.
Isn't that a C89 (or maybe even KR) feature?
I thought that was C99. I think Ben Laurie even corrected me with some
OpenSSL sample code because I initialized a variable without using
-std=c99.
There is a C99 feature backported from C++: Allow
declarations after/between statements, thus allowing
unconditional initialization formulas to be used even
if code is needed before them.
E.g.
int foo61(void)
{
int a = 1;
int b = 5;
do {
a *= b;
} while (--b);
int c = a / 2; // C99/C++ only
return c + 1;
}
There is another problem though: Blindly initializing
every variable with dummy values (because the correct
value comes from one or more if() branches), only
achieves two things, both bad:
- It hides correct warnings in case one of those if()
branches forgets to set the variable, before it is
read.
- It potentially confuses less-than-halting-problem-
solving optimizers to needlessly generate code that
allocates and initializes the variable because they
cannot detect (within their compile time resource
limits) that the dummy value is (hopefully) never
used.
The second problem is almost guaranteed to happen on
any compiler/option combination that would otherwise
falsely warn about the variable being maybe-
uninitialized. This is because most compilers
generate that warning as a side effect of the
optimizer trying to figure out if the garbage or
dummy value will be used by the code.
What, exactly is the problem? The program is in a known state. As far
as I know, that's the best state to be in.
In the first case, the program is in a wrong state,
and no tool will tell you about it. Silently producing
a wrong result is quite unpleasant.
In the second case we have inefficient code.
And if the compiler *can* detect the situation correctly,
and the code *is* correct without the extra initialization,
the compiler is likely to emit a warning that variable is
assigned a value which is never used.
So if the goal is to avoid warnings, you can't win anyway.
If as in the case under discussion, the value is set and
used only under a (common) condition, one may consider a
structural change so the condition is checked only once,
then move the variable inside that conditional block. On
pipelined processors, this may even result in faster code,
though it will be larger, this however depends on a closer
analysis of the particular code.
And that's why managed languages like Java and .Net are so popular.
When a variable is declared, it gets placed in a known state
immediately. It relieves the programmer of remembering pesky details
like, remember to initialize your variables to a known state.
But it also makes it harder to auto-detect bugs where a
variable is left in that default state when it should
have been in a different state. In fact for languages
without implicit initialization, there are often debug
tools that can set the variables to a known impossible
value and report if those values are ever used.
Typical choices include 0xBAADF00D (where 32 bit
pointers are restricted to the range 0x1000 to
0x7fff) etc.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Warnings Compiling openssl 1.0.2d
On 21/07/15 15:33, Tom Browder wrote: On Sun, Jul 19, 2015 at 11:00 AM, Tom Browder tom.brow...@gmail.com 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
Re: [openssl-users] Warnings Compiling openssl 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. 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
Re: [openssl-users] Warnings Compiling openssl 1.0.2d
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
Re: [openssl-users] Warnings Compiling openssl 1.0.2d
If it's a simple matter of adding =0 in the declaration, we should just fix the darn thing. -- Senior Architect, Akamai Technologies IM: richs...@jabber.at Twitter: RichSalz ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Warnings Compiling openssl 1.0.2d
On Tue, Jul 21, 2015 at 4:06 PM, Matt Caswell m...@openssl.org 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 CA 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 CA 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
Re: [openssl-users] Warnings Compiling openssl 1.0.2d
On Tue, Jul 21, 2015 at 4:40 PM, Tom Browder tom.brow...@gmail.com wrote: On Tue, Jul 21, 2015 at 2:16 PM, Matt Caswell m...@openssl.org wrote: On 21/07/15 15:33, Tom Browder wrote: On Sun, Jul 19, 2015 at 11:00 AM, Tom Browder tom.brow...@gmail.com 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
Re: [openssl-users] Warnings Compiling openssl 1.0.2d
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
Re: [openssl-users] Warnings Compiling openssl 1.0.2d
From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of Kaduk, Ben Sent: Tuesday, July 21, 2015 17:06 On 7/21/15, 17:37, Ken Goldman kgold...@us.ibm.com wrote: On 7/21/2015 6:20 PM, Jeffrey Walton wrote: For the stragglers, I don't think its a stretch to ask C99 in 2015. If only. Visual Studio is often used on Windows, and it is not C99. It is getting closer, though: http://blogs.msdn.com/b/vcblog/archive/2013/06/28/c-11-14-stl-features- fixe s-and-breaking-changes-in-vs-2013.aspx discusses the addition of several useful C99 features in VS2013, including compound literals, designated initializers, and variable declarations. Still no sign of a conforming snprintf, though. MSVC isn't even really a conforming hosted-environment C90. It's debatable whether it can be called C at all. -- Michael Wojcik Technology Specialist, Micro Focus ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Warnings Compiling openssl 1.0.2d
On Tue, Jul 21, 2015 at 5:56 PM, Salz, Rich rs...@akamai.com 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
Re: [openssl-users] Warnings Compiling openssl 1.0.2d
On 21/07/15 21:44, Jeffrey Walton wrote: On Tue, Jul 21, 2015 at 4:06 PM, Matt Caswell m...@openssl.org 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 CA 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 CA 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
Re: [openssl-users] Warnings Compiling openssl 1.0.2d
On 7/21/2015 6:20 PM, Jeffrey Walton wrote: For the stragglers, I don't think its a stretch to ask C99 in 2015. Visual Studio is often used on Windows, and it is not C99. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Warnings Compiling openssl 1.0.2d
For the stragglers, I don't think its a stretch to ask C99 in 2015. Visual Studio is often used on Windows, and it is not C99. Oh my, I was not aware it was still struggling for C99 :) I guess Microsoft is still putting their energies into the one-size, tablet interface known as Windows 8, fits all, even on desktops without a touchscreen. On the good side, MSVC does not need to be 100% compliant. It just needs to support initialization at time of declaration. That particular feature works. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Warnings Compiling openssl 1.0.2d
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
Re: [openssl-users] Warnings Compiling openssl 1.0.2d
On 21/07/15 21:40, Tom Browder wrote: On Tue, Jul 21, 2015 at 2:16 PM, Matt Caswell m...@openssl.org wrote: On 21/07/15 15:33, Tom Browder wrote: On Sun, Jul 19, 2015 at 11:00 AM, Tom Browder tom.brow...@gmail.com 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
Re: [openssl-users] Warnings Compiling openssl 1.0.2d
It may be correct in this case, but simple matter of can sometimes mask a real problem. If the function expected the value to be set earlier, but the analysis tool finds a path where it's not set, there could be a more real bug. Is zero the right value? Why not, 1, -1, or 42? =0 may be perfectly good in this case. But beware of quick code fixes to silence compiler warnings. On 7/21/2015 5:56 PM, Salz, Rich wrote: If it's a simple matter of adding =0 in the declaration, we should just fix the darn thing. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Warnings Compiling openssl 1.0.2d
On 7/21/15, 17:37, Ken Goldman kgold...@us.ibm.com wrote: On 7/21/2015 6:20 PM, Jeffrey Walton wrote: For the stragglers, I don't think its a stretch to ask C99 in 2015. Visual Studio is often used on Windows, and it is not C99. It is getting closer, though: http://blogs.msdn.com/b/vcblog/archive/2013/06/28/c-11-14-stl-features-fixe s-and-breaking-changes-in-vs-2013.aspx discusses the addition of several useful C99 features in VS2013, including compound literals, designated initializers, and variable declarations. -Ben Kaduk ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Warnings Compiling openssl 1.0.2d
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. Ah, OK. So its being reported in GCC 5.1 via -Wmaybe-unitialized (I suspect). That may point to an issue in OpenSSL's engineering process. There may be a gap because no one is running, say Fedora 22 or Debian 8 (I think Debian 8 provides GCC 5.1). Can you confirm the test platform is in-place and being utilized? Jeff ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Warnings Compiling openssl 1.0.2d
On Sun, Jul 19, 2015 at 11:00 AM, Tom Browder tom.brow...@gmail.com 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
Re: [openssl-users] Warnings Compiling openssl 1.0.2d
On Thu, Jul 9, 2015 at 12:00 PM, Viktor Dukhovni openssl-us...@dukhovni.org 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 openssl-us...@dukhovni.org 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
Re: [openssl-users] Warnings Compiling openssl 1.0.2d
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
Re: [openssl-users] Warnings Compiling openssl 1.0.2d
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
[openssl-users] Warnings Compiling openssl 1.0.2d
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
Re: [openssl-users] Warnings Compiling openssl 1.0.2d
On Thu, Jul 9, 2015 at 10:25 AM, Matt Caswell m...@openssl.org 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
Re: [openssl-users] Warnings Compiling openssl 1.0.2d
On Thu, Jul 9, 2015 at 10:22 AM, Viktor Dukhovni openssl-us...@dukhovni.org 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
Re: [openssl-users] Warnings Compiling openssl 1.0.2d
On Thu, Jul 09, 2015 at 11:50:25AM -0500, Tom Browder wrote: On Thu, Jul 9, 2015 at 10:22 AM, Viktor Dukhovni openssl-us...@dukhovni.org 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
