RE: newline conversion with EDITOR

Lurker comment: FILE * has drawbacks too. A particular limitation to keep
in mind with FILE* is that on some unices (solaris at least) the fd is
stored in the struct as a byte, which implies that a process which makes
heavy use of fd's won't be able to fopen.

This doesn't tend to be a limitation with your average CLI program, but in a
library context, It's not hard to imagine a failure scenario.

[it seems to be a short in FreeBSD].

-----Original Message-----
From: Greg Stein [mailto:gstein@lyra.org]
Sent: Mon, January 28, 2002 4:17 PM
To: Greg Hudson
Cc: dev@subversion.tigris.org
Subject: Re: newline conversion with EDITOR

On Mon, Jan 28, 2002 at 09:36:19AM -0500, Greg Hudson wrote:
> On Mon, 2002-01-28 at 04:57, Greg Stein wrote:
> > But I don't think we shold use FILE*. Using apr_file_t is portable. If
it
> > has drawbacks, then we should fix APR, not workaround it.
>
> I'm a little confused by this claim. FILE * is extremely portable; not
> only is it in ANSI C, but it's also in K&R C. There have been some
> historical stdio bugs, but none I know of which would actually affect
> Subversion.

All right, let me rephrase and say that "apr_file_t is a better mapping to
native OS file facilities, yet remains portable." We get to use native file
operations on Win32, BeOS, OS/2, and Netware, rather than their covers for
FILE*.

As Karl says, for consistency, we ought to continue using apr_file_t, and to
add any missing functionality.

> (Likewise, system() is part of ANSI C, so is also quite portable, but is
> worth ignoring for other reasons.)

system() isn't very portable to things like Windows. apr_proc_create()
handles process creation a lot better...

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org