~skeeto/public-inbox

2 2

compile checking of NULL & macro magic

Details
Message ID
<PRAP250MB0616366CCDE1D122491CD56989D4A@PRAP250MB0616.EURP250.PROD.OUTLOOK.COM>
DKIM signature
missing
Download raw message
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
Details
Message ID
<20231020180056.fztpa6nontl3pvwn@nullprogram.com>
In-Reply-To
<PRAP250MB0616366CCDE1D122491CD56989D4A@PRAP250MB0616.EURP250.PROD.OUTLOOK.COM> (view parent)
DKIM signature
missing
Download raw message
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.
Details
Message ID
<PRAP250MB06168C51416388F72A52EC5E89D9A@PRAP250MB0616.EURP250.PROD.OUTLOOK.COM>
In-Reply-To
<20231020180056.fztpa6nontl3pvwn@nullprogram.com> (view parent)
DKIM signature
missing
Download raw message
(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!
Reply to thread Export thread (mbox)