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.bertr...@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/
