Date: Mon, 24 Nov 1997 21:41:38 -0500 (EST)
Message-Id: <199711250241.VAA28980@delorie.com>
From: DJ Delorie <dj AT delorie DOT com>
To: randym AT acm DOT org
CC: djgpp-workers AT delorie DOT com
In-reply-to: <3.0.1.32.19971124145927.007bbd60@yacker.xiotech.com> (message
	from Randy Maas on Mon, 24 Nov 1997 14:59:27 -0600)
Subject: Re: some proposed new fsext txh files
Precedence: bulk


> int _copy(const char* path1, const char* path2)

The correct way to do this is to emulate read and write, so that you
can copy from a file handled by one fsext to a different file
handled by a different fsext.

> The thin nature allows for programmers -- at their own risk -- to replace the
> @code{_open}, @code{_close}, etc. routines with their own and still be able
> to use many of the compiled library's functions.   Of course, the recommended
> method to add functionality to @code{_open}, @code{_close}, etc. is through
> @xref{file system extensions}.

The correct way to offer this is for the programmers to replace open,
close, etc.  I don't agree we should support or even mention this as
an option.

> @multitable @columnfractions .15 .15 .60

This must be new, eh?  Never heard of @multitable.  Will using it
cause backward compatibility problems when the documentation is
converted to HTML (texi2html) or Postscript (texi2ps), neither of
which support it?  I think it will.