From: "Juan Manuel Guerrero" <ST001906 AT HRZ1 DOT HRZ DOT TU-Darmstadt DOT De>
Organization: Darmstadt University of Technology
To: Bruno Haible <haible AT ilog DOT fr>
Date: Thu, 22 Feb 2001 21:04:17 +0200
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: Re: gettext pretest available
CC: djgpp-workers AT delorie DOT com, Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
In-reply-to: <14996.6596.968351.656454@honolulu.ilog.fr>
References: <29F40F30739 AT HRZ1 DOT hrz DOT tu-darmstadt DOT de>
X-mailer: Pegasus Mail for Windows (v2.54DE)
Message-ID: <2BBB1E41683@HRZ1.hrz.tu-darmstadt.de>
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 Wed, 21 Feb 2001 20:40:52 +0100 (CET), Bruno Haible wrote:

> >   #if ((__DJGPP__ == 2) && (__DJGPP_MINOR__ <= 3))
> >   /* DJGPP 2.03 and prior only supports C and POSIX. */
>
> What about DJGPP 2.04 or 2.1? Do these versions have a full
> setlocale()?
Good question. I don't know. If someone of the djgpp-workers envolved
with libc.a developement knows something about this, I will seriously
appreciate a response to this question. Meanwhile I will replace
  #if ((__DJGPP__ == 2) && (__DJGPP_MINOR__ <= 3))
simply by
  #ifdef __DJGPP__


> > Apart of this general points, the DJGPP port of GNU gettext shall be able
> > to process .po and other text files properly, regardless if they have been
> > created on DOS **or** on UNIX.
> > DJGPP software can be cross compiled from linux to msdos/djgpp so gettext
> > must be able to process files with dos-style EOL and unix-style EOL properly.
> > To achive this purpose *all* files will be read and written in binary mode.
> > ...
> > For DJGPP they will be set
> > to "rb" and "wb", for all other compilers, they will be set to "r" and "w".
>
> I fail to understand why this is necessary. ISO C 99 section 7.19.5.3
> says "r" and "w" are appropriate fopen() modes for text files. This
> works in other Windows environments like MSVC. Why is it a win to open
> in binary mode instead and then do the job of the text stdio in every
> program?
>
> Does reading a Unix (LF delimited) text file on DJGPP in "r" mode
> recognize the line delimiters and return "\n" for each of them? If
> yes, then there's no need for the binary I/O. If not, then DJGPP users
> have a problem anyway and should have tar/unzip/ftp/etc programs which
> deal with this.
Of course, you are right. All the pertinent DJGPP libc functions work as you have
described (they recognize CRLF *and* LF as '\n' if the file has been fopen()'ed
in text mode) makeing the code I have added redundant and superfluous. All the
code guarded by the OPENED_IN_BINARY_MODE macro has been removed. The READ and WRITE
macros are also superflous and have been removed. My fault.


> > On WinDos, switching unconditionally stdin/stdout into binary mode is a dangerous
> > issue **if** stdin is still connected to the console. This switching inhibits
> > Cntl-Z (software EOF), Cntl-C and Cntl-Break generation making it impossible
> > to the user to interrupt the program.
>
> Then the setmode() macro should take care of it.
I will assume you are makeing reference to setmode() macro defined in lib/system.h.
I will add a setmode() macro to system.h for djgpp:
1) DJGPP:
# define setmode(fd, mode)      do { \
                                  if (!isatty ((fd))) \
                                    setmode ((fd), mode); \
                                } while (0)
2) Posix:
# define setmode(fd, mode)      /* nothing */


> >       *msdosdjgpp*)
> 
> Why not
>         msdosdjgpp*)
> ? What comes before "msdosdjgpp"?
I have missed that config.charset extractes the operating system
from the host string. This converts i[3-7]86-pc-msdosdjgpp into
msdosdjgpp. All this implies that the pattern shall look like:
  msdosdjgpp)
This will be corrected in the next patch.
Thank you for all the bug fixes.

Regards,
Juan Mnauel Guerrero