Glad you were able to get to the bottom of the crash. With the newest 5 patches, I'm still not seeing the behavior I am expecting. To make my testing and expectations hopefully more clear, I've pushed them to github (https://github.com/btalbot/dual-stack-test) From a laptop with Vagrant installed, it should be a simple process to provision a host for testing and run the test script.
What I am expecting is that OpenSSL 0.9.8 client will be able to connect to an haproxy port that is bound to both ECDSA and RSA certificates. This doesn't work for me and the connection fails the SSL handshake. I'm also expecting that a newer OpenSSL which support ECC will connect AND negotiate and use the 256 bit ECDSA certificate and not the RSA cert. My tests always show the ECC capable client still getting the RSA certificate. -Bryan On Mon, Dec 7, 2015 at 1:44 PM, Willy Tarreau <w...@1wt.eu> wrote: > On Mon, Dec 07, 2015 at 08:48:53PM +0000, Dave Zhu (yanbzhu) wrote: > > Hey Willy > > > > On 12/7/15, 3:11 PM, "Willy Tarreau" <w...@1wt.eu> wrote: > > > > > >Yep, thanks for the pointer. So indeed gcc's inline version of strncpy > > >*is* > > >bogus. strncpy() has no right to guess the destination size. > > > > > >I suspect that if you just do this it would work (prefix the array with > > >'&' > > >and use [0] : > > > > > > strncpy((char *)&s_kt->name.key[0], trash.str, i); > > > > > >Thanks, > > >Willy > > > > You would be correct in this guess :) > > > > So what零 the preference? Should I change it to use this weird version of > > strcpy, or change it to memcpy? > > I'd prefer the memcpy() anyway. Please keep your comment and add the > link to gcc's bugzilla so that nobody is tempted to change this later > for any reason, and please mention that it's the inlined version of > strncpy() which refuses to write into a char[0]. > > You have my full support if you want to add some dirty words there to > express your feelings about the compiler which dies on valid C code... > > Thanks, > Willy > >
