delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1997/03/09/11:04:54

Date: Sun, 9 Mar 1997 17:48:49 +0200 (IST)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To: James McCann <jmccann AT junkmailwolfenet DOT com>
cc: djgpp AT delorie DOT com, DJ Delorie <dj AT delorie DOT com>
Subject: Re: File system extensions -- write() doesn't work?
In-Reply-To: <331F8657.68B1707@junkmailwolfenet.com>
Message-ID: <Pine.SUN.3.91.970309174801.26812N-100000@is>
MIME-Version: 1.0

On Thu, 6 Mar 1997, James McCann wrote:

> The attached program shows  behavior I did not expect.  It installs
> a handler for file descriptors returned by __FSEXT_allocate_fd and 
> installs the handler w/ FSEXT_set_function.  When the write function 
> is called, the handler is called only for the first write.  Read and 
> close work as expected, and if the write() calls are replaced w/ calls
> to _write(), the handler is called as expected.  I am using the libc.a
> from djdev201.zip dated 10/31/96.
> 
> Is this a bug, or am I doing something wrong?

You might say it's a bug or a feature, it all depends on your views.
`write' only calls your handler if the file handle is put into binary
mode.  For text-mode handles, `write' puts the characters directly
into the transfer buffer, while adding a CR after each LF on the fly.
Call `setmode' on your handles after they return from
`__FSEXT_allocate_fd', and it will work, like so:

		setmode (fd[0], O_BINARY);

I guess `__FSEXT_allocate_fd' should have opened the handle in binary
mode.

Btw, it's not a good idea to call `fprintf' inside the handler: it
could cause an infinite loop (since `fprintf' itself eventually calls
`_write'); if you need to do debugging output, use `cprintf', `cputs'
etc.

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019