u/SheikHunt

In C++, when you want to make a struct or class or function that acts upon/uses a type whose features are generally unimportant, you use templates. For example std::vector<T>, and that (as far as I'm aware), tells the compiler that whenever it sees something like std::vector<AStruct>, it should generate code that acts on a vector of AStructs. This is a useful feature that C doesn't have (which I'm fine with, there are workarounds, especially a really fucky workaround I saw on SO).

I'm assuming that one advantage of C++'s templates is that it can use SIMD, vectorized instructions, and all the other fun stuff that make a lot of actions faster, because it knows the size of std::vector<int> vs std::vector<string>.

In C, when I try to make type that's generic (especially a data structure like a priority queue), I have to have a (usually) void * and a size_t, one for where the data is, and for how big one object of that data is.

Here comes my question:

Can most C compilers, based off of the usage of the structs, realize that "Oh, this is basically always guaranteed to be used on the type int32_t, so I can just compile it with that in mind", or do I have to un-Genericify my struct for that?

(Note: I am aware of using Macros to achieve technically-generic-but-typed structs, however there are apparently issues with "eating your own dog food" when you try to make a queue of queues, for example. I'd rather avoid that, even if I probably won't eat my own dog food)

Hi! I'm writing an HTTP server!

I've hit a tiny mental bump after reading up on a few well-known exploits that applications or libraries like mine suffer from, namely Directory Traversal Attacks.

I was already aware of DTAs, and had plans for how to keep them from happening, but after reading some more Wikipedia articles (definitely not the canonical way to do OpSec, I'm sure), I have been hit with a question:

How does fopen() (and OS-specific functiona like dlopen()) expect its string argument? Obviously, a NUL-terminated string, but what encoding? UTF-8? UCS-2? ASCII? AnotherFormatName? Is it OS-specific? Is it Just Some Bytes? What about the slashes and OS-specific features like Windows's "C:\"?

More importantly, if I were handing strings over to system calls and I/O functions, how would I deal with deliberately and maliciously UTF-8-non-compliant text? Aside from deliberately ignoring any input that isn't UTF-8-valid, I mean.

TL;DR: Filesystems; how they encode?

Apparently, there exists a program that can turn some C programs into Rust ones, more specifically it can be used to make C structs usable in Rust.

I am writing an HTTP server that, with this feature, its usability would be far better than otherwise. Specifically, there is an http.h file that includes all necessary information for some other language to use to understand a struct and its values.

With that said, should I use C's types (short, int, long, etc.) Which you famously never know how big they are, or should I use the types given by <stdint.h> and any similar header files that give you portable-ish int sizes?

Also, bonus question: Does any version of the described program exist for other languages? One that can take some C code relating to structs, or a compiled object file or other binary that contains information about a struct and maybe even the enums used therein, and produce a language-appropriate version of that struct for ease of use?

The question explains itself, but for context:

I am writing an Over-Engineered HTTP server for fun's and learning's sake, and I have hit a conceptual roadblock.

Currently, the server works thusly:

One (1) thread sits on a port and accept()s incoming requests and adds them to a queue, then pthread_cond_signal()s a condition that...

... Four (4) threads (request handlers) are pthread_cond_wait()ing on, one of whom will pick up the request and parse it.

Here comes the issue:

Similar to that the server simply adds each request to a queue, I want each request handler to, once it's parsed a request, hand it off to some HTTP_<method> function, then pick up the next request from the queue, only returning to the original point of execution (the point where HTTP_<method> was called), where it then returns a response.

The only two ways that comes to mind of doing this, one of them require N more threads sitting on another queue, which I feel weird about, and the other requires some Macro Fuckery that I found on a Github repository then lost, so Idk if it even is feasible.

How do I go forward from here?

TL;DR: Async Await for C; good, bad, or disgustingly ugly? Potential other solutions?