Aussehen
Suche Einloggen
[c] [meta] [fefe] [erp]

/fefe/ – Fefes Kommentarfunktion


Antwort erstellen

(≤ 4)



[Zurück]

  • [l] Liest hier zufällig jemand aus dem C-Standardisierungsprozess ... Effe ## Mod Wed, 14 May 2025 14:22:31 GMT Nr. 156420
    JPG 1000×656 121.6k
    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  
     
           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!

    https://blog.fefe.de/?ts=96da664d
  • [l] Update Effe ## Mod Wed, 14 May 2025 14:27:40 GMT Nr. 156421
    @@ -53,0 +54,2 @@
    +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!
    +

  • [l] Felix Wed, 14 May 2025 14:45:12 GMT Nr. 156422
    Will Herr Leitner SAL neu erfinden?

    void * memcpy(
       _Out_writes_bytes_all_(count) void *dest,
       _In_reads_bytes_(count) const void *src,
       size_t count
    );


    https://learn.microsoft.com/en-us/cpp/code-quality/understanding-sal

    >
    #include

    Herr Leitner hat die Winkelklammern nicht in < und > umgewandelt.

    >
           size_t strnlen(size_t maxlen;

    >
                          const char s[maxlen], size_t maxlen);

    Sieht falsch aus. Felix vermutet, gemeint war:
    size_t strnlen(const char s[.maxlen], size_t maxlen);
  • [l] Felix Wed, 14 May 2025 14:55:44 GMT Nr. 156423
    Warum nicht gleich Rust nemen?
  • [l] Update Effe ## Mod Wed, 14 May 2025 20:22:11 GMT Nr. 156444
    @@ -55,0 +56,12 @@
    +[b]Update[/b]: Wir sind übrigens schon fast da! C99 kennt das hier:
    +
    +[code]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 eine Bettel-Ticket bei LLVM aufmachen.
    +[/code]
  • [l] Update Effe ## Mod Wed, 14 May 2025 20:32:40 GMT Nr. 156445
    @@ -6 +6 @@
    -       #include 
    +       #include <string.h>

  • [l] Felix Thu, 15 May 2025 08:03:05 GMT Nr. 156476
    >>156423
    Weil es scheiße ist.
  • [l] Update Effe ## Mod Thu, 15 May 2025 09:00:11 GMT Nr. 156488
    @@ -66 +66 @@
    -Ich werde mal eine Bettel-Ticket bei LLVM aufmachen.
    +Ich werde mal ein Bettel-Ticket bei LLVM aufmachen.
    @@ -67,0 +68,3 @@
    +[b]Update[/b]: Stellt sich raus: Es gibt bereits einen Vorschlag dafür [0], 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.
    +
    +[0] https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3394.pdf

  • [l] Felix Thu, 15 May 2025 09:22:15 GMT Nr. 156498
    >>156488
    Felix >>156422 sieht aus dem verelften Dokument aus >>156488 gerade, dass die Syntax
    void foo(size_t len; char buf[static len], size_t len);

    aus dem OP anscheinend doch so gewollt war.
    Ja, da ist ein Semikolon zwischen den Klammern.

    Bzgl. des Vorschlags befürchtet Felix gerade, dass der Vorschlag sich nicht gegen das gerade laufende, das "hip und cool"-Label habende Vorhaben der "C++ Contracts" durchsetzen wird. Da gibt es dann Pre- und Postconditions. Felixens Befürchtung ist, das das Standardkomitee dann will, diese auch dazu zu benutzen, zu prüfen, ob der Aufrufer ein entsprechend großes Array übergeben hat.

    https://isocpp.org/files/papers/P2900R6.pdf

    Felix empfiehlt diesen Faden fürs köstliche Amüsement:
    https://old.reddit.com/r/cpp/comments/17t7ohe/contracts_moving_along_hopefully_on_track_for_c26/

    Das ganze reicht aber um Längen noch nicht an SAL heran, was Microsoft im Rahmen des statischen Analysierers "PREfast" für Windows-Treiber entwickelt hat. Letzteres war ein tatsächlich halbwegs funktionierendes Programm, dass dann im MSVC-Analysierer (MSVC mit /analyze) aufgegangen ist, welcher natürlich auch SAL beherrscht.

    Herr Leitner könnte also tatsächlich etwas SAL drübersprenkeln und dann den MSVC-Kompiler mit /analyze anschmeißen, und hätte das alles schon heute.

    Leider versteht Clang noch nicht einmal die SAL-Syntax, und steigt mit einem Compiler-Fehler aus (/analyze setzt eine Präprozessor-Flagge, wodurch die SAL-Annotierungen in den Header-Dateien auftauchen, womit Clang dann nicht klarkommt). Wünschenswert wäre gewesen, dass Clang, wenn es via clang-cl getrieben wird, die SAL-Annotationen zumindest ignorieren würde, und nicht direkt mit Fehler aussteigt.
  • [l] Felix Thu, 15 May 2025 09:31:03 GMT Nr. 156501
    >>156488
    >s/eine/ein
    >...
    >Das werte das als ...
    Ach fefe ...
  • [l] Felix Thu, 15 May 2025 10:28:25 GMT Nr. 156516
    JPG 239×227 15.8k
    In diesem Faden


[Zurück]
[c] [meta] [fefe] [erp]