From: <ams AT ludd DOT luth DOT se>
Message-Id: <200301251243.h0PChVH22366@speedy.ludd.luth.se>
Subject: Re: ssize_t: int -> signed long [PATCH]
In-Reply-To: <3E304571.BFA087FF@phekda.freeserve.co.uk> "from Richard Dawe at
 Jan 23, 2003 07:41:37 pm"
To: djgpp-workers AT delorie DOT com
Date: Sat, 25 Jan 2003 13:43:31 +0100 (CET)
X-Mailer: ELM [version 2.4ME+ PL78 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
X-MailScanner: Found to be clean
X-MailScanner-SpamScore: s
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

According to Richard Dawe:
> > >     int function(__FSEXT_Fnumber func_number, int *rv, va_list args);
> > 
> > Perhaps we should change FSEXT to return an ssize_t.
> 
> If we're going to change it, I would prefer a long long, since then it will
> cope with return values from anything (llseek, etc.). But that's not binarily
> compatible, so what you suggest is better. Unless we're not worried about
> binary compatibility with FSEXTs?

If we don't change it to long long, then a footnote or something
explaining how to handle that int successfully in the llseek FSEXT
handler (basically map [INT_MIN, INT_MAX] to [-1, 2^32-2] or back)
should be written.


Right,

						MartinS