Thanks for the report. This is fixed in eb4320fc.
I also added a few other checks to make sure that structs have at least one member and the flexible array member (if present) is last.
REPORTED RESOLVED FIXED
Seems like an interesting project, but pp-1 is not a C preprocessor. Rather, it looks to be some sort of document templating program.
This was fixed in 28146f5e.
REPORTED RESOLVED FIXED
Yes, I think that should work. You could also go further and keep a parallel array containing a linked list of free pollfd indices. When a client exits, just update its index in the free list with the previous head, and when you accept a new client, check if there are any free pollfds before reallocating the array. I'm not sure if the extra complexity is worth it over just scanning the array for a free index, though.
I'm not sure if it meets your criteria, but I'd be interested in porting gmnisrv to bearssl.
I noticed that if gmniserve ever has to realloc the fds array because it had over 1024 simultaneous clients, then all the pollfd pointers saved in client structs become invalid.
Additionally, if two clients (1 and 2) are being served simultaneously and then client 1 disconnects first, then client 2's pollfd is shifted earlier in the array, but its pollfd pointer is not updated.
The first issue can be solved by keeping track of array indices instead of pointers. To solve the second issue, upon client disconnection you could loop through all subsequent clients and adjust their pollfd index.
This is required for
struct epoll_eventon Linux x86_64: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/include/uapi/linux/eventpoll.h#n66
Right now, cproc can segfault if it tries to call a function with a
long doubleargument. We currently detect a missing representation when we try to emit it, but we should actually just prevent construction of a value with no QBE representation in the first place.
Another manifestation of this bug is if you try to call a function returning
long double, ignoring the result. This should be a compile error, but cproc compiles it as if it were
repr == NULLfor function calls to indicate that it has no return value, so we can't tell if we are calling a function with no return value, or the return value has no representation.
To fix this, perhaps we could add a special
funccallfunction to create call instructions. There is already some call-specific code in
funcinst, so this is probably the right thing to do.
REPORTED RESOLVED INVALID
I'm guessing you had some other flag that was not supported. I've run into this occasionally, too, since cproc didn't make it clear which option was problematic. C compilers are typically passed a lot of options, which makes it difficult to figure it out by inspecting the full command.
I pushed a commit that should help with this.