X-Authentication-Warning: delorie.com: mail set sender to djgpp-workers-bounces using -f
Date: Wed, 12 Nov 2003 14:01:42 +0200 (EET)
From: Esa A E Peuha <peuha AT cc DOT helsinki DOT fi>
Sender: peuha AT sirppi DOT helsinki DOT fi
To: djgpp-workers AT delorie DOT com
Subject: Re: Suggested improvements
In-Reply-To: <3FB15D6E.E3FFCC07@phekda.freeserve.co.uk>
Message-ID: <Pine.OSF.4.58.0311121308420.11484@sirppi.helsinki.fi>
References: <Pine DOT OSF DOT 4 DOT 58 DOT 0311071212520 DOT 5324 AT sirppi DOT helsinki DOT fi>
 <3FB15D6E DOT E3FFCC07 AT phekda DOT freeserve DOT co DOT uk>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

On Tue, 11 Nov 2003, Richard Dawe wrote:

> Hello.
>
> Esa A E Peuha wrote:
> >
> > I have been thinking of some small possible improvements to djgp's libc.
> >
> > First of these is fgetc/getc and fputc/putc.  These two pairs of
> > functions are completely identical, so maybe we could define fgetc to
> > getc and fputc to putc in stdio.h if ANSI allows it (if not, then
> > fgetc/fputc might be just stabs to getc/putc).
>
> (I think you mean "stubs" rather than "stabs".)

Oops. Yes, I mean stubs.

> fgetc and fputc are functions. I don't think they can be macros. getc and putc
> can be macros.

SUSv3 description of stdio.h says that all four must be available as
functions and may also be available as macros.  (If fgetc and fputc are
macros, they must not evaluate their arguments more than once.)

> If you're looking for something to do in <stdio.h>, perhaps you could look at
> implementing the *_unlocked macros described in POSIX/Single Unix
> Specification v3 (SUSv3). You can download SUSv3 for free at
> http://www.opengroup.org/ or http://www.unix.org/ (I forget which is quicker).

There's not much to implement; [ge|pu]tc[|har]_unlocked functions (can't
be just macros) would be identical to non-unlocked versions, and the
associated f[|try|un]lockfile functions would be no-ops.  But since
these are optional (that is, applications must test their existence at
configure time), is there any point in implementing them?

I think that it would be more useful to implement fseeko and ftello
(versions of fseek and ftell that use off_t instead of long) which are
not optional.

> > Second, do we ever expect close do something that _close can't do?  I'm
> > asking this because now close is a stub to __close which calls _close...
> > (This reminds me of the joke that every computing science problem can be
> > solved by adding a layer of indirection. :-)  It seems to me that it
> > would be more sensible to define close to _close in libc/stabs.h.
>
> Is there any point changing this? What we have is equivalent to a stub.

More like two stubs, which is unoptimal in both size and speed, but
maybe I worry too much... ;-)

-- 
Esa Peuha
student of mathematics at the University of Helsinki
http://www.helsinki.fi/~peuha/