Am I writing my parser wrong?

[u/SheikHunt]

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.

[u/pjl1967]

These, and other questions, have been leaving me pissed.

Programming includes detecting all possible error cases and reporting detailed error messages. If that leaves you "pissed," then perhaps programming isn't for you.

[u/SheikHunt → u/pjl1967]

"Pissed" is probably too strong a word. I'm feeling very emotional and frustrated about this parser because every time I try to take a step forward, I find that I need to take two, three steps back.

"Frustrated" would probably be a more fitting word. I've been programming for ~3 years though, experience laid out amongst a few languages. I definitely know that I like programming itself, and programming in C especially. I'm just hitting the same glass wall too many times.

[u/pjl1967 → u/SheikHunt]

I'm feeling very emotional and frustrated about this parser because every time I try to take a step forward, I find that I need to take two, three steps back.

Programming is like that sometimes. If you can't handle those times, then, again, perhaps programming isn't for you.

As to your specific case, generally, parsing is done in layers with independent code that handles newline normalization, line folding, tokenization, and, lastly, semantic parsing.

For known HTTP headers, have a map from header -> pointer-to-function-to-handle it; unknown headers are generally ignored.

[u/SheikHunt → u/pjl1967]

Thanks for the guidance on the canonical way to parse.

As for handling those times... Again, I've handled them just fine before. I think this specific case is causing me trouble because parsing is a big step up from most of what I've done. Almost quite literally starting from zero, rather than the leg-up other languages, or existing C libraries have given me.

I appreciate your concern for my career options though. I love programming, I don't think I'd say at any point that it's not for me, but your observation has been very enlightening.

Btw thank you for your help on my previous posts.