This PR adds a tool that verifies every header whether it is self-contained.
As an example, the field_5x52.h
and field_10x26.h
headers have been refactored to get self-contained.
This PR adds a tool that verifies every header whether it is self-contained.
As an example, the field_5x52.h
and field_10x26.h
headers have been refactored to get self-contained.
Interesting!
This raises the question: Should self-containedness be tested in VERIFY mode, or non-VERIFY mode, or both? I believe at least in VERIFY mode because the goal here will be to help development tooling (e.g., clangd), and development is typically more convenient in VERIFY mode. Otherwise all #ifdef VERIFY
blocks don’t exist, i.e., you don’t even get syntax highlighting for them…
Of course, we could manage to make this happen in both modes without too much hassle, that will be ideal.
This is related to #1039, where I suggested something like this.
This is related to #1039, where I suggested something like this.
I’ve been working on this branch a few months but decided to PR it now as I feel it might help with #1421 (comment).
29@@ -30,7 +30,10 @@ typedef struct {
30 * sum(i=0..9, n[i] << (i*26)) < p
31 * (together these imply n[9] <= 2^22 - 1)
32 */
33- SECP256K1_FE_VERIFY_FIELDS
34+#ifdef VERIFY
35+ int magnitude;
36+ int normalized;
37+#endif
38 } secp256k1_fe;
field.h
instead?
In some sense, yes, but it’s not a problem because the include guards should break any loops.
If you take that to the extreme, we could also have a single headers.h
that includes all internal headers and include headers.h
(almost) everywhere. That’s a rather simple solution. I’m not convinced that this is very elegant, but it gets the job done…
it’s not a problem because the include guards should break any loops.
Right. But not for renaming a header to a source file. It is not clear (at least for me) how to make it meaningful. FWIW, I’ve already tried the testing script that keeps an original header unmodified.
Right. But not for renaming a header to a source file. It is not clear (at least for me) how to make it meaningful.
You mean problems will occur if we move code from a header to a source file?
FWIW, I’ve already tried the testing script that keeps an original header unmodified.
I don’t understand. Can you rephrase?
Right. But not for renaming a header to a source file. It is not clear (at least for me) how to make it meaningful.
You mean problems will occur if we move code from a header to a source file?
Yes. I mean:
0mv src/field_10x26.h src/field_10x26.c
1gcc -c src/field_10x26.c -o src/field_10x26.o
That effectively renders src/field_10x26.h
unavailable.
FWIW, I’ve already tried the testing script that keeps an original header unmodified.
I don’t understand. Can you rephrase?
A modified script looks like that:
0cp src/field_10x26.h src/field_10x26.c
1gcc -c src/field_10x26.c -o src/field_10x26.o
742+ name: "Self-contained headers"
743+ runs-on: ubuntu-latest
744+
745+ steps:
746+ - name: Checkout
747+ uses: actions/checkout@v4
0 uses: actions/checkout@v5