Re: [dev] URI Parser

From: Adrian Grigore <>
Date: Fri, 5 Jul 2019 23:47:30 +0300

Hi all,

Sorry for the late reply!


1. I'm in period of experiment with different stuff, including self
hosting, I bought a so ,
I'll maybe host a git or cvs (I get it, I never worked with cvs
ever so I think it's a good idea to to work with it a while just to
understand where software versioning mostly started). Thanks for
attaching the files.

2. I usually add LICENSE files, thanks for the suggestion!

3. Thanks for the suggestion, wasn't aware of the convention!

4. I already have a test program, I don't know if it's a good idea
to include it the actual package or have it separately. Also, I don't
know if it's a good idea to have tests, I can write shell scripts for
the testing, simple stdin stdout testing, but it looks like in C land
most people don't write tests. I was thinking of copying the Go test
suite, also your forgot to mention the [0]. :)

5. In naming, I was looking at the `libc` in OpenBSD, where functions
are stored in single files, that's why the file is named `parseuri.c`,
I'm thinking if it might be good practice to have it as separate

6. I was thinking I can maybe use the standard `errno` mechanism if
possible, somehow...

7. I usually start programs with dynamic memory allocations and
afterwards decide on default sizes. I somehow missed checking for
mallocs and strdups, weird, thank you! Later edit: you caught me
in the middle of the migration!

8. Yes, I've been given the same advice by somebody else and I can
understand why it could be a good idea. I was reading Go code at the
time and returning structures seemed elegant. It is questionable
indeed, I know at least one function in the standard library that does
the allocation itself, `strdup`. Later edit: If I don't alloc in the functions,
I guess it's a good idea to return structures?

9. I usually leave simplifications for the last moment, I'd rather not
worry about simplicity until it actually works at least in a decent
matter. I think that's fair. I think comments are also reviewable also
I don't think the code has to necessarly be clean if it's in an
incomplete state, cleaning up also comes at the end also
simplifications. I posted mostly to make sure I don't do something
really stupid. It's good to ask.

Thanks for your feedback!


That's one of the reason I posted, making sure I haven't missed an
existing library. Thank you!. Links don't work tho.

I think Plan9 had a URI parsing library (I really can't find it right
now) and I think they used regex, I'd rather not.

The incomplete parts are are query parsing, but I think I'm going to
leave that as simple character array, validations starting from and
including hostname, cleaning up and simplifications.


Thanks for pointing to the guideline, I mostly follow the Suckless
coding standards and get a lot of inspiration from reading the code.

I was thinking my use of `goto`s was elegant,
I don't think it's confusing.

Thanks all for the feedback, I'll continue working on it when I'll feel
like it, I'd rather not force myself. :)

On Thu, Jun 13, 2019 at 1:26 PM <> wrote:
> Hi,
> Try to follow roughly the coding guideline from the linux kernel.
> lower case, no typedefs, sized types (u8, u32, s32...) and cast in case of the
> use of an external API, use of goto for "very sequential code error
> management", etc.
> I do even remove keywords from the already way too rich syntax of C:
> - one loop statement: #define loop for(;;)
> - no enum.
> - try to avoid qualifiers (const...).
> --
> Sylvain

Thank you,
Freelance Developer
Received on Fri Jul 05 2019 - 22:47:30 CEST

This archive was generated by hypermail 2.3.0 : Fri Jul 05 2019 - 23:00:09 CEST