Hey Chris!
I was recently doing some research on more modern ways of writing C and
came across these videos:
- https://www.youtube.com/watch?v=QpAhX-gsHMs&t=3334s
- https://www.youtube.com/watch?v=lLv1s7rKeCM
A lot of the ideas that were mentioned have already been discussed on
this site, which is a good sign!
Now, I was wondering what are your thoughts on some of these C features:
- One can ensure that a pointer passed to a function is not null like this:
void print_char(const char str[static 1]);
What do you think of this addition and do you think it is useful?
The compilers seems to be able to detect NULL pointers that are passed
to the function, which seems like quite a nice benefit to me.
- More use of macros:
So, the talk got me thinking and led me down to writing macros as in
this gist:
https://gist.github.com/florianmarkusse/cf72a4d06b240aad3b06f0da5f91b87c
I was wondering, what is your opinion on these kinds of macros? I come
from a higher-level language and it looks like a Java try with resources
to me in this case, which seems quite nice to be able to do in C!
Moreover, one can expand these macros to, always benchmark a certain
piece of code, or make sure that accessing a shared variable is always
done using a mutex.
Lastly, the html-parser is coming along very well, and want to thank you
again for the feedback you have already provided, more to come if you're
interested!
Kind regards,
Flo
Thanks for the video links, Flo. I hadn't yet come across the first, and
there's a shocking amount of overlap with my own thoughts and writing the
past year — even down to signed sizes. The slide "API Design: Modern C" at
41:20 is a good summary, which emphasizes that "modern C" is more about
style (esp. ZII, allocator aware) and attitude than new language features
(emphasized _too_ much in the second video). That is, these techniques
have all been possible for a quarter century. I'll reference this video
myself in the future.
> What do you think of this addition and do you think it is useful?
At least for me, not useful, and the ugly syntax keeps me from using it
even casually. With one exception, I just don't have trouble passing null
pointers to functions that don't accept them. As Lucas Sas notes in the
first video, we should more often pass structures by copying, not by
address, so there wouldn't be a pointer in the common case anyway. When
other people's code is passing null pointers by accident, typically their
whole approach is confused ("How did you end up passing a null pointer to
strdup() And why are you using strdup()?"), and a static check won't help
much.
In Lucas's example with the split string function, the first argument is a
"str *" but in order to use the function you already have to be thinking
about what variable is being modified and how it's allocated. It's just
not a mistake you're going to make when using it, so in practice it
doesn't benefit from the not-null notation.
But if you've used it and it's helped you catch mistakes, go for it! That
means it's doing something for you.
The one exception is standard C functions that reject null pointers as a
special case for no good reason, like memcpy or memset. In these cases I
_want_ my function to accept null pointers (i.e. with a zero count), but
then I forget that the C standard has this footgun that requires special
checks. So, if anything, I want the opposite of "static 1" ("may be null")
in order to remind me about those checks.
One thing I can say for the second video is that I learned that GCC now
produces diagnostics for VLA arguments, which is nice. That plays well
with arena allocation if you use the alloc_size attribute, as it can check
against arena allocations too. So perhaps I should consider this not for
null pointer checks, but for static bounds checking at call sites.
> I was wondering, what is your opinion on these kinds of macros?
This is the sort of thing I call "macro abuse" and it's annoying when I'm
reading code using them. When reviewing code using these macros, I have to
keep in my head how they work. If I'm reading in a format where I can't
jump to definitions easily (e.g. on a web page, including MR reviews),
it's even more frustrating.
I'm more accepting of them in tests, which tend to have tedious repetition
that macros can compress away, and the definitions close to their use.
Your specific examples aren't so bad because they don't define or declare
variables visible outside the macro. Those are one of the worst cases, as
they hide variable origins from tools that don't expand macros (tags,
etc.).
> Lastly, the html-parser is coming along very well […] more to come if
> you're interested!
Great! I'm interested in seeing where you go with it.
(I hope the answer is correctly formatted like this, apologies in
advance if not)
Happy to hear I showed u a small new thing 🙂
> At least for me, not useful, and the ugly syntax keeps me from using it
> even casually.
I figured you may carry this sentiment seeing as you also stopped using
const qualifiers. I must say, the ugly syntax really does not help
indeed. Perhaps when I redo my API signatures I can find a use case. For
internal use, it seems unnecessary.
> This is the sort of thing I call "macro abuse" [..] I can't jump to
> definitions easily (e.g. on a web page, including MR reviews), it's
> even more frustrating.
I hadn't even thought of the possible MR review issues yet, reminds me
of over-use Java's annotations & friends. It's a good point definitely
to keep in mind. I think I will refrain mostly from using it, except
simpler cases, e.g.:
BENCHMARK {
...
}
These seem like fine additions and don't hide any part of the code under
benchmark.
>> Lastly, the html-parser is coming along very well […] more to come if
>> you're interested!
>
> Great! I'm interested in seeing where you go with it.
So far the code has gotten much nicer to read, 20% fewer LoC, and around
3x faster thanks in great part to your suggestions & posts here. Still
finishing up some loose ends, and want to do the fuzzing last as you
also recommend. After that, I think it should be in a decent place ^^
Have a good Sunday!