URL: https://github.com/SSSD/sssd/pull/675
Title: #675: p11: Fix -Wmaybe-uninitialized in p11_child_openssl.c
jhrozek commented:
"""
* master: 7794caec36e7142423491d90aaade7e49b9df1c1
"""
See the full comment at
https://github.com/SSSD/sssd/pull/675#issuecomment-429994095
URL: https://github.com/SSSD/sssd/pull/675
Title: #675: p11: Fix -Wmaybe-uninitialized in p11_child_openssl.c
sumit-bose commented:
"""
ACK
"""
See the full comment at
https://github.com/SSSD/sssd/pull/675#issuecomment-429243416
___
sssd-devel
URL: https://github.com/SSSD/sssd/pull/675
Title: #675: p11: Fix -Wmaybe-uninitialized in p11_child_openssl.c
jhrozek commented:
"""
I didn't catch this, our internal Coverity instance attached to the RH update
tool did. I don't know why the other instance we use for diffs didn't catch
this,
URL: https://github.com/SSSD/sssd/pull/675
Title: #675: p11: Fix -Wmaybe-uninitialized in p11_child_openssl.c
sumit-bose commented:
"""
Hi @jhrozek,
thank you for catching this. ACK to the patch.
About s, I agree that s should only be uninitialized if there are no modules
matching the URI.
URL: https://github.com/SSSD/sssd/pull/675
Title: #675: p11: Fix -Wmaybe-uninitialized in p11_child_openssl.c
jhrozek commented:
"""
btw there is another instance of this warning about the 's' variable. Looking
at the code, I don't think it can happen that the variable will be
uninitialized,
