Hi all,
Sorry for the late reply!
Laslo:
1. I'm in period of experiment with different stuff, including self
hosting, I bought a
https://www.pine64.org/devices/single-board-computers/rock64/ 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
functions.
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!
Kurt:
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.
Sylvain:
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 <sylvain.bertrand_AT_gmail.com> 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,
Adi,
Freelance Developer
http://adi.tilde.institute/
Received on Fri Jul 05 2019 - 22:47:30 CEST