[klibc] stdio

[H. Peter Anvin]

maximilian attems wrote:
> hello hpa,
> 
> woow you are quick!!
> 
> On Thu, 16 Aug 2007, H. Peter Anvin wrote:
> 
>> I have experimentally done a branch of klibc with buffered stdio
>> support.  It seems to add about 1.5K of code (for x86-64), which isn't
>> so bad, except that it means that *every* program now pulls in stdio,
>> which in turn depends on malloc() and some other pieces of code.
> 
> -# define BUFSIZ 4096
> +# define BUFSIZ 65536
> hmm didn't you set BUFSIZ quite high?
> 
> shouldn't that get a default config variable with setable values
> between 128 and 8192?
> 

Yes, it's set quite high.  I have assumed here klibc binaries are
generally not going to stay around while the main system is executing.
In that sense, 64K isn't all that much.  I could drop it down, of
course, but if execution footprint is a real issue then the whole stdio
buffering is IMO highly questionable.

> +/* Actual FILE structure */
> +struct _IO_file {
> +       struct _IO_file *prev, *next;
> +       off_t filepos;          /* File position */
> +       char *buf;              /* Buffer */
> +       int offset;             /* Offset to data in buffer */
> +       int bytes;              /* Data bytes in buffer */
> +       int bufsiz;             /* Total size of buffer */
> +       int fd;                 /* Underlying file descriptor */
> +       int flags;              /* Error, end of file */
> +};
> 
> hmm could offset, bytes and bufsize not be uint32_t?

Uhm... uint* types are usually to fit to an external ABI; that's not
really the case here.  The values are small enough that signed versus
unsigned shouldn't matter anyway.

> what for the *prev, is not *next enough, why the doubly linked decision?

Single linked lists require a whole-link traversal in order to remove an
item.

	-hpa