Sender: rich AT phekda DOT freeserve DOT co DOT uk
Message-ID: <3E2FB5F0.B7FD75FC@phekda.freeserve.co.uk>
Date: Thu, 23 Jan 2003 09:29:20 +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: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
CC: djgpp-workers AT delorie DOT com
Subject: Re: ssize_t: int -> signed long [PATCH]
References: <Pine DOT SUN DOT 3 DOT 91 DOT 1030123081522 DOT 15630C AT is>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: djgpp-workers AT delorie DOT com

Hello.

Eli Zaretskii wrote:
> 
> On Wed, 22 Jan 2003, Richard Dawe wrote:
> 
> > * The _cnt member of FILE is now a long. In src/libc/ansi/stdio/filbuf.c
> >   &f->_cnt is passed to __libc_read_termios_hook, which expects a ssize_t
> >   argument. &f->_cnt being an int * cannot be converted without typecasts
> >   to ssize_t *. Hence I changed f->_cnt to be a long.
> 
> Why not make it ssize_t?  That way, we avoid any breakage in the future,
> if ssize_t is changed.

I thought about that and it should work. But then we pollute <stdio.h> with
ssize_t. Is that good, bad or ugly? If there are no objections, then I'm happy
with ssize_t for _cnt.

> > * In write() the return value 'rv' was an int. But it's used to store
> >   both an int and a ssize_t. Now they are not the same as int,
> >   two variables are needed - 'i_rv' and 'ss_rv' for int and ssize_t
> >   respectively.
> 
> Again, why not change the return value to ssize_t?  Will that break
> anything?

The return type is already ssize_t. The problem is that there are two possible
return values: one from FSEXT, one from normal operation. The normal operation
path can work with ssize_t. The FSEXT call returns an int:

    int function(__FSEXT_Fnumber func_number, int *rv, va_list args);

So there are now two return value variables used in the code: i_rv for the
FSEXT-related code and ss_rv for the normal operation.

Bye, Rich =]

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