A note on this effort re pointer declarations:

WebKit style makes a difference between C and C++: https://webkit.org/code-style-guidelines/#pointers-non-cpp

clang-format, if not told otherwise, will assume C++ over C, and that's the reason we get all those * moved flush to the type instead of flush to the variable.

I've tried adding Language: C to .clang-format, but my clang-format (version 19.1.7) doesn't accept it, in spite of documentation saying it should. The fallback is to add PointerAlignment: Right.

I tried that on one file on top of this PR, here's the diff:

diff --git a/.clang-format b/.clang-format
index 2413d23d1d..a668fac4dd 100644
--- a/.clang-format
+++ b/.clang-format
@@ -4,6 +4,9 @@ BasedOnStyle: WebKit
 #
 # OpenSSL Customizations start here.
 #
+# It's important to specify the main language (hmm, "C" unknown???)
+#Language: C
+PointerAlignment: Right
 # we add matches for /** and /*- at the top
 # of a comment block to protect comments as
 # per STYLE.md
diff --git a/apps/asn1parse.c b/apps/asn1parse.c
index c277b36ba3..fbd9d7c334 100644
--- a/apps/asn1parse.c
+++ b/apps/asn1parse.c
@@ -67,26 +67,26 @@ const OPTIONS asn1parse_options[] = {
     { NULL }
 };
 
-static int do_generate(char* genstr, const char* genconf, BUF_MEM* buf);
+static int do_generate(char *genstr, const char *genconf, BUF_MEM *buf);
 
-int asn1parse_main(int argc, char** argv)
+int asn1parse_main(int argc, char **argv)
 {
-    ASN1_TYPE* at = NULL;
+    ASN1_TYPE *at = NULL;
     BIO *in = NULL, *b64 = NULL, *derout = NULL;
-    BUF_MEM* buf = NULL;
-    STACK_OF(OPENSSL_STRING)* osk = NULL;
+    BUF_MEM *buf = NULL;
+    STACK_OF(OPENSSL_STRING) *osk = NULL;
     char *genstr = NULL, *genconf = NULL;
     char *infile = NULL, *oidfile = NULL, *derfile = NULL;
-    unsigned char* str = NULL;
+    unsigned char *str = NULL;
     char *name = NULL, *header = NULL, *prog;
-    const unsigned char* ctmpbuf;
+    const unsigned char *ctmpbuf;
     int indent = 0, noout = 0, dump = 0, informat = FORMAT_PEM;
     int offset = 0, ret = 1, i, j;
     long num, tmplen;
-    unsigned char* tmpbuf;
+    unsigned char *tmpbuf;
     unsigned int length = 0;
     OPTION_CHOICE o;
-    const ASN1_ITEM* it = NULL;
+    const ASN1_ITEM *it = NULL;
 
     prog = opt_init(argc, argv, asn1parse_options);
 
@@ -196,7 +196,7 @@ int asn1parse_main(int argc, char** argv)
             ERR_print_errors(bio_err);
             goto end;
         }
-        buf->data = (char*)str;
+        buf->data = (char *)str;
         buf->length = buf->max = num;
     } else {
         if (!BUF_MEM_grow(buf, BUFSIZ * 8))
@@ -211,7 +211,7 @@ int asn1parse_main(int argc, char** argv)
         } else {
 
             if (informat == FORMAT_BASE64) {
-                BIO* tmp;
+                BIO *tmp;
 
                 if ((b64 = BIO_new(BIO_f_base64())) == NULL)
                     goto end;
@@ -234,7 +234,7 @@ int asn1parse_main(int argc, char** argv)
                 num += i;
             }
         }
-        str = (unsigned char*)buf->data;
+        str = (unsigned char *)buf->data;
     }
 
     /* If any structs to parse go through in sequence */
