PHP, ffi Beispiele

Dergute W. schrieb:

Bei printf.php seh' ich im Browser nix. Also nur eine weisse Seite.

Da da kein HTML-Header etc. kommt, ist das nicht weiter überraschend.

Moin,

Harald K. schrieb:

Dergute W. schrieb:

Bei printf.php seh' ich im Browser nix. Also nur eine weisse Seite.

Da da kein HTML-Header etc. kommt, ist das nicht weiter überraschend.

Doch, ist es. Ich wuerde ein "Hello world" erwarten. Bei errno.php kommt auch ein freundliches int(0) bzw. int(2).

Gruss WK

Vielleicht findet ja Dein php die libc.so.6 nicht, wenn es im Kontext des Webservers ausgeführt wird?

Moin,

Ich hab' jetzt mal im printf.php die Zeile mit printf dahingehend abgeaendert:

1

var_dump($ffi->printf("Hello %s!\n", "world"));

Und kriege int(13) im Browser angezeigt. Was ja der Rueckgabewert von printf sein wird. Also geht anscheinend der stdout der libc irgendwie nicht an php-fpm, so wie's aussieht? Aber warum, und wohin geht der?

Gruss WK

Nun, prüf' mal, welchen Wert stdout hat, also mach ein

var_dump($ffi->stdout);

Moin, Harald K. schrieb im Beitrag #7549002:

Nun, prüf' mal, welchen Wert stdout hat, also mach ein

var_dump($ffi->stdout);

Das sieht nicht gut aus. Im browser taucht weiterhin nix auf, aber stdout wird keine "normale" variable sein, vermute ich mal stark...

1

root [ /srv/www ]# php printf.php 

2

Hello world!

3

PHP Fatal error:  Uncaught FFI\Exception: Attempt to read undefined C variable 'stdout' in /srv/www/printf.php:8

4

Stack trace:

5

#0 {main}

6

  thrown in /srv/www/printf.php on line 8

Gruss WK

Dergute W. schrieb:

aber stdout wird keine "normale" variable sein, vermute ich mal stark

stdout ist aber das, wohin printf seinen Kram ausgibt. Ist vom Typ FILE*, d.h. Pointer auf eine Struktur.

Statt printf("bla") kann man auch fprintf(stdout, "bla") verwenden.

Das wird nicht die Lösung Deines Problems sein, aber ich nehme stark an, daß das Problem irgendwo in diesem Dunstkreis liegt.

Dein Fehlercode 2 aus errno lässt jedenfalls darauf schließen, daß stdout nicht verfügbar ist.

Moin,

Harald K. schrieb:

Dein Fehlercode 2 aus errno lässt jedenfalls darauf schließen, daß stdout nicht verfügbar ist.

Ja, gut moeglich. Koennte evtl. damit zusammenhaengen, wie nginx und php verwurstet sind? hier meine /etc/nginx/nginx.conf

1

user www;

2

worker_processes  1;

3

#error_log  /var/log/nginx/error.log  debug;

4

#error_log  /var/log/nginx/error.log  info;

5

6

events {

7

    worker_connections  1024;

8

}

9

http {

10

11

    server {

12

        client_max_body_size 70m;

13

        listen       80;

14

        root /srv/www;

15

16

#fuer php zeugs:

17

        location ~* \.php$ {

18

            fastcgi_index   index.php;

19

            fastcgi_pass    127.0.0.1:9000;

20

            include         fastcgi.conf;

21

            fastcgi_param   SCRIPT_FILENAME    $document_root$fastcgi_script_name;

22

            fastcgi_param   SCRIPT_NAME        $fastcgi_script_name;

23

        }

24

        location / {

25

            index index.php index.html index.htm;

26

        }

27

    }

28

}

Da weiss ich nicht wirklich ob das alles so passt. Kann/muss man da evtl. noch "ein Kabel fuer stdout ziehen"?

Gruss WK

Dergute W. schrieb:

Kann/muss man da evtl. noch "ein Kabel fuer stdout ziehen"?

Tut mir leid, das kann ich mangels Wissen & Erfahrung wirklich nicht beantworten - nginx hab' ich noch nie verwendet, und mein Wissen über php/apache ist auch eher an meinen Bedarf angepasst.

/Brauchst/ Du denn printf, oder könntest Du das, was Du ausgeben willst, nicht auch anders transportieren?

sprintf beispielsweise kann in ein char-Array ausgeben, und das wiederum sollte man mit var_dump sehen können.

Moin,

Harald K. schrieb:

Brauchst Du denn printf,

Nee, nicht wirklich. Ist nur irgendwie kein schoenes Gefuehl, wenn man schon bei den simplen copy+paste Beispielen aus der doku solche eigenartigen Effekte hat...

Gruss WK

Nun, das Beispiel funktioiert ja. Mit php. Nur nicht mit dem in Deinen Webserver integrierten php.

Ja, das ist nicht hilfreich, aber es ist zu befürchten, daß das irgendjemand so begründen wird.

Aber das ist halt auch ein Grenzfall, nämlich die Nutzung der Betriebssystemschnittstelle des C-Runtime-Systems, und nicht die Nutzung von C an sich. Wenn Du also vermeidest, Funktionen zu verwenden, die stdin/stdout/stderr verwenden, müsstest Du zurechtkommen können.

