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

/meta/ – Diskussionen über Dietchan


Antwort erstellen

(≤ 4)



[Zurück]

  • [l] dietlibc-0.35.tar.xz & libowfat-0.34.tar.xz Zuse ## Admin Wed, 28 May 2025 10:53:38 GMT Nr. 157222 Klebrig
    Aus gegebenem Anlass, da Fefes Seite wegen des abgelaufenen Zertifikats ja gerade nicht erreichbar ist, hier die aktuellen Versionen von dietlibc und libowfat. Mir fiel gerade ein, dass der Diätkanal sich ohne die ja gar nicht bauen lässt (außer mit -DUSE_STOCK, falls die Distribution libowfat als Paket ausliefert wie z.B. Debian und jenes installiert ist).

    Hätte uns doch nur jemand gewarnt vor Paketmanagern und Abhängigkeitshölle!

    Vielleicht ist das ja auch sonst für den ein oder anderen nützlich. Die Prüfsummen könnt ihr im Quelltext verifizieren [0]. Wie praktisch, dass der Kanal erst vor Kurzem TAR-Unterstütztung erhalten hat.

    5aa5599039ae58bba7b4a1566fc453485cd1a155a20b313e15cd1bd0e19c0beb  dietlibc-0.35.tar.xz
    d4330d373ac9581b397bc24a22ad1f7f5d58a7fe36d9d239fe352ceffc5d304b  libowfat-0.34.tar.xz
    


    [0] https://gitgud.io/zuse/dietchan/-/blob/master/CMakeLists.txt?ref_type=heads
  • [l] dietlibc 0.35 lässt sich mit GCC 15 nicht kompilieren Zuse ## Admin Wed, 28 May 2025 17:06:53 GMT Nr. 157245
    Wobei Zuse gerade auffällt, dass sich das frisch geklont mit GCC 15.1.1 sowieso nicht kompilieren lässt:

    In file included from x86_64/stackgap-pie.c:1:
    librpc/svc.c: In function ‘svc_register’:
    librpc/svc.c:142:8: error: argument ‘dispatch’ doesn’t match prototype
      142 | void (*dispatch) ();
          |        ^~~~~~~~
    In file included from include/rpc/rpc.h:59,
                     from librpc/svc.c:49:
    include/rpc/svc.h:173:15: error: prototype declaration
      173 | extern bool_t svc_register (SVCXPRT *__xprt, rpcprog_t __prog,
          |               ^~~~~~~~~~~~
    librpc/svc.c: In function ‘svc_find’:
    librpc/svc.c:199:28: warning: old-style function definition [-Wold-style-definition]
      199 | static struct svc_callout *svc_find(prog, vers, prev)
          |                            ^~~~~~~~
    librpc/svc.c: In function ‘svc_getreqset’:
    librpc/svc.c:456:66: error: too many arguments to function ‘s->sc_dispatch’; expected 0, have 2
      456 |                                                                 (*s->sc_dispatch) (&r, xprt);
          |                                                                 ~^~~~~~~~~~~~~~~~  ~~
    librpc/svc_auth.c: In function ‘_authenticate’:
    librpc/svc.c:76:16: note: declared here
       76 |         void (*sc_dispatch) ();
          |                ^~~~~~~~~~~
    librpc/svc_auth.c:103:26: error: too many arguments to function ‘svcauthsw[cred_flavor].authenticator’; expected 0, have 2
      103 |                 return ((*(svcauthsw[cred_flavor].authenticator)) (rqst, msg));
          |                         ~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~  ~~~~
    librpc/svc_auth.c:64:26: note: declared here
       64 |         enum auth_stat (*authenticator) ();
          |                          ^~~~~~~~~~~~~
    librpc/rpc_prot.c: In function ‘xdr_accepted_reply’:
    librpc/rpc_prot.c:83:15: warning: old-style function definition [-Wold-style-definition]
       83 | static bool_t xdr_accepted_reply(xdrs, ar)
          |               ^~~~~~~~~~~~~~~~~~
    librpc/rpc_prot.c: In function ‘xdr_rejected_reply’:
    librpc/rpc_prot.c:109:15: warning: old-style function definition [-Wold-style-definition]
      109 | static bool_t xdr_rejected_reply(xdrs, rr)
          |               ^~~~~~~~~~~~~~~~~~
    librpc/rpc_prot.c: In function ‘accepted’:
    librpc/rpc_prot.c:177:13: warning: old-style function definition [-Wold-style-definition]
      177 | static void accepted(acpt_stat, error)
          |             ^~~~~~~~
    librpc/rpc_prot.c: In function ‘rejected’:
    librpc/rpc_prot.c:214:13: warning: old-style function definition [-Wold-style-definition]
      214 | static void rejected(rjct_stat, error)
          |             ^~~~~~~~
    make[3]: *** [Makefile:211: bin-x86_64/svc_auth.o] Error 1
    make[3]: *** Waiting for unfinished jobs....
    make[3]: *** [Makefile:211: bin-x86_64/svc.o] Error 1
    librpc/svc_auth_unix.c: In function ‘_svcauth_unix’:
    librpc/svc_auth_unix.c:56:16: warning: old-style function definition [-Wold-style-definition]
       56 | enum auth_stat _svcauth_unix(rqst, msg)
          |                ^~~~~~~~~~~~~
    librpc/svc_auth_unix.c: In function ‘_svcauth_short’:
    librpc/svc_auth_unix.c:135:16: warning: old-style function definition [-Wold-style-definition]
      135 | enum auth_stat _svcauth_short(rqst, msg)
          |                ^~~~~~~~~~~~~~
    librpc/svc_raw.c: In function ‘svcraw_recv’:
    librpc/svc_raw.c:98:15: warning: old-style function definition [-Wold-style-definition]
       98 | static bool_t svcraw_recv(xprt, msg)
          |               ^~~~~~~~~~~
    librpc/svc_raw.c: In function ‘svcraw_reply’:
    librpc/svc_raw.c:117:15: warning: old-style function definition [-Wold-style-definition]
      117 | static bool_t svcraw_reply(xprt, msg)
          |               ^~~~~~~~~~~~
    librpc/svc_raw.c: In function ‘svcraw_getargs’:
    librpc/svc_raw.c:137:15: warning: old-style function definition [-Wold-style-definition]
      137 | static bool_t svcraw_getargs(xprt, xdr_args, args_ptr)
          |               ^~~~~~~~~~~~~~
    librpc/svc_raw.c: In function ‘svcraw_freeargs’:
    librpc/svc_raw.c:151:15: warning: old-style function definition [-Wold-style-definition]
      151 | static bool_t svcraw_freeargs(xprt, xdr_args, args_ptr)
          |               ^~~~~~~~~~~~~~~
    librpc/svc_simple.c: In function ‘universal’:
    librpc/svc_simple.c:99:13: warning: old-style function definition [-Wold-style-definition]
       99 | static void universal(rqstp, mytransp)
          |             ^~~~~~~~~
    librpc/svc_simple.c:128:36: error: too many arguments to function ‘mypl->p_progname’; expected 0, have 1
      128 |                         outdata = (*(mypl->p_progname)) (xdrbuf);
          |                                   ~^~~~~~~~~~~~~~~~~~~~  ~~~~~~
    librpc/svc_simple.c:51:17: note: declared here
       51 |         char *(*p_progname) ();
          |                 ^~~~~~~~~~
    make[3]: *** [Makefile:211: bin-x86_64/svc_simple.o] Error 1
    make[2]: *** [CMakeFiles/dietlibc.dir/build.make:96: .prefix/dietlibc/src/dietlibc-stamp/dietlibc-build] Error 2
    make[1]: *** [CMakeFiles/Makefile2:100: CMakeFiles/dietlibc.dir/all] Error 2
    make: *** [Makefile:91: all] Error 2
    
    


    Nicht sicher, ob Zuse da drin rumfrickeln will. Petsches welkam.

    Das kaputte Zertifikat kann man ansonsten übrigens auch noch mit CMAKE_TLS_VERIFY=0 make umgehen. Solange der Servierer nicht komplett abschnur ist, wäre das also auch noch eine Möglichkeit. Nützt natürlich nichts, wenn es sich in aktuellem GCC nicht kompilieren lässt.
  • [l] Zuse ## Admin Wed, 28 May 2025 17:15:05 GMT Nr. 157246
    JPG 4000×3000 4.5M
    Es ist alles so mühsam...
  • [l] Felix Wed, 28 May 2025 17:31:22 GMT Nr. 157248
    PNG 1129×601 45.6k
    >>157245
    >Wobei Zuse gerade auffällt, dass sich das frisch geklont mit GCC 15.1.1 sowieso nicht kompilieren lässt
    Was genau? Kann ich dein Repo irgendwie einfach clonen und den build starten? 0.35 ist nichtmal im aktuellen Trixie.
  • [l] Felix Wed, 28 May 2025 17:33:34 GMT Nr. 157249 SÄGE
    Nachtrag:
    >libowfat-dev armhf 0.32-5
    >gcc (Debian 14.2.0-19) 14.2.0
    Ist auch etwas alt.
  • [l] Zuse ## Admin Wed, 28 May 2025 17:45:39 GMT Nr. 157255 SÄGE
    >>157248
    Viele Distros shippen dietlibc und libowfat nicht (oder nur in veralteten Versionen so wie bei dir), deswegen habe ich das damals, damit man es einfach so auspacken und laufen lassen kann, mit CMake so hingebastelt, dass das standardmäßig aus der Quelle gebaut wird.

    Wenn du libowfat hast, dann sollte kompilieren aber trotzdem funktionieren mit

    cmake -DUSE_STOCK .
    make
    


    Wenn du CMake schon mal ausgeführt hast, dann musst du eventuell aber vorher den Ordner .prefix und ein paar andere CMake-Dateien löschen. Sonst hat CMake irgendwelche Probleme.

    Es wird dann allerdings mit deiner regulären libc gebaut und nicht mit dietlibc. Und da ich selbst immer aus der Quelle baue, kann ich auch nicht garantieren, dass alles 100% funktioniert.

    Achso, und beim Klonen den --recursive Parameter nicht vergessen!

    git clone --recursive ...
    


    Sonst wird das Captcha-Submodule nicht geladen.

    Selbstsäge im Klebi wegen Pfostierfersagens.
  • [l] Felix Wed, 28 May 2025 19:34:48 GMT Nr. 157257
    PNG 296×296 717
    >>157255
    Leider der ähnliche Fehler (aber weniger) während dietlibc-Kuhmpilierung unter
    <gcc (Debian 14.2.0-19) 14.2.0
    mit den libs in 0.34 und 0.35

    Die Compiler-Version ist zumindest nicht alleine schuld. Logs habe ich nicht angehängt, da ich es Morgen nochmal probieren will.
  • [l] Felix Wed, 28 May 2025 19:36:12 GMT Nr. 157258 SÄGE
    Hatte mich gegen USE_STOCK entschieden und den TLS-Error ignoriert, da ich gegen das GCC und Trixie testen wollte. Die alten Debian Versionen würden dir ja nicht helfen. Die laufen ja schon bei dir gut.
  • [l] Felix Thu, 29 May 2025 01:30:57 GMT Nr. 157260
    fefer liefert ja auch ohne tls aus. ist sowieso bloat
  • [l] Felix Thu, 29 May 2025 07:00:18 GMT Nr. 157261 SÄGE
    >>157260
    In dem Punkt, dass sein Blog nicht wirklich Geheimes enthält ja. Aber TLS schützt auch davor, dass die CIA alle Inhalte von Fefe im Transport mit Artikeln von der TAZ austauscht.
  • [l] Felix Fri, 30 May 2025 03:34:15 GMT Nr. 157305
    JPG 255×342 27.8k
    >>157257
    >Die Compiler-Version ist zumindest nicht alleine schuld. Logs habe ich nicht angehängt, da ich es Morgen nochmal probieren will.
    Und? Inzwischen weitergekommen?
  • [l] Felix Sat, 31 May 2025 14:50:18 GMT Nr. 157348
    >>157245
    Das liegt vermutlich an:
    >C23 by default: GCC 15 changes the default language version for C compilation from -std=gnu17 to -std=gnu23. If your code relies on older versions of the C standard, you will need to either add -std= to your build flags, or port your code; see the porting notes.
    https://gcc.gnu.org/gcc-15/changes.html

    >The meaning of function declarations of the form rettype identifier (); such as char *strstr (); changed in C23.
    https://gcc.gnu.org/gcc-15/porting_to.html#c23-fn-decls-without-parameters

    Felix hat mal auf den dietlibc-Kot geschaut, und den Teil hat Fefe von Sun Microsystems geklaut.
    Zum Thema Sun Microsystems der Kommentar vom Meister selbst:

    Sun und Java sind erst recht scheiße.  Ich schlage dir mal *dringend*
    vor, daß du dich ein bißchen informierst, bevor du hier solches Gewäsch
    losläßt.  Suns Innovationen waren bisher immer ein Muster-Antibeispiel.
    
    -- Felix von Leitner in de.org.ccc
       1997-05-24 <slrn5od4la.94u.felix@kutta.math.fu-berlin.de>

    https://github.com/yayachiken/fortune-mod-fvl/blob/master/fvl_vendor#L45

    Flicken im Anhang.
  • [l] Zuse ## Admin Sun, 01 Jun 2025 05:35:05 GMT Nr. 157355
    PNG 379×426 3.4k
    >>157348
    Kühl, scheint zu funktionieren, vielen Dank! Flicken selbst geschrieben oder aus dem CVS (ist für Zuse Voodoo) ausgegraben? Wem soll ich das Commit widmen?

    Sieht aber leider so aus, als ob libowfat auch noch einen Flicken bräuchte:
    In file included from buffer/buffer_0.c:2:
    ./buffer.h:40:65: error: initialization of ‘ssize_t (*)(void)’ {aka ‘long int (*)(void)’} from incompatible pointer type ‘ssize_t (*)(int,  char *, size_t)’ {aka ‘long int (*)(int,  char *, long unsigned int)’} [-Wincompatible-pointer-types]
       40 | #define BUFFER_INIT(op,fd,buf,len) { (char*)(buf), 0, 0, (len), (op), NULL, NULL, (fd) }
          |                                                                 ^
    ./buffer.h:42:41: note: in expansion of macro ‘BUFFER_INIT’
       42 | #define BUFFER_INIT_READ(op,fd,buf,len) BUFFER_INIT(op,fd,buf,len) /*obsolete*/
          |                                         ^~~~~~~~~~~
    buffer/buffer_0.c:10:20: note: in expansion of macro ‘BUFFER_INIT_READ’
       10 | static buffer it = BUFFER_INIT_READ(b0read,0,buffer_0_space,sizeof buffer_0_space);
          |                    ^~~~~~~~~~~~~~~~
    ./buffer.h:40:65: note: (near initialization for ‘it.op’)
       40 | #define BUFFER_INIT(op,fd,buf,len) { (char*)(buf), 0, 0, (len), (op), NULL, NULL, (fd) }
          |                                                                 ^
    ./buffer.h:42:41: note: in expansion of macro ‘BUFFER_INIT’
       42 | #define BUFFER_INIT_READ(op,fd,buf,len) BUFFER_INIT(op,fd,buf,len) /*obsolete*/
          |                                         ^~~~~~~~~~~
    buffer/buffer_0.c:10:20: note: in expansion of macro ‘BUFFER_INIT_READ’
       10 | static buffer it = BUFFER_INIT_READ(b0read,0,buffer_0_space,sizeof buffer_0_space);
          |                    ^~~~~~~~~~~~~~~~
    buffer/buffer_0.c:4:16: note: ‘b0read’ declared here
        4 | static ssize_t b0read(int fd,char* buf, size_t len) {
          |                ^~~~~~
    In file included from buffer/buffer_0small.c:2:
    ./buffer.h:40:65: error: initialization of ‘ssize_t (*)(void)’ {aka ‘long int (*)(void)’} from incompatible pointer type ‘ssize_t (*)(int,  char *, size_t)’ {aka ‘long int (*)(int,  char *, long unsigned int)’} [-Wincompatible-pointer-types]
       40 | #define BUFFER_INIT(op,fd,buf,len) { (char*)(buf), 0, 0, (len), (op), NULL, NULL, (fd) }
          |                                                                 ^
    ./buffer.h:42:41: note: in expansion of macro ‘BUFFER_INIT’
       42 | #define BUFFER_INIT_READ(op,fd,buf,len) BUFFER_INIT(op,fd,buf,len) /*obsolete*/
          |                                         ^~~~~~~~~~~
    buffer/buffer_0small.c:10:20: note: in expansion of macro ‘BUFFER_INIT_READ’
       10 | static buffer it = BUFFER_INIT_READ(b0read,0,buffer_0_space,sizeof buffer_0_space);
          |                    ^~~~~~~~~~~~~~~~
    ./buffer.h:40:65: note: (near initialization for ‘it.op’)
       40 | #define BUFFER_INIT(op,fd,buf,len) { (char*)(buf), 0, 0, (len), (op), NULL, NULL, (fd) }
          |                                                                 ^
    ./buffer.h:42:41: note: in expansion of macro ‘BUFFER_INIT’
       42 | #define BUFFER_INIT_READ(op,fd,buf,len) BUFFER_INIT(op,fd,buf,len) /*obsolete*/
          |                                         ^~~~~~~~~~~
    buffer/buffer_0small.c:10:20: note: in expansion of macro ‘BUFFER_INIT_READ’
       10 | static buffer it = BUFFER_INIT_READ(b0read,0,buffer_0_space,sizeof buffer_0_space);
          |                    ^~~~~~~~~~~~~~~~
    buffer/buffer_0small.c:4:16: note: ‘b0read’ declared here
        4 | static ssize_t b0read(int fd,char* buf, size_t len) {
          |                ^~~~~~
    In file included from buffer/buffer_1.c:2:
    ./buffer.h:40:65: error: initialization of ‘ssize_t (*)(void)’ {aka ‘long int (*)(void)’} from incompatible pointer type ‘ssize_t (*)(int,  const void *, size_t)’ {aka ‘long int (*)(int,  const void *, long unsigned int)’} [-Wincompatible-pointer-types]
       40 | #define BUFFER_INIT(op,fd,buf,len) { (char*)(buf), 0, 0, (len), (op), NULL, NULL, (fd) }
          |                                                                 ^
    buffer/buffer_1.c:8:20: note: in expansion of macro ‘BUFFER_INIT’
        8 | static buffer it = BUFFER_INIT(write,1,buffer_1_space,sizeof buffer_1_space);
          |                    ^~~~~~~~~~~
    ./buffer.h:40:65: note: (near initialization for ‘it.op’)
       40 | #define BUFFER_INIT(op,fd,buf,len) { (char*)(buf), 0, 0, (len), (op), NULL, NULL, (fd) }
          |                                                                 ^
    buffer/buffer_1.c:8:20: note: in expansion of macro ‘BUFFER_INIT’
        8 | static buffer it = BUFFER_INIT(write,1,buffer_1_space,sizeof buffer_1_space);
          |                    ^~~~~~~~~~~
    In file included from buffer/buffer_1.c:1:
    [KLASSIFIZIERT]/dietchan2/build/include/unistd.h:79:9: note: ‘write’ declared here
       79 | ssize_t write(int fd,const void* buf,size_t len) __THROW;
          |         ^~~~~
    make[3]: *** [GNUmakefile:1186: buffer_0.o] Error 1
    make[3]: *** Waiting for unfinished jobs....
    make[3]: *** [GNUmakefile:1186: buffer_0small.o] Error 1
    make[3]: *** [GNUmakefile:1186: buffer_1.o] Error 1
    In file included from buffer/buffer_2.c:2:
    ./buffer.h:40:65: error: initialization of ‘ssize_t (*)(void)’ {aka ‘long int (*)(void)’} from incompatible pointer type ‘ssize_t (*)(int,  const void *, size_t)’ {aka ‘long int (*)(int,  const void *, long unsigned int)’} [-Wincompatible-pointer-types]
       40 | #define BUFFER_INIT(op,fd,buf,len) { (char*)(buf), 0, 0, (len), (op), NULL, NULL, (fd) }
          |                                                                 ^
    buffer/buffer_2.c:5:20: note: in expansion of macro ‘BUFFER_INIT’
        5 | static buffer it = BUFFER_INIT(write,2,buffer_2_space,sizeof buffer_2_space);
          |                    ^~~~~~~~~~~
    ./buffer.h:40:65: note: (near initialization for ‘it.op’)
       40 | #define BUFFER_INIT(op,fd,buf,len) { (char*)(buf), 0, 0, (len), (op), NULL, NULL, (fd) }
          |                                                                 ^
    buffer/buffer_2.c:5:20: note: in expansion of macro ‘BUFFER_INIT’
        5 | static buffer it = BUFFER_INIT(write,2,buffer_2_space,sizeof buffer_2_space);
          |                    ^~~~~~~~~~~
    In file included from buffer/buffer_2.c:1:
    [KLASSIFIZIERT]/dietchan2/build/include/unistd.h:79:9: note: ‘write’ declared here
       79 | ssize_t write(int fd,const void* buf,size_t len) __THROW;
          |         ^~~~~
    make[3]: *** [GNUmakefile:1186: buffer_2.o] Error 1
    In file included from buffer/buffer_1small.c:2:
    ./buffer.h:40:65: error: initialization of ‘ssize_t (*)(void)’ {aka ‘long int (*)(void)’} from incompatible pointer type ‘ssize_t (*)(int,  const void *, size_t)’ {aka ‘long int (*)(int,  const void *, long unsigned int)’} [-Wincompatible-pointer-types]
       40 | #define BUFFER_INIT(op,fd,buf,len) { (char*)(buf), 0, 0, (len), (op), NULL, NULL, (fd) }
          |                                                                 ^
    buffer/buffer_1small.c:5:20: note: in expansion of macro ‘BUFFER_INIT’
        5 | static buffer it = BUFFER_INIT(write,1,buffer_1_space,sizeof buffer_1_space);
          |                    ^~~~~~~~~~~
    ./buffer.h:40:65: note: (near initialization for ‘it.op’)
       40 | #define BUFFER_INIT(op,fd,buf,len) { (char*)(buf), 0, 0, (len), (op), NULL, NULL, (fd) }
          |                                                                 ^
    buffer/buffer_1small.c:5:20: note: in expansion of macro ‘BUFFER_INIT’
        5 | static buffer it = BUFFER_INIT(write,1,buffer_1_space,sizeof buffer_1_space);
          |                    ^~~~~~~~~~~
    In file included from buffer/buffer_1small.c:1:
    [KLASSIFIZIERT]/dietchan2/build/include/unistd.h:79:9: note: ‘write’ declared here
       79 | ssize_t write(int fd,const void* buf,size_t len) __THROW;
          |         ^~~~~
    make[3]: *** [GNUmakefile:1186: buffer_1small.o] Error 1
    make[2]: *** [CMakeFiles/libowfat.dir/build.make:96: .prefix/libowfat/src/libowfat-stamp/libowfat-build] Error 2
    make[1]: *** [CMakeFiles/Makefile2:132: CMakeFiles/libowfat.dir/all] Error 2
    make: *** [Makefile:91: all] Error 2
    

  • [l] Zuse ## Admin Sun, 01 Jun 2025 13:07:06 GMT Nr. 157386
    Habe mal nen MR mit dem aktuellen Stand aufgemacht: https://gitgud.io/zuse/dietchan/-/merge_requests/2
  • [l] Felix Sun, 01 Jun 2025 13:43:14 GMT Nr. 157389
    >>157355
    Ich habe es zum Kompilieren bekommen, aber sage gleich, dass das, was der Meister zum Teil vom Herrn Bernstein übernommen hat und zum Teil dort selbst verzapft hat, absolut unterirdisch ist. Je mehr ich dort reinschaue, desto schlimmer wird es.

    Es geht um den buffer aus der libowfat (buffer.h):

    typedef struct buffer {
      char *x;              /* actual buffer space */
      size_t p;             /* current position */
      size_t n;             /* current size of string in buffer */
      size_t a;             /* allocated buffer size */
      ssize_t (*op)();      /* use read(2) or write(2) */
      void* cookie;                 /* used internally by the to-stralloc buffers, and for buffer chaining */
      void (*deinit)(void*);        /* called to munmap/free cleanup, with a pointer to the buffer as argument */
      int fd;               /* passed as first argument to op */
    } buffer;


    Wie man sieht, kriegt der Buffer eine op-Funktion übergeben. Und wie man bereits am Kommentar dort sieht: Das können z.B. die POSIX-Funktionen read() oder write() sein, oder auch andere Funktionen (wie intern in der libowfat genutzt). Da kommt man direkt zum ersten Problem, da read() und write() nicht die gleiche Signatur haben:

    ssize_t read(int fd, void *buf, size_t count);

    ssize_t write(int fd, const void *buf, size_t count);


    Also Unterschiede im cv-Qualifizierer des zweiten Parameters.

    Im Internet gibt es Diskussionen darüber, dass es UB sei, weil void * keine "unqualified version" von const void * sei (das wäre wohl bei void * const der Fall), und daher die Funktionsaufrufe inkompatibel seien:
    https://old.reddit.com/r/C_Programming/comments/18fbsfg/is_casting_a_function_pointer_to_the_same_type/

    Darum geht es hier aber nicht, denn das ist ein Luxusproblem im Vergleich zu den nun folgenden Problemen mit externem Kot und internem Kot.

    Erst mal muss man sich an der Stelle oben entscheiden: Nimmt man Signatur 1, Signatur 2, oder einen void *. Da auch externer Kot solche Punktionszeiger z.B. an buffer_init übergibt, muss man void * nehmen, da ansonsten der externe Kot einen Kompilerfehler verursacht, da dieser externe Kot sowohl Signatur 1 als auch Signatur 2 verwenden könnte. Mit void * gibt es nur eine Warnung, auch nicht schön, aber was will man machen.

    Nun zu den Problemen mit dem libowfat-internen Kot. Da ist extremes Voodoo involviert (das Felix auch im originalen Bernstein-Kot bisher nicht gefunden hat). Denn intern in der libowfat wird die op-Funktion auch schon mal mit 4 statt 3 Parametern aufgerufen. Das sieht man in buffer_feed, buffer_flush, buffer_put, buffer_putflush. Diese leiten den op-Funktionszeiger an buffer_stubborn oder buffer_stubborn_read weiter, welche den Funktionszeiger mit 4 Parametern aufrufen/missbrauchen.

    Felix will gar nicht wissen, was passiert, wenn man einen buffer mit read()/write() als op anlegt, und dann eine der obigen Funktionen aufruft, und zwar in einer Calling-Convention, bei dem der Aufgerufene den Stack aufräumen muss (z.B. das standardmäßige stdcall auf 32-Bit-Fenster, wo auch alle Parameter über den Stack gehen, vielleicht deswegen auch das "Please do not port my software to Windows!"). Das geht hier auf Linux bzw. x86/x86_64 nur gut, weil der Aufrufer zwar was in rcx schreibt, aber rcx vom aufgerufenen read()/write/etc. gemäß Calling-Convention ignoriert wird.

    Die Besten der Besten.
  • [l] Felix Sun, 01 Jun 2025 13:53:47 GMT Nr. 157390
    >>157389
    Kot von djb ist per Definition perfekt und enthält keine Bugs.
  • [l] Felix Sun, 01 Jun 2025 14:04:02 GMT Nr. 157391
    >>157389
    >Da ist extremes Voodoo involviert (das Felix auch im originalen Bernstein-Kot bisher nicht gefunden hat). Denn intern in der libowfat wird die op-Funktion auch schon mal mit 4 statt 3 Parametern aufgerufen.
    Solche Zustände sind normal in Fefes Code. Du bist einfach nur nicht genial genug, um ihn zu verstehen.
  • [l] Felix Sun, 01 Jun 2025 15:33:00 GMT Nr. 157392
    Fefe hat das mit den 4 Parametern in libowfat Version 0.29 (vom 02.11.2012) hinzugefügt, um Bernsteins dynamische String-Bibliothek (die Datenstruktur für den String heißt stralloc, einfach nur ein char *, len, capacity) irgendwie an die Buffer-Bibliothek ranzuflanschen. So kann man mit dem Schreiben in einen buffer einen String zusammenbauen.

    An ausgewählten Stellen kriegt die op-Funktion dann einen vierten Parameter übergeben, welcher einfach nur ein Zeiger auf den buffer ist, der wiederum einen cookie-Zeiger hat, der auf den dynamischen String zeigt. Dadurch kann dann beim op-Aufruf der String realloziert werden, wenn die Kapazität zu knapp wird.

    Man kann einen Buffer zum Schreiben in einen dynamischen String mit buffer_tosa ("to stralloc") initialisieren, was es dann auch ins Changelog zur Version 0.29 geschafft hat:
    >add buffer_tosa (buffer writing to auto-growing stralloc)
    https://www.fefe.de/libowfat/changes-0.29.txt
  • [l] Zuse ## Admin Sun, 01 Jun 2025 15:57:23 GMT Nr. 157393
    >>157389
    Auch hier noch einmal Danke für den Flicken. Einziger Kritikpunkt: Bezeichner, die mit zwei Unterstrichen anfangen, sowie Bezeichner, die auf _t enden, sind reserviert und dürfen in konformem Kot nicht verwendet werden. [0] __buffer_stubborn_op_t ist also gleich doppelt problematisch.

    >The names of all library types, macros, variables and functions that come from the ISO C standard are reserved unconditionally; your program may not redefine these names.
    >...
    >In addition to the names documented in this manual, reserved names include all external identifiers (global functions and variables) that begin with an underscore (‘_’) and all identifiers regardless of use that begin with either two underscores or an underscore followed by a capital letter are reserved names.
    >...
    >Names that end with ‘_t’ are reserved for additional type names.

    Kommt immer wieder rein...

    [0] https://www.gnu.org/software/libc/manual/html_node/Reserved-Names.html
  • [l] Felix Sun, 01 Jun 2025 16:54:50 GMT Nr. 157397
    >>157393
    Stimmt, da war was. Änder das bitte auch im ersten Flicken. Alternativ die im Anhang.

    Felix ist aber eingefallen, wie er darauf gekommen ist:
    https://android.googlesource.com/platform/hardware/msm7k/+/donut-release/librpc/svc.c#75

    Schnelles greppen über den Kot zeigt, dass es da auch noch andere Identifizierer mit __ in der Kotbasis... egal.

    >Wem soll ich das Commit widmen?
    Das "Felix" dort ist perfekt, danke.
  • [l] Zuse ## Admin Mon, 02 Jun 2025 09:34:51 GMT Nr. 157447
    >>157397
    __dispatch_fn ist in include/svc/svc.h bereits definiert, deshalb sehe ich da kein Problem.

    >Schnelles greppen über den Kot zeigt, dass es da auch noch andere Identifizierer mit __ in der Kotbasis... egal.
    Wir können nicht alles dort fixen, wir sollten die Situation nur nicht noch weiter verschlimmern.
  • [l] Zuse ## Admin Mon, 02 Jun 2025 10:29:35 GMT Nr. 157449
    So, Flicken sind eingepflegt und Fallzurück-Spiegel wurden auch hinzugefügt, problemloses Bauen sollte nun also wieder möglich sein. Vielen Dank noch mal an Felix für die Unterstützung! Merge-Fersagen bitte ignorieren
  • [l] Zuse ## Admin Mon, 02 Jun 2025 10:54:44 GMT Nr. 157450
    JPG 799×583 123.7k
    Bissl nervig: Irgendwie scheint CMake jetzt seine alte Krankheit wieder zu haben, dass es jedes mal den Kanal (und Captcha und andere Unterprojekte) komplett neu baut, wenn man make/ninja aufruft. Ist jetzt nicht so gravierend, weil der Kot recht minimalistisch ist und das Kompilieren daher schnell geht (betrifft auch nicht die Dependencies), aber trotzdem etwas nervig. Das war schon mal behoben. Keine Ahnung, wieso das jetzt plötzlich wieder auftritt.


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