openssl: OPENSSL_VERSION_TEXT no longer a proper string

For as long as anyone cares to remember, the OPENSSL_VERSION_TEXT macro has been defined as a single string:

    #define OPENSSL_VERSION_TEXT    "OpenSSL 1.1.1  11 Sep 2018"

From 3.0.0, this is redefined as four separate elements:

    #define OPENSSL_VERSION_TEXT        \
        "OpenSSL " OPENSSL_FULL_VERSION_STR " " OPENSSL_RELEASE_DATE

This introduces compilation errors if OPENSSL_VERSION_TEXT is used in a context where a single string is expected.

Attempting to coerse OPENSSL_VERSION_TEXT into a single string using OPENSSL_MSTR produces a result with embedded "s resulting from premature evaluation.

    \"OpenSSL \"\"3\" \".\"\"0\" \".\"\"0\"\"-dev\"\"\" \" \"\"xx XXX xxxx\"

The following code produces something close to the pre-3.0.0 OPENSSL_VERSION_TEXT:

    #define OPENSSL_VERSION_PRE_RELEASE     -dev            /* NOT within quotes */
    #define OPENSSL_RELEASE_DATE    xx XXX xxxx             /* NOT within quotes */
    #undef OPENSSL_BUILD_METADATA                           /* NOT within quotes */

    #ifdef OPENSSL_VERSION_PRE_RELEASE
    # define _OPENSSL_PRE_RELEASE   OPENSSL_VERSION_PRE_RELEASE
    #else
    # define _OPENSSL_PRE_RELEASE
    #endif

    #ifdef OPENSSL_BUILD_METADATA
    # define _OPENSSL_BUILD_METADATA        OPENSSL_BUILD_METADATA
    #else
    # define _OPENSSL_BUILD_METADATA
    #endif

    #define _SPACE  _

    #define OPENSSL_VERSION_TEXT    OPENSSL_MSTR( OpenSSL _SPACE    \
            OPENSSL_VERSION_MAJOR.OPENSSL_VERSION_MINOR.OPENSSL_VERSION_PATCH       \
            _OPENSSL_PRE_RELEASE _OPENSSL_BUILD_METADATA _SPACE OPENSSL_RELEASE_DATE )

Devising a satisfactory definition of the _SPACE macro (inserting white space) is left as an exercise for the student.

About this issue

Original URL
State: closed
Created 5 years ago
Comments: 16 (13 by maintainers)

Most upvoted comments

I will echo the sentiment by asking: why is it important for that macro to end up being a single string in cpp?

If we have an understanding, I’m not saying we will change its current nature, but might be able to advise better mechanisms to do what you’re trying to do.

(unless this is just an academic discussion, in which case I personally find it moot, and reason for closing this issue immediately)

levitte on Aug 6, 2019

I’m still confused about the actual practical impact/complaint here.

This introduces compilation errors if OPENSSL_VERSION_TEXT is used in a context where a single string is expected.

is just a conditional statement without any evidence that the condition is ever met in practice.

To phrase it differently, there are a lot of places in openssl where people have assumed that historical behavior would continue into the future, even when that was a bad idea and caused problems for both the maintainers and the consumers making those assumptions. (Consider the move to opaque structures as a move out of such a situation.) Why should this particular historical behavior be promoted to an invariant?

kaduk on Aug 6, 2019

OpenSSL moved away from using define’s in include statements; this was done when #9204 was merged and I am sure that the team doesn’t want to go back there. 😃

It seems that you are trying to use version-dependent headers in your application, but you never clearly answered the question at https://github.com/openssl/openssl/issues/9489#issuecomment-516720522.

The macro OPENSSL_VERSION_STRING continues to remain a valid C string. It was never intended to be a pre-processor string, if that is what you are trying to do.

richsalz on Aug 6, 2019