On 24/03/2016 17:55, Sands, Daniel wrote:
On Thu, 2016-03-24 at 01:08 -0400, Jeffrey Walton wrote:
I see
some stuff going on that's not allowed in C++, but its dodgy in C. For
example:
crypto/asn1/asn_mime.c: In function ‘ASN1_VALUE* SMIME_read_ASN1(BIO*,
BIO**, const ASN1_ITEM*)’:
crypto/asn1/asn_mime.c:432:53: warning: deprecated conversion from
string constant to ‘char*’ [-Wwrite-strings]
if ((hdr = mime_hdr_find(headers, "content-type")) == NULL
^
In the absence of a compensating control to catch these kinds of
mistakes, maybe the project should consider a modern C++ compiler as a
quality gate.
Just a note about this particular issue: It's not unique to C++.
Even the C standard proscribes use of character string constants as
char*'s.
That's not correct. In C string literals are static arrays of items of
type char, so char* is appropriate to access them. They have the added
ugly restriction that attempting to modify them results in undefined
behaviour, which does not exactly match their type. They were not
defined as arrays of const char to be more easily compatible with
pre-existing library APIs.
And with the appropriate -W's, even gcc will warn you about such use.
Just in case you're code might be using them to modify the literal.
With another -W that I can't be bothered to look up at the moment, it
will even warn you that explicit casts from const x to x are taboo,
since your constant may be optimized in a way that conflicts with your
attempted use.
--
J. J. Farrell
Not speaking for Oracle
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
