Self-contained headers #1423

pull hebasto wants to merge 2 commits into bitcoin-core:master from hebasto:230911-headers changing 5 files +46 −9
  1. hebasto commented at 10:39 pm on September 11, 2023: member

    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.

  2. real-or-random added the label ci on Sep 12, 2023
  3. real-or-random added the label build on Sep 12, 2023
  4. real-or-random added the label refactor/smell on Sep 12, 2023
  5. real-or-random added the label development on Sep 12, 2023
  6. real-or-random commented at 8:13 am on September 12, 2023: contributor

    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.

  7. hebasto commented at 2:26 pm on September 12, 2023: member

    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).

  8. in src/field_10x26.h:37 in 652afd3960 outdated
    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;
    


    real-or-random commented at 2:55 pm on September 12, 2023:
    Have you tried/considered including field.h instead?

    hebasto commented at 2:57 pm on September 12, 2023:
    Doesn’t it create a circular dependency?

    real-or-random commented at 10:40 pm on September 12, 2023:

    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…


    hebasto commented at 1:53 pm on September 13, 2023:

    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.


    real-or-random commented at 1:57 pm on September 13, 2023:

    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?


    hebasto commented at 2:01 pm on September 13, 2023:

    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
    
  9. hebasto force-pushed on Sep 13, 2025
  10. hebasto renamed this:
    POC: Self-contained headers
    Self-contained headers
    on Sep 13, 2025
  11. hebasto commented at 2:57 pm on September 13, 2025: member
    Rebased.
  12. in .github/workflows/ci.yml:747 in 3e19728131 outdated
    742+    name: "Self-contained headers"
    743+    runs-on: ubuntu-latest
    744+
    745+    steps:
    746+      - name: Checkout
    747+        uses: actions/checkout@v4
    


    fanquake commented at 9:32 am on September 15, 2025:
    0        uses: actions/checkout@v5
    

    hebasto commented at 11:15 am on September 15, 2025:
    Thanks!. Fixed.
  13. hebasto force-pushed on Sep 15, 2025
  14. Add `tools/check-headers.sh` to check whether headers are self-contained 271c1da6c2
  15. refactor: Make `field_NxM.h` headers self-contained 7f0d072314
  16. hebasto force-pushed on Sep 15, 2025
  17. hebasto commented at 11:17 am on September 15, 2025: member

    Addressed feedback from @fanquake.

    Additionally, the check script now compiles in a temporary directory rather than in the source tree.


github-metadata-mirror

This is a metadata mirror of the GitHub repository bitcoin-core/secp256k1. This site is not affiliated with GitHub. Content is generated from a GitHub metadata backup.
generated: 2025-10-13 21:15 UTC

This site is hosted by @0xB10C
More mirrored repositories can be found on mirror.b10c.me