bug-groff
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug #63079] #include <assert.h> or "assert.h" ?


From: G. Branden Robinson
Subject: [bug #63079] #include <assert.h> or "assert.h" ?
Date: Mon, 19 Sep 2022 15:53:26 -0400 (EDT)

Update of bug #63079 (project groff):

                Severity:              3 - Normal => 2 - Minor              
              Item Group:           Documentation => Lint                   
                  Status:                    None => In Progress            
             Assigned to:                    None => gbranden               
         Planned Release:                    None => 1.23.0                 

    _______________________________________________________

Follow-up Comment #1:

[comment #0 original submission:]
> Subject: #include <assert.h> or "assert.h" ?
> 
>   Some source files use '<assert.h>' and others '"assert.h"'.

I acknowledge the inconsistency.  However, on my system, neither choice seems
to prevent groff's assert.h from being located in preference to the standard C
library's.

Verifying this is straightforward: add a telltale string literal to the
assert() macro expansion and contrive an assertion failure, for instance in
src/roff/troff/input.cpp.

>   It should at least be documented in the file why the '"assert.h"' is used

Okay.  I can put a sentence from the commit message
<https://git.savannah.gnu.org/cgit/groff.git/commit/?id=642353ef06b3c2b49f74b71e0d5ecdfa866fe3de>
into a comment.

> and where that file exactly is.

This, I decline to do.  In the event the source tree should be reorganized
such that our "assert.h" moves, annotating its location just creates more
places that the notation can become invalid.

I expect even a novice developer to be capable of running "find -name
assert.h", or of using something like cscope, or of using a fancy IDE like
Atom that crawls the whole source tree and creates a navigation pane.  (So,
cscope reinvented in JavaScript and praised for its thoroughly unprecedented
innovation.  :-| )
 
> See also bug #63078.

That still looks to me like a consequence of a poorly managed working copy.


    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?63079>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]