SSL_ part in macro names

[irwir]

Does it make sense to keep SSL_ part in macro names if there is already MBEDTLS_ prefix?

mbedtls/include/mbedtls/mbedtls_config.h

Line 312 in 08909c9

#define MBEDTLS_SSL_ALL_ALERT_MESSAGES

This TLS 1.3 feature was not expected to be a part of SSL.

mbedtls/include/mbedtls/mbedtls_config.h

Line 576 in 08909c9

#define MBEDTLS_SSL_TLS1_3_KEY_EXCHANGE_MODE_PSK_ENABLED

A few names could be made shorter by avoiding tautological repetitions, and now it is a rare time for such changes - next major version release might be quite far away.

[yanesca]

It might seem redundant, but it serves a purpose. MBEDTLS_ is prefix for the Mbed TLS project which includes 3 libraries: libmbedcrypto, libmbedtls and libmbedx509. The SSL_ prefix identifies the library.

(In 4.0 there will only be libmbedtls and libmbedx509, but that is still two libraries and it justifies a prefix for each.)

[irwir]

Interesting.
Consistent naming usually is a hard target; even more so for code with longer history.

[irwir]

(In 4.0 there will only be libmbedtls and libmbedx509, but that is still two libraries and it justifies a prefix for each.)

Trying to minimize things, MBEDTLS_ and MBEDTLS_X509 could be guessed.
Should MBEDTLS_ASN1_PARSE_C become MBEDTLS_X509_ASN1_PARSE_C?

[yanesca]

Trying to minimize things, MBEDTLS_ and MBEDTLS_X509 could be guessed.

We normally try to minimize the thought that the reader has to put in understanding the code. I agree, that length can be at odds with that goal, but I don't feel that we are there yet in this case.

Should MBEDTLS_ASN1_PARSE_C become MBEDTLS_X509_ASN1_PARSE_C?

4.0 won't have it's own MBEDTLS_ASN1_PARSE_C, it will be pulled in from TF-PSA-Crypto as part of the submodule.

[irwir]

I agree, that length can be at odds with that goal, but I don't feel that we are there yet in this case.

Macro MBEDTLS_SSL_TLS1_3_KEY_EXCHANGE_MODE_PSK_EPHEMERAL_ENABLED has 58 characters in 10 parts (words) - not too short phrase taking most of an 80-characters line.
It very well could be already "there".

[yanesca]

That is indeed very long. A mitigating factor is that our new coding standard allows 100 characters, but still, I see your point.