вт, 17 дек. 2019 г. в 00:55, Rosen Penev <ros...@gmail.com>: > On Mon, Dec 16, 2019 at 10:21 AM Илья Шипицин <chipits...@gmail.com> > wrote: > > > > > > > > пн, 16 дек. 2019 г. в 22:40, Rosen Penev <ros...@gmail.com>: > >> > >> On Mon, Dec 16, 2019 at 4:49 AM Lukas Tribus <lu...@ltri.eu> wrote: > >> > > >> > Hello Rosen, > >> > > >> > > пн, 16 дек. 2019 г. в 12:07, Rosen Penev <ros...@gmail.com>: > >> > >> > >> > >> LIBRESSL_VERSION_NUMBER evaluates to 0 under OpenSSL, making the > condition > >> > >> always true. Check for the define before checking it. > >> > > >> > I cannot find this in the openssl sources, not in master and not in > >> > the 1.1.1 branch. Please clarify where this is defined. > >> Compile with -Wundef. Missing macros evaluate to 0. > > > > > > I checked haproxy source, it does not use such compiler flag. Any reason > for introducing it ? > > > > if we want to make it first class citizen, maybe we should add it to > proper Makefile ? or to our CI ? > > > > assuming "undefined macros may ACCIDENTLY become equal to 0" scares me > You serious? This is basic C. Undefined macros always evaluate to 0. > > indeed, you're right. I checked both gcc and clang. unfortunately, I neither learned nor used that area of C preprocessor specification before.
> -Wundef only warns about it. > > > >> > >> > > >> > The SSL compatibility layer is already complex enough and needs > >> > continuous adjustments, we need to understand the reason for changes > >> > very well. Fast fixes are continually coming back to hunt us. > >> > > >> > > >> > On Mon, 16 Dec 2019 at 08:19, Илья Шипицин <chipits...@gmail.com> > wrote: > >> > > please have a look at https://github.com/haproxy/haproxy/issues/367 > (it still misses germ part, I tried things like you send, but reg-tests > fail. do you have travis-ci passed ?) > >> > > also, there's a patch already sent, Lukas Tribus promised to review > it > >> > > >> > Yeah, this one fell through the cracks. Give me a few days to catch > up. > >> > > >> > Thanks, > >> > Lukas >