Moin,

Harald K. schrieb:

Nun, das Beispiel funktioiert ja. Mit php. Nur nicht mit dem in Deinen Webserver integrierten php.

Ja, das ist nicht hilfreich, aber es ist zu befürchten, daß das irgendjemand so begründen wird.

Wenns das tatsaechlich ist, dann isses voellig OK. Waere evtl. ein kleiner Hinweis bei dem offiziellen Beispiel nicht schlecht. Wenns aber prinzipiell funktioniert, nur bei mir - aus Gruenden - halt nicht, dann isses doof.

Aber das ist halt auch ein Grenzfall, nämlich die Nutzung der Betriebssystemschnittstelle des C-Runtime-Systems, und nicht die Nutzung von C an sich.

Wie ich das das erste Mal mitgekriegt hab, dass es ueberhaupt sowas gibt, habbich auch erstmal 3..4 Baukloetze gestaunt.

Gruss WK

Moin,

Damit ich's mal wieder find', wenn ich's brauch, und damit andere sich ordentlich amuesieren koennen, hier mal ein Beispiel, was ohne stdout auskommt und bei mir so tut, wie ich es erwartet habe: bla.c:

1

/* compile with

2

3

gcc -Wall -Wextra -shared -fPIC -o libbla.so bla.c

4

5

*/

6

7

#include <string.h>

8

#include <stdlib.h>

9

#include <syslog.h>

10

struct sbla {

11

    int inumber;

12

    char *snumber;

13

};

14

15

struct sbla return5(void) {

16

    struct sbla retval;

17

    retval.inumber = 5;

18

    retval.snumber = strdup("pfuempf");

19

    syslog(LOG_INFO,"in return5()\n");

20

    return retval;

21

}

22

23

void free5(struct sbla *pbla) {

24

    syslog(LOG_INFO,"in free5()\n");

25

    if (pbla) {

26

        free(pbla->snumber);

27

    }

28

}

bla.php:

1

<?php

2

$ffi = FFI::cdef("

3

struct sbla {

4

    int inumber;

5

    char *snumber;

6

};

7

8

struct sbla return5(void);

9

void free5(struct sbla*);" , "libbla.so");

10

$retval = $ffi->return5(); // call libfunction

11

$retstr = ffi::string($retval->snumber);

12

$retint = $retval->inumber;

13

var_dump($retval);

14

$ffi->free5(ffi::addr($retval)); //call libfunction

15

var_dump($retstr);

16

var_dump($retint);

17

?>

Gruss WK

Ob man ffi::cdef auch eine *.h-Datei unterjubeln kann? Dann könnte struct sbla und die Prototypen dort untergebracht und sowohl vom C-Compiler als auch ffi verwendet werden, was die Fehlerquote bei Änderungen reduzieren würde (keine mehreren, aktuell zu haltenden identischen Deklarationen an unterschiedlichen Stellen)

Moin,

Harald K. schrieb:

Ob man ffi::cdef auch eine *.h-Datei unterjubeln kann?

Ich glaub' schon. Das hier sieht danach aus: https://www.php.net/manual/en/ffi.examples-complete.php Nur bin ich halt dazu derzeit intellell noch nicht in der Lage ;-)

Gruss WK

Dergute W. schrieb:

Nur bin ich halt dazu derzeit intellell noch nicht in der Lage

Ach, Du schaffst das. Erst mal 'nen geruhsamen ersten Advent.

Generell: Du schreibst mittels C-printf direkt auf STDOUT in deinem PHP-Script. Früher™, wenn PHP als CGI eingebunden war, ging das mit in die Antwort des Webservers ein. War aber eher so eine Art dreckiger Nebeneffekt, dass das ging. Und hat auch nicht gut mit "output_buffering", "output_handler", "ob_start()&co" zusammengespielt.

mit FPM geht das garnicht mehr. Die Default-Config von FPM hat catch_workers_output=no Bedeutet: Alle deine STDOUT-Writes landen in /dev/null. Wenn du das auf "yes" stellst, landen deine C-printfs im Logfile. In der Webserver-Antwort landen sie nie.

Tja, so ist das halt. Wenn ich 12V für eine Fritzbox möchte und nur 400V/125A habe, funktioniert ein Zwischenstecker mit einem einfachen Stück Kabel dran, auch eher suboptimal.

Moin,

Ben B. schrieb:

funktioniert ein Zwischenstecker mit einem einfachen Stück Kabel dran, auch eher suboptimal.

Der wird aber auch nicht ausdruecklich im Benutzerhandbuch der Fritzbox als Beispiel fuer eine Stromversorgung erwaehnt.

Εrnst B. schrieb:

Die Default-Config von FPM hat catch_workers_output=no Bedeutet: Alle deine STDOUT-Writes landen in /dev/null. Wenn du das auf "yes" stellst, landen deine C-printfs im Logfile.

Wollt' ich spasshalber mal probieren, scheitert aber auch klaeglich. Mein php (8.2.9) erkennt diese Option weder in php.ini noch php-fpm.conf Naja, eh' wurscht. Was ich ans laufen bringen wollte, laeuft soweit.

Gruss WK