From: arne@vajhoej.dk   
      
   On 7/3/2025 4:07 PM, Dan Cross wrote:   
   > In article <1046hc5$62th$2@dont-email.me>,   
   > Arne Vajhøj   wrote:   
   >> On 7/3/2025 1:40 PM, Dan Cross wrote:   
   >>> As the main logic is the same in each case (find out the buffer   
   >>> size, allocate, and then assign and return), and the only real   
   >>> difference is in finding out the buffer length, your code would   
   >>> be more readable with some helper functions that you delegated   
   >>> to.   
   >>   
   >> As states in the comments then it was a design goal to have   
   >> simple code blocks - no nested if's, no functions - for a given   
   >> context just 1-10 lines of code.   
   >   
   > That's a bad design goal.   
   >   
   > This sort of organization leads to lots of duplication and tends   
   > to produce code that is overly verbose and fragile, where one   
   > section may be updated and the others skipped or missed.  A   
   > little bit of duplication for the sake of comprehensibility is   
   > ok, but this is excessive.   
      
   It is very easy to read this way.   
      
   Just scan sequentially down until one find the relevant   
   #if context and then read 1-10 lines sequentially.   
   No jumping up and down.   
      
   >>> You refer to `_PATH_DEVNULL` but do not `#include `, as   
   >>> required by POSIX.   
   >>   
   >> This must support non *nix systems (as an example   
   >> VMS !!) - config.h is expected to provide that with the rest.   
   >   
   > If copyright dates are anything to judge by, `` has   
   > been a thing since 1989, but I was wrong in that it is not   
   > actually in POSIX: it is a BSD extension, though common.   
      
   This code should also work on non-*nix. It does not matter   
   if all or most *nix has had it since 1989.   
      
   > In general, it is good practice and good hygiene in C programs   
   > to `#include` the header files that are documented to define the   
   > symbols and types that you use in your program, instead of   
   > relying on transitive includes to populate things ambiantly via   
   > e.g. `config.h`.   
   >   
   > Regardless, in that case, you shouldn't use `_PATH_DEVNULL`.   
   > Note the leading `_`: that signifies a reserved identifier,   
   > which is not something you should be defining yourself.  If you   
   > want to punt this to e.g. config.h, better would be to define a   
   > new name (say, `TDS_PATH_DEVNULL`) and use that.   
      
   This has to fit into an existing project that has its   
   way to setup things.   
      
   I also think that its way makes sense. It would not be good   
   to start putting OS specific includes/defines into lots   
   of C files. That is what the configure process is supposed to   
   handle.   
      
   Arne   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)