#define CURRPOS currpos
#define gettoken() gettoken(CURRPOS)
#define advpos(tok) advpos(&CURRPOS, &tok)
#define nexttoken(tok) \
do { \
tok = gettoken(); \
advpos(tok); \
} while ( 0 )
Maintainability be damned, I can make better macro soup than you
Obligatory /s
Simple question: what do you think about the tutorial?
I'm going through it right now, I'm still in the very early stages (my heavy procrastination means that I'm only just making a Logical Device), and I find that with every step I go forward I want to gnaw off another piece of my body.
I can't tell if this is because I dislike modern C++ to some extent, or because the tutorial's design of a Vulkan application is basically "Make a God Object, put every single itty bitty thing in there, then shove it under several layers of carpet".
Maybe that makes the tutorial better for learning purposes, because a God Object That Handles Everything In Tiny, Clean-Code-Esque Functions is easier to grasp than something laid out more evenly across multiple files with design decisions and questions to consider.
I'm asking because I genuinely can't tell if my frustrations are only with having to learn what a std::ranges::any_of() is, why the tutorial is telling me to declare lambda functions in a way that requires a thoughtful visit to the cppreference website for me to even begin to comprehend, or if the tutorial is doing a bad job in and of itself of telling me what its bits are. Why is there a PhysicalDevice.GetFeatures() AND a PhysicalDevice.GetFeatures2()? All of this is buried entirely under wraps, which leaves me dazed and confused.
For context, I'm talking about the tutorial in docs.vulkan.org, in case there are multiple starting tutorials that people might assume I'm talking about.
A specific SCP that I can't remember, potentially a Joke SCP, whose whole thing is that he inexplicably bypasses Site security measures (like a flower shop front) and enters a Site, only to escape just as inexplicably and harmlessly.
The article includes a military type Foundationer (a general?) who keeps encountering the guy and is hilariously baffled and confused by the anomaly.
The climax of the article is- well, I won't say, it was really funny though.
Which SCP was this?
Simple question. I can't give exact code examples, but I have a string_t struct with methods like:
string_t split(string_t *string, string_t *on)
string_t split_sp(string_t *string)
string_t split_crlf(string_t *string)
char *s_strstr(string_t *needle, string_t *haystack)
void trim(string_t *str)
So on and so forth.
I've been using these so far to parse HTTP reqeusts, and I have come up against many minor problems:
"What happens if a header field appears with no value? I'll have to explicitly check for it."
"What happens if a sender puts a bunch of CRLFs in the middle? I'll probably need a check for that."
"Oh God, how will I handle unrecognized header fields? How do I recognize them?"
These, and other questions, have been leaving me pissed.
I recall reading through the LLVM projects Kaleidoscope language thing, where they create a parser for said language. Said parser doesn't use anything close to what I am, instead reading character by character without fuss.
Similarly, on my last post made here, the way comments were worded reminded me of that method, and how it probably works better.
I have written only a small part of the parser, so it isn't too late to tear down and rebuild. Simple question: should I? Are there benefits to swallowing the input token by token instead of taking the overarching view my string_t functions provide? Or vice versa?
It would help if I'd upload the code, I know, but I don't want to bother with that until the project is completed/near-completion.
This is a fairly simple question:
You're on a Unix-like (for me, Linux), and you've got a File Descriptor that leads to some data. You don't know the length of the data (it's a TCP socket you're listening on), all you know is that it is ready to be read.
Do you:
A) Read an absurd amount of bytes of data into a (sufficiently large + 1) char array of your own, and if it overflows, handle it with mallocated memory or just reject the connection (like a monster)
Or
B) Just use existing kernel system calls to read and parse the data as necessary.
For context: this is about an HTTP server, and I have an internal string_t struct that I use for parsing, which needs a byte-length to be usable
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?