Fefes Blog

Fragen? Antworten! Siehe auch: Alternativlos

Wed May 14 2025

• [l] Liest hier zufällig jemand aus dem C-Standardisierungsprozess mit?

  Linux-Man-Pages haben neuerdings eine eigene Syntax für Funktionsbeschreibungen. Hier ist ein Beispiel:

  SYNOPSIS
         #include <string.h>
  
         size_t strnlen(size_t maxlen;
                        const char s[maxlen], size_t maxlen);

  Wieso kann das reguläre C das eigentlich nicht?

  Stattdessen gibt es einen gcc-Alleingang über __attribute__, den nicht mal clang unterstützt (ich habe letztes Jahr einen Bug aufgemacht, der leider nichts erreicht hat). Ich habe seit dem in meinen Projekten großflächig diesen Attribute-Hack ausgerollt, und plötzlich kann der Compiler mich warnen, wenn ich z.B. einen Pointer mit Länge 100 übergebe, aber der Pointer nur für 50 Bytes alloziert wurde.

  Da sind wir uns doch hoffentlich alle einig, dass wir das haben wollen, richtig?

  Wenn hier also jemand mitliest, der da Einfluss nehmen kann: Mach doch mal bitte!

  Für C++ wäre das natürlich auch gut, aber weniger dringend, weil man da üblicherweise nicht mit Pointern und Längen hantiert sondern mit STL Containern.

  Besonders schön wäre, wenn das auch noch ein bisschen erweiterbar ist. Hier ist z.B. ein Funktionsprototyp von libsodium:

  SODIUM_EXPORT
  int crypto_aead_aegis128l_encrypt(
    unsigned char       *c,
    unsigned long long  *clen_p,
    const unsigned char *m,
    unsigned long long   mlen,
    const unsigned char *ad,
    unsigned long long   adlen,
    const unsigned char *nsec,
    const unsigned char *npub,
    const unsigned char *k) __attribute__((nonnull(1, 8, 9)));

  libsodium ist eine Krypto-Library. Wäre das nicht großartig, wenn man da stattdessen folgendes schreiben könnte?

  SODIUM_EXPORT
  int crypto_aead_aegis128l_encrypt(
    unsigned char       c[mlen + crypto_aead_aegis128l_ABYTES],
    unsigned long long  *clen_p,
    const unsigned char m[mlen],
    unsigned long long   mlen,
    const unsigned char ad[adlen],
    unsigned long long   adlen,
    const unsigned char *nsec,
    const unsigned char npub[crypto_aead_aegis128l_NPUBBYTES],
    const unsigned char k[crypto_aead_aegis128l_KEYBYTES])

  C ist alt und hat eine Menge Warzen. Keine Frage. Aber das heißt ja nicht, dass man da nicht mal ab und zu Dinge verbessern kann!

  Wenn die Länge des Zielbuffer wie in diesem Beispiel nicht direkt ein Funktionsargument ist sondern sich daraus berechnet, kann auch die gcc-Attribute-Hack-Nummer das nicht abbilden. Das müsste alles nicht so schlimm sein!

  Update: Wir sind übrigens schon fast da! C99 kennt das hier:

  int foo(unsigned int len, char foo[static len]);

  Leider kennt C99 keinen Weg für den Fall, wo erst der Pointer und dann die Länge übergeben wird. Aber dafür hat gcc eine Extension, die aber leider clang nicht kann:

  int bar(unsigned int len; char foo[static len],unsigned int len);

  Ich werde mal ein Bettel-Ticket bei LLVM aufmachen.

  Update: Stellt sich raus: Es gibt bereits einen Vorschlag dafür, der konnte sich aber bisher nicht durchsetzen. Es wird aber einen neuen Anlauf geben. Das werte das als gutes Omen, dass clang das unilateral als Extension einbauen könnte, selbst wenn das noch nicht im Standard ist.