@@ -243,7 +243,7 @@ int asn1parse_main(int argc, char** argv)
         tmpbuf = str;
         tmplen = num;
         for (i = 0; i < sk_OPENSSL_STRING_num(osk); i++) {
-            ASN1_TYPE* atmp;
+            ASN1_TYPE *atmp;
             int typ;
             j = strtol(sk_OPENSSL_STRING_value(osk, i), NULL, 0);
             if (j <= 0 || j >= tmplen) {
@@ -295,10 +295,10 @@ int asn1parse_main(int argc, char** argv)
         }
     }
     if (!noout) {
-        const unsigned char* p = str + offset;
+        const unsigned char *p = str + offset;
 
         if (it != NULL) {
-            ASN1_VALUE* value = ASN1_item_d2i(NULL, &p, length, it);
+            ASN1_VALUE *value = ASN1_item_d2i(NULL, &p, length, it);
             if (value == NULL) {
                 BIO_printf(bio_err, "Error parsing item %s\n", it->sname);
                 ERR_print_errors(bio_err);
@@ -328,12 +328,12 @@ end:
     return ret;
 }
 
-static int do_generate(char* genstr, const char* genconf, BUF_MEM* buf)
+static int do_generate(char *genstr, const char *genconf, BUF_MEM *buf)
 {
-    CONF* cnf = NULL;
+    CONF *cnf = NULL;
     int len;
-    unsigned char* p;
-    ASN1_TYPE* atyp = NULL;
+    unsigned char *p;
+    ASN1_TYPE *atyp = NULL;
 
     if (genconf != NULL) {
         if ((cnf = app_load_config(genconf)) == NULL)
@@ -361,7 +361,7 @@ static int do_generate(char* genstr, const char* genconf, BUF_MEM* buf)
     if (!BUF_MEM_grow(buf, len))
         goto err;
 
-    p = (unsigned char*)buf->data;
+    p = (unsigned char *)buf->data;
 
     i2d_ASN1_TYPE(atyp, &p);
 

I checked through the rest of the WebKit code style guidelines. The pointer style was the only significant language-specific thing I could find.

@bob-beck, you might want to consider corrections for when clang-format makes the wrong choice based on assumed language (see my commentary above on that).

Yes, it defaults to Cpp for everything "unknown"

this is the same thing, we've just added the pointer alignment to actually do the WebKit C style instead of C++

…
On Thu, Oct 2, 2025 at 8:37 AM Richard Levitte @.> wrote: levitte left a comment (openssl/openssl#28691) <#28691 (comment)> @bob-beck https://github.com/bob-beck, you might want to consider corrections for when clang-format makes the wrong choice based on assumed language (see my commentary above on that). — Reply to this email directly, view it on GitHub <#28691 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB57M5N77DW3EOKDGUJAUPD3VU2C7AVCNFSM6AAAAACHZ4IUIKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTGNRRGUYTCMBVGU . You are receiving this because you were mentioned.Message ID: @.>

I did a quick write-up of stuff that I found makes our code less readable, about a month ago, see https://openssl-communities.org/d/PyEH0sRW/your-thoughts-wanted-openssl-source-code-reformat/11

I now wonder if what transpired in that discussion ever made it back to @bob-beck

In short, the webkit format has a few shortcommings, two of them being about wanting to flush everything on a line together, example:

 struct ossl_param_st {
-    const char *key;             /* the name of the parameter */
-    unsigned int data_type;      /* declare what kind of content is in buffer */
-    void *data;                  /* value being passed in or out */
-    size_t data_size;            /* data size */
-    size_t return_size;          /* returned content size */
+    const char *key; /* the name of the parameter */
+    unsigned int data_type; /* declare what kind of content is in buffer */
+    void *data; /* value being passed in or out */
+    size_t data_size; /* data size */
+    size_t return_size; /* returned content size */
 };

The other thing is losing the indentation of pre-processor directives... considering that how pre-processor heavy OpenSSL is, the result of losing the indentation is a mess that's very hard to follow when you look. Of course, those could be refactored, but as far as I can tell, we're not there.

So here's a wishlist of tweaks that I'd like to see to not uglify the code too much:

# Leave trailing comments alone, flushing them against the statement
# makes things harder to read
AlignTrailingComments:
    Kind: Leave
# Indent pre-processor directives after the hash symbol.  OpenSSL pre-processor use is
# quite complex, indentation makes it a bit easier to see what's what.
IndentPPDirectives: AfterHash
# We might also want to consider if we want to preserve the current one-space indentation
# for preprocessor directives (clang-format directive: PPIndentWidth: 1) or if we want to
# make it fallback to IdentWidth (PPIndentWidth: -1, which is what the webkit config defaults
# to anyway).

I'm pondering strongly not consenting to a .clang-format without those directives.

I did a quick write-up of stuff that I found makes our code less readable, about a month ago, see https://openssl-communities.org/d/PyEH0sRW/your-thoughts-wanted-openssl-source-code-reformat/11

I now wonder if what transpired in that discussion ever made it back to @bob-beck

In short, the webkit format has a few shortcommings, two of them being about wanting to flush everything on a line together, example:

 struct ossl_param_st {
-    const char *key;             /* the name of the parameter */
-    unsigned int data_type;      /* declare what kind of content is in buffer */
-    void *data;                  /* value being passed in or out */
-    size_t data_size;            /* data size */
-    size_t return_size;          /* returned content size */
+    const char *key; /* the name of the parameter */
+    unsigned int data_type; /* declare what kind of content is in buffer */
+    void *data; /* value being passed in or out */
+    size_t data_size; /* data size */
+    size_t return_size; /* returned content size */
 };

The other thing is losing the indentation of pre-processor directives... considering that how pre-processor heavy OpenSSL is, the result of losing the indentation is a mess that's very hard to follow when you look. Of course, those could be refactored, but as far as I can tell, we're not there.

So here's a wishlist of tweaks that I'd like to see to not uglify the code too much:

# Leave trailing comments alone, flushing them against the statement
# makes things harder to read
AlignTrailingComments:
    Kind: Leave
# Indent pre-processor directives after the hash symbol.  OpenSSL pre-processor use is
# quite complex, indentation makes it a bit easier to see what's what.
IndentPPDirectives: AfterHash
# We might also want to consider if we want to preserve the current one-space indentation
# for preprocessor directives (clang-format directive: PPIndentWidth: 1) or if we want to
# make it fallback to IdentWidth (PPIndentWidth: -1, which is what the webkit config defaults
# to anyway).

I'm pondering strongly not consenting to a .clang-format without those directives.

No I was not aware of this. This PR would have been the place to discuss it, as your other issue with C was also dealt with here.

Trailing comment allgnment...

Personally I do like the aligned versions better, however, int the interest of not being different
from the normally documented webkit style, I can live with it.

WebKit is explicit that it should be one space:

Use only one space before end of line comments and in between sentences in comments

Given that it is explict about it and we were clear we did not want to invent our own thing here, this will
not be what other tooling will expect to do when we are doing webkit style. (This is unlike the pointer
alignment issue from before where WebKit does specify Pointer Alignment right for C (not for C++))

Preprocessor Directive indentation...

Changing this I almost personally dislike, but for the opposite reason, I find the indented preprocessor blocks
harder to read than the unindented ones, especially if the unintended ones have comments on the #end lines.
My personal two cents is this style encourages complicated preprocessor use without things like comments at the end of #endif blocks to indicate what it is intended to match which I think should be discouraged.

Nevertheless whatever the default WebKit setting was, again, I'd be willing to live with it.

I have heard comments from people who are glad this change removes the preprocessor indentation, so I think this is again a matter of personal taste, and not a universally liked thing.

Nevertheless, aside from sorted #includes (which we are not going to tackle just yet) WebKit style itself is
silent on this subject. So presumably going with whatever setting is not contrary to anything the WebKit style itself says.

I'm all in for this .clang-format tweak

# Leave trailing comments alone, flushing them against the statement
# makes things harder to read
AlignTrailingComments:
    Kind: Leave

I actually prefer to drop the indentation for preprocessor directives.

so I'm with @bob-beck on this.

I think we should be able to reason around the strictness of complying with the base style. That's what I voted for, to base what we come up with on webkit, but I never thought that would become some sort of purist thing.

I'd argue that since we're now three who would prefer to leave trailing comments aligned, and the style remains mainly webkit, I really don't see that as a bad thing.

I concur

I think we should be able to reason around the strictness of complying with the base style. That's what I voted for, to base what we come up with on webkit, but I never thought that would become some sort of purist thing.

I'd argue that since we're now three who would prefer to leave trailing comments aligned, and the style remains mainly webkit, I really don't see that as a bad thing.

Well, I've at least been clear all along for a preference of sticking to something established:
Such as here, in the presentation before we voted

As well as in numerous discussions, so perhaps you missed this.

I know @tjh has also expressed the desire to stick to a standard format and not invent our own on a number of occasions.

So I believe people have been well informed that we do not want to do significant deviations from a standard format.

While I'm not super "purist" about it, I want other tools that are aware of the format to work, and not go "oh it's webkit but not webkit."

I'm all in for this .clang-format tweak

# Leave trailing comments alone, flushing them against the statement
# makes things harder to read
AlignTrailingComments:
    Kind: Leave

I'm very much not in favour of "Leave" , unless that is what we really mean. I.E. We do not care, and whatever I do with trailing comments if it passes clang-format, it's ok stylistically. (i.e. specifically, nits about "please change the trailing comments to line up differently" can be ignored and closed)

I suspect what you mean here is not the webkit style, and not "Leave" but rather to force alignment.

I would be perfectly OK with forced alignment.

In our previous reformat, we had trailing comments aligned at column 33. I'm not particularly attached to that specific column, that's just to show that we did have an idea of enforcing a specific alignment.

# Leave trailing comments alone, flushing them against the statement
# makes things harder to read
AlignTrailingComments:
    Kind: Leave

ok so I took a closer look to what I want here. This is the sample.c file I was using to convey my tests:

typedef struct sample {
        int x;                          /* this is horizontal axis */
        int y_axis_is_important;        /* this is vertical axis */
} sample_t;

in sample above comments are separated by tabs. this is clang-format does when running with .clang-format as found in this PR

typedef struct sample {
    int x; /* this is horizontal axis */
    int y_axis_is_important; /* this is vertical axis */
} sample_t;

This is what I get if I apply diff to .clang-format

--- .clang-format       Tue Dec  2 13:46:22 2025
+++ clang-format-always Tue Dec  2 13:51:29 2025
@@ -292,5 +292,9 @@
 #    Priority:        6
 #    SortPriority:    0
 #    CaseSensitive:   false
+# Leave trailing comments alone, flushing them against the statement
+# makes things harder to read
+AlignTrailingComments:
+    Kind: Leave
...

the resulting sample.c reads as follows:

lifty$ clang-format  sample.c                      
typedef struct sample {
    int x;    /* this is horizontal axis */
    int y_axis_is_important; /* this is vertical axis */
} sample_t;

And this is what I get for .clang-format with this diff applied:

--- .clang-format       Tue Dec  2 13:46:22 2025
+++ clang-format-always Tue Dec  2 13:51:29 2025
@@ -292,5 +292,9 @@
 #    Priority:        6
 #    SortPriority:    0
 #    CaseSensitive:   false
+# Leave trailing comments alone, flushing them against the statement
+# makes things harder to read
+AlignTrailingComments:
+    Kind: Always

With Kind: Always the sample.c looks as follows:

typedef struct sample {
    int x;                   /* this is horizontal axis */
    int y_axis_is_important; /* this is vertical axis */
} sample_t;

so Always seems to be what I prefer here.

That Leave result was... interesting. So it seems that Always is a good option, then. My read of https://clang.llvm.org/docs/ClangFormatStyleOptions.html#aligntrailingcomments says that we might want to consider OverEmptyLines, but I'm not particularly concerned for the moment

Although I first disliked it I think I can live with both removing indentation on preprocessor directives and removing the comment alignment. I am afraid AlignTrailingComments: ... Always will possibly break some other things. and although the preprocessor directive alignment that we do is somewhat nice, @bob-beck 's arguments are valid - it is much better to use comments to refer to the corresponding #if rather than alignment.

What I really hate about the reformat is the removal of alignment of function call arguments on split lines. I did not find anything about that on the Webkit style guide. Can we please please consider keeping this? It makes the code much more readable.

Regarding preprocessor directives, I've already given in, 'cause indentation is inconsistent anyway seen over a whole file. What clang-format documentation isn't quite clear about is that it only considers consecutive preprocessor directives. A line that isn't a preprocessor directive resets the preprocessor indentation "state", so to say.
(I actually find clang-format to be a pretty rotten indent in this case. utterly useless)

As for webkit and continuation of function parameters, @t8m, they do start with saying that the indent size is 4 spaces, and follow that with cases that are the exception. Since they don't say anything specific about function continuation, then the indent size is... 4 spaces.
If you look carefully, though, you can see an example that shows this, here

giving it another thought here. like sticking to vanilla webkit also makes sort of sense because people just see a webkit and can apply style configuration changes to their editor/ide saying use webkit style without further tweaks. and my vim uses dark blue color for comments, so the indentation is actually less important.

Yeah that's how it looks like when tools are put before the people reading the code. But yeah well, I already gave up on that matter so I am not blocking this.

giving it another thought here. like sticking to vanilla webkit also makes sort of sense because people just see a webkit and can apply style configuration changes to their editor/ide saying use webkit style without further tweaks. and my vim uses dark blue color for comments, so the indentation is actually less important.

So you rely on a christmas tree style to say what's what. Me, with a popular red-green impairment, find issue with a majority of them, and would rather go with monochrome, which is a bit more limited in the color space.
(and I'll stop there for now... just know that I have a collection of rants on the topic in the pipeline, just a valve to open...)

I know @tjh has also expressed the desire to stick to a standard format and not invent our own on a number of occasions.

It is all personal preference in terms of a choice of a style - and we need to simply accept that grabbing a small subset of people and creating our own unique set of things - a set which basically we never actually agree on completely - and is not a consensus - and then forcing something unique and unusual on our users does our community a disservice.

There is nothing inherently different about the OpenSSL Library that requires a different choice.

We went into this discussion all with the explicit understanding that we were picking between a set of common styles and we were not going to basically argue out each setting to tweak things around personal preferences.

There are things in every one of the styles we looked that would not be my choice in terms of a style to use - but the objective is to simply go with a commonly used and recognised style and to stop treating this as as area to diverge. There are many more important things we should be focused on about the actual code itself rather than formatting tweaks.

The decision we made (which in itself was a compromise) was vanilla webkit and @bob-beck has done his work on that basis.

All the feedback in this PR should be on the basis of has Bob messed it up and not on suggesting additional tweaks that conflict with the vanilla webkit decision which was clearly made.

What I really hate about the reformat is the removal of alignment of function call arguments on split lines. I did not find anything about that on the Webkit style guide. Can we please please consider keeping this? It makes the code much more readable.

I concur that.

So you rely on a christmas tree style to say what's what. Me, with a popular red-green impairment, find issue with a majority of them, and would rather go with monochrome, which is a bit more limited in the color space. (and I'll stop there for now... just know that I have a collection of rants on the topic in the pipeline, just a valve to open...)

I keep forgetting that not everybody can read this. From that perspective the deviation from webkit style is justified. The drawback of this tweak is the clang-format may exceed the line length as can be seen on the diff here:

diff --git a/test/tls13groupselection_test.c b/test/tls13groupselection_test.c
index 8f44e0c453..54e094464f 100644
--- a/test/tls13groupselection_test.c
+++ b/test/tls13groupselection_test.c
@@ -324,9 +324,9 @@ static void server_response_check_cb(int write_p, int version,
         0x07, 0x9E, 0x09, 0xE2, 0xC8, 0xA8, 0x33, 0x9C };
 
     /* Did a server hello arrive? */
-    if (write_p == 0 &&                                /* Incoming data... */
-        content_type == SSL3_RT_HANDSHAKE &&           /* carrying a handshake record type ... */
-        version == TLS1_3_VERSION &&                   /* for TLSv1.3 ... */
+    if (write_p == 0 && /* Incoming data... */
+        content_type == SSL3_RT_HANDSHAKE && /* carrying a handshake record type ... */
+        version == TLS1_3_VERSION && /* for TLSv1.3 ... */
         ((uint8_t *)buf)[0] == SSL3_MT_SERVER_HELLO) { /* with message type "ServerHello" */
         /* Check what it is: SH or HRR (compare the 'random' data field with HRR magic number) */
         if (memcmp((void *)incoming_random, (void *)magic_HRR_random, 32) == 0)
@@ -432,8 +432,8 @@ static int test_groupnegotiation(const struct tls13groupselection_test_st *curre
     }
 
     /* We set the message callback on the client side (which checks SH/HRR) */
-    server_response = INIT;                                    /* Variable to hold server response info */
-    SSL_set_msg_callback_arg(clientssl, &server_response);     /* add it to the callback */
+    server_response = INIT; /* Variable to hold server response info */
+    SSL_set_msg_callback_arg(clientssl, &server_response); /* add it to the callback */
     SSL_set_msg_callback(clientssl, server_response_check_cb); /* and activate callback */
 
     /* Creating a test connection */

adding

AlignTrailingComments:
    Kind: Always

make lines to exceed line length of 80 characters, so that's the price of .clang-format tweak.

as I've said I'm fine with X-mass tree colors. but if we want to go for this change then it makes sense to do it now..
the cost of .clang-format tweak is reasonable. we won't be able to implement the .clang-format tweak later.