View source for On the Effectiveness of nonnull

'''[[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:

* <tt>const</tt> and <tt>pure</tt> -- facilitate subexpression hoisting and memoization
* <tt>malloc</tt> -- helps aliasing analysis and warning generation
* <tt>warn_unused_result</tt> -- warning generation
* <tt>nonstring</tt> -- warning generation
* <tt>uninitialized</tt> in conjunction with <tt>-ftrivial-auto-var-init</tt>
* <tt>format</tt> -- warning generation for <tt>printf</tt>-style functions in conjunction with <tt>-Wformat</tt>, which ought probably be mandatory
* <tt>nothrow</tt> -- improves C++ code generation when exceptions are enabled. ought be on every C function you declare that doesn't call C++ (beware user-provided function pointers!)
* <tt>returns_nonnull</tt> -- improves code generation and static analysis
* <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.

<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:

<syntaxhighlight lang="c">
// for now, we just run the top half of notcurses_render(), and copy out the
// memstream from within rstate. we want to allocate our own here, and return
// it, to avoid the copy, but we need feed the params through to do so FIXME.
int ncpile_render_to_buffer(ncplane* p, char** buf, size_t* buflen){
  if(ncpile_render(p)){
    return -1;
  }
  notcurses* nc = ncplane_notcurses(p);
  unsigned useasu = false; // no SUM with file
  fbuf_reset(&nc->rstate.f);
  int bytes = notcurses_rasterize_inner(nc, ncplane_pile(p), &nc->rstate.f, &useasu);
  pthread_mutex_lock(&nc->stats.lock);
    update_render_bytes(&nc->stats.s, bytes);
  pthread_mutex_unlock(&nc->stats.lock);
  if(bytes < 0){
    return -1;
  }
  *buf = memdup(nc->rstate.f.buf, nc->rstate.f.used);
  if(buf == NULL){
    return -1;
  }
  *buflen = nc->rstate.f.used;
  return 0;
}
</syntaxhighlight>

ignore the nonsensical mouthfoam in the opening comment. do you see the bug? it ought require no knowledge of the content beyond standard ANSI C to do so.

...see it yet?

<syntaxhighlight lang="c">
  *buf = memdup(nc->rstate.f.buf, nc->rstate.f.used);
  if(buf == NULL){
    return -1;
  }
</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.

either way, adding <tt>nonnull(2)</tt> immediately generated the warning:

<pre>
/home/dank/src/dankamongmen/notcurses/src/lib/render.c: In function ‘ncpile_render_to_buffer’:
/home/dank/src/dankamongmen/notcurses/src/lib/render.c:1561:5: warning: ‘nonnull’ argument ‘buf’ compared to NULL [-Wnonnull-compare]
 1561 |   if(buf == NULL){
      |     ^
</pre>

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'''

[[Category:Blog]]