Re: Cleaning up elkscmd and adding help text - Questions

[Alan Cox <alan@lxorguk.ukuu.org.uk>]

On Fri, 27 Mar 2015 18:59:28 +0100
Nils Stec <nils.stec@gmail.com> wrote:

> Wow i really belive that writing this took some time... Thank you, this 
> gave me a lot of hints, do's and don'ts.
> 
> I read The Art of Unix Programming, but you showed me that i forgot a lot ;)
> 
> I think I'm going to rewrite my patches with all that things in mind, 
> will send them soon.

One thing that is not obvious

stderr is unbuffered, and this is required by the C language standard

That means that

   /* A function so we don't have two copies of the same string, and
      we don't go mad counting bytes */
   static int writes(int fd, const char *s) {
	return write(fd, s, strlen(s));
   }

   write(2, argv[0], strlen(argv[0]));
   writes(2, " broke.\n");

is actually better than fprintf. Not that performance matters here , if
you are optimising the performance of error reporting then you've almost
certainly got the wrong priorities.


In the FUZIX case we've shared several Kbytes of some key binaries by
carefully avoiding the use of malloc, stdio and floating point. The same
ought to be the case for ELKS although some of the other changes we do
like avoiding floating point and if possible division of long types is
much much less important as the 8086 has multiply/divide instructions
even if only 16bit ones.

Several of the elks tools do

     blah = malloc(somefixedsize)
     do stuff
     free(blah)

which for a utility which always needs the buffer except in error cases
is actually massively less efficient than simply doing

      static uint8_t blah[somefixedsize];



The v7 utilities are well worth reading for their elegance and efficiency
of memory usage. It's quite old style C so can be harder to read than
modern ANSI C, but the techniques used are frequently very clever indeed,
and some like the v7 implementation of "dd" are masterpieces.

Alan