X-Authentication-Warning:	delorie.com: mail set sender to djgpp-workers-bounces using -f
Sender:	rich AT phekda DOT freeserve DOT co DOT uk
Message-ID:	<3FB287FC.6676B3A7@phekda.freeserve.co.uk>
Date:	Wed, 12 Nov 2003 19:20:28 +0000
From:	Richard Dawe <rich AT phekda DOT freeserve DOT co DOT uk>
X-Mailer:	Mozilla 4.77 [en] (X11; U; Linux 2.2.23 i586)
X-Accept-Language:	de,fr
MIME-Version:	1.0
To:	djgpp-workers AT delorie DOT com
Subject:	Re: Suggested improvements
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> <Pine DOT OSF DOT 4 DOT 58 DOT 0311121308420 DOT 11484 AT sirppi DOT helsinki DOT fi>
Reply-To:	djgpp-workers AT delorie DOT com

Hello.

Esa A E Peuha wrote:
> 
> 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.)

So the macro definitions of fgetc and fputc would be compatible with C99.
Please send a patch, if you have one.

> > 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?

So they're part of the thread-safe function option. I guess there's not much
point implementing them, then.

> 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.

We can't implement these functions until we support the Large File Summit.
(I'm not sure I've convinced MartinS yet, though. ;) ) Please see mails in the
archives about the Large File Summit.

> > > 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... ;-)

"There are bigger fish to fry." - There are more important things that need
fixing in DJGPP 2.04.

If you have some time, please choose something from the 2.04 status page:

    http://www.phekda.freeserve.co.uk/richdawe/djgpp/2.04/status204.html

If you're feeling really brave, perhaps you could integrate KB Williams's C99
maths stuff? Or work out why memalign segfaults, when using nmalloc?

Thanks, bye, Rich =]

-- 
Richard Dawe [ http://www.phekda.freeserve.co.uk/richdawe/ ]

"You can't evaluate a man by logic alone." -- McCoy, "I, Mudd", Star Trek

- Raw text -