build failure (Linux/Debian/Sid/gcc-8) commit bd926d18df4ec7182b3fa1

[bstarynk]

trafficstars

The commit bd926d18df4ec7182b3f (the latest one today nov.18th 2018 on master) fails to build:

cc -c  -Wall -Wextra -Wstrict-prototypes -Wshadow -Wpointer-arith -Wformat-security -Winit-self -Wcast-qual -Wcast-align -Wwrite-strings -Wnested-externs -Wredundant-decls -Werror -O3 -funsigned-char -Iinclude/ -DUSE_STACK_SIZE=102400 -oobj/httplib_ssl_get_client_cert_info.o src/httplib_ssl_get_client_cert_info.c
src/httplib_ssl_get_client_cert_info.c: In function ‘XX_httplib_ssl_get_client_cert_info’:
src/httplib_ssl_get_client_cert_info.c:101:15: error: cast between incompatible function types from ‘int (*)(X509 *, unsigned char **)’ {aka ‘int (*)(struct x509 *, unsigned char **)’} to ‘int (*)(void)’ [-Werror=cast-function-type]
  ASN1_digest( (int (*)(void))i2d_X509, digest, (char *)cert, buf, &ulen );
               ^
cc1: all warnings being treated as errors
make: *** [Makefile:148: obj/httplib_ssl_get_client_cert_info.o] Error 1

This is on Linux/x86-64/Debian/Sid the GCC compiler is gcc version 8.2.0 (Debian 8.2.0-9). The GNU libc is Debian GLIBC 2.27-8. The kernel is Linux version 4.18.0-2-rt-amd64

[lammertb]

I have uploaded a commit https://github.com/lammertb/libhttp/commit/d35e71f270875742dc106319732cad01f8dbc74e which should solve this problem. Can you please test if this is the case with your compiler?

[bstarynk]

That https://github.com/lammertb/libhttp/commit/d35e71f270875742dc106319732cad01f8dbc74e works. Thanks. BTW, is libhttp multi-threaded? Can it be used with either a fixed amount of threads (that is a thread pool created at init time) or with a single thread?

FWIW, I am using libonion in my bismon system. Read the draft bismon-doc.pdf report (a future deliverable of Chariot H2020 project) to learn more about it. But the fact that libonion creates threads might be annoying to me. I would prefer to manage them myself (and that might be a reason to switch to your library)

[lammertb]

Thanks for testing. It seems more modern versions of gcc default to C++ style prototype checking which is more strict than the C style checking. I changed to code to the C++ version which also works in C.

The current implementation is multi-threaded with a fixed amount of threads in the thread pool. The default number of threads is 50. You can change this value by setting the option "num_threads" to the desired value when calling httplib_start().

[bstarynk]

But can I access to the threads local stack? I might need to implement my garbage collector inside them.

Or at least, explain somewhere in details (perhaps in some future implementation-details.md file) how is that working and where is that implemented.

FYI, multi-threading and GC is tricky to do simultaneously (and require careful coding). See for example this stackoverflow question and read about Ravenbrook MPS

[lammertb]

If the system started successfully, an array of pthread_t structures with info for each individual thread is available in the structure to which a pointer is returned after the call to httplib_start().

So if you start with ctx = httplib_start(a,b,c) then ctx->workerthreadids will be the array of all the thread info structures. On systems which support POSIX threads, you can use the pthread_XXX functions to access the thread info. Externally modifying threads or their stacks may however have impact on stability of the http server.