klibc - Aug 2007 - stdio

Hi,

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.

I have not yet implemented fscanf(), however, which may cause additional
bloat.

As of this point, I'm a bit undecided about stdio in klibc.  If you care
about it, you may want to check out the stdio branch from the klibc
repository and try it out.

	-hpa

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?

+/* 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?

what for the *prev, is not *next enough, why the doubly linked decision?
 
> As of this point, I'm a bit undecided about stdio in klibc.  If you
care
> about it, you may want to check out the stdio branch from the klibc
> repository and try it out.
> 
> 	-hpa
haven't build tried yet, just very curiusly eyed!! :)
i'll give it more next days.

--
maks