On the Effectiveness of nonnull: Difference between revisions

Created page with "'''dankblog! 2021-11-05, 0236 EDT, at the danktower''' I add <code>nonnull</code> [https://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html anno..."
 
No edit summary
 
(5 intermediate revisions by the same user not shown)
Line 1: Line 1:
'''[[Dankblog|dankblog!]] 2021-11-05, 0236 EDT, at [[Viewpoint|the danktower]]'''
'''[[Dankblog|dankblog!]] 2021-11-05, 0236 EDT, at [[Viewpoint|the danktower]]'''


I add <code>nonnull</code> [https://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html annotations] to my [[C]] programs pretty religiously, making most frequent use of:
I add [https://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html annotations] to my [[C]] programs pretty religiously, making most frequent use of:


* <tt>const</tt> and <tt>pure</tt> -- facilitate subexpression hoisting and memoization
* <tt>const</tt> and <tt>pure</tt> -- facilitate hoisting and memoization
* <tt>malloc</tt> -- helps aliasing analysis and warning generation
* <tt>malloc</tt> -- helps aliasing analysis and warning generation
* <tt>warn_unused_result</tt> -- warning generation
* <tt>warn_unused_result</tt> -- warning generation
Line 13: Line 13:
* <tt>sentinel</tt> in the unfortunate situations where it's applicable (did you really need varargs there? that's not how we raised you, son)
* <tt>sentinel</tt> in the unfortunate situations where it's applicable (did you really need varargs there? that's not how we raised you, son)


and of course the ubiquitous <code>visibility("default")</code> (roughly) ala Microsoft's <tt>__declspec(dllexport)</tt>, which you ought be diligently employing on your shared libraries as [https://www.akkadia.org/drepper/dsohowto.pdf mr. drepper] taught you.
and of course the ubiquitous <tt>visibility("default")</tt> (roughly) ala Microsoft's <tt>__declspec(dllexport)</tt>, which you ought be diligently employing on your shared libraries as [https://www.akkadia.org/drepper/dsohowto.pdf mr. drepper] taught you.


<tt>access</tt> lets you get fine-grained, Ada-like controls on your variable access types, but if i were writing Ada i'd be fucking with <tt>gnat</tt> and working for Northrop Grumman and questioning my life choices.
<tt>access</tt> lets you get fine-grained, Ada-like controls on your variable access types, but if i were writing Ada i'd be fucking with <tt>gnat</tt> and working for Northrop Grumman and questioning my life choices.


anyway, <tt>nonnull</tt> is all over the place, but it's usually added merely to satisfy the spergy part of my brain that also forces me to compulsively run <tt>ls</tt> every time i switch between terminals just to, like, ensure nothing shifted around. a pleasant surprise today when it caught a bug in my existing code:
finally, <tt>nonnull</tt> is all over the place, but it's usually added merely to satisfy the spergy part of my brain that also forces me to compulsively run <tt>ls</tt> every time i switch between terminals just to, like, ensure nothing shifted around. a pleasant surprise today when it caught a bug in my existing code:


<syntaxhighlight lang="c">
<syntaxhighlight lang="c">
Line 57: Line 57:
</syntaxhighlight>
</syntaxhighlight>


OH SHIT, THERE GOES THE PLANET. that error check is completely pointless; indeed, the compiler might well elide it entirely (if <tt>buf</tt> is <tt>NULL</tt>, dereferencing it in the <tt>memdup</tt> line is undefined behavior, and the compiler can do whatever it wants. if it is not <tt>NULL</tt>, the check is pointless. thus work the mysterious minds of the compiler people). a static analyzer arguably ought have picked up on this (and i run several analyzers regularly), but there's good reasons why not, also.
OH SHIT, THERE GOES THE PLANET. that error check is completely pointless; indeed, the compiler might well elide it entirely (if <tt>buf</tt> is <tt>NULL</tt>, dereferencing it in the <tt>memdup</tt> line is undefined behavior, and the compiler can do whatever it wants. if it is not <tt>NULL</tt>, the check is pointless. thus work the mysterious minds of the Compiler People). a static analyzer arguably ought have picked up on this (and i run several analyzers regularly), but there's good reasons why not, also.


either way, adding <tt>nonnull(2)</tt> immediately generated the warning:
either way, adding <tt>nonnull(2)</tt> immediately generated the warning:
Line 70: Line 70:
and thus the inevitable "what? oh fuck what is this. no i just assigned to <tt>buf</tt>, you dumbass compiler, it could be <tt>NULL</tt> now, computer piece of shit, oh wait no fuck me in the ass, i assigned to <tt>*buf</tt> and checked <tt>buf</tt> like a witless simpleton asshole, fuck me in the ass twice, awww fuck piece of shit brain, thank you compiler you're a good compiler here's some more page cache, awww look at you chomping those pages you're my only friend, compiler."
and thus the inevitable "what? oh fuck what is this. no i just assigned to <tt>buf</tt>, you dumbass compiler, it could be <tt>NULL</tt> now, computer piece of shit, oh wait no fuck me in the ass, i assigned to <tt>*buf</tt> and checked <tt>buf</tt> like a witless simpleton asshole, fuck me in the ass twice, awww fuck piece of shit brain, thank you compiler you're a good compiler here's some more page cache, awww look at you chomping those pages you're my only friend, compiler."


'''next: "[[Four_questions_for_a_Wednesday|four questions for a wednesday]]" 2021-10-13'''
ps i ended up getting rid of the copy when i fixed this, too. w00t! =]
 
'''previously: "[[Four_questions_for_a_Wednesday|four questions for a wednesday]]" 2021-10-13'''


[[Category:Blog]]
[[Category:Blog]]