--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24383
--- Comment #6 from fxcoudert at gmail dot com 2005-10-21 19:49 ---
Fixed.
--
fxcoudert at gmail dot com changed:
What|Removed |Added
Status|NEW
--- Comment #5 from cvs-commit at gcc dot gnu dot org 2005-10-21 19:40
---
Subject: Bug 24383
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-10-21 19:40:32
Modified files:
libgfortran: ChangeLog
libgfortran/io : unix.c
Log
--- Comment #4 from fxcoudert at gmail dot com 2005-10-20 08:53 ---
This is fixed in mingw CVS. I will add the workaround with SHRT_MAX. It might
not be very efficient, but at least it's garanteed to work, and I think we'd
better be on the safe side.
--
http://gcc.gnu.org/bugzilla/s
--- Comment #3 from jblomqvi at cc dot hut dot fi 2005-10-15 20:43 ---
I think something like LONG_MAX might be appropriate. long should be the same
as size_t both on 32 and 64 bit mingw-windows, right (if 64 bit mingw indeed
exists at all)?
If LONG_MAX is too risky then at least INT_M
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2005-10-15 15:17
---
(In reply to comment #1)
> Short is too small. SSIZE_MAX is the signed version of size_t. If you can
> figure out what the type of size_t, you have figured out that too.
I only mentionned short because it's wri
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-15 13:54 ---
(In reply to comment #0)
> #ifndef SSIZE_MAX
> #define SSIZE_MAX SHRT_MAX
> #endif
Short is too small. SSIZE_MAX is the signed version of size_t. If you can
figure out what the type of size_t, you have figured out
