From: Bruno Haible <haible AT ilog DOT fr>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <14996.6596.968351.656454@honolulu.ilog.fr>
Date: Wed, 21 Feb 2001 20:40:52 +0100 (CET)
To: "Juan Manuel Guerrero" <ST001906 AT HRZ1 DOT HRZ DOT TU-Darmstadt DOT De>
Cc: djgpp-workers AT delorie DOT com, Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
Subject: Re: gettext pretest available
In-Reply-To: <29F40F30739@HRZ1.hrz.tu-darmstadt.de>
References: <29F40F30739 AT HRZ1 DOT hrz DOT tu-darmstadt DOT de>
X-Mailer: VM 6.72 under 21.1 (patch 8) "Bryce Canyon" XEmacs Lucid
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

Thanks a big lot, Juan Manuel, for your patches. I'll need a few days to
digest them. Still I have two or three questions:

>   #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()?

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

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

>       *msdosdjgpp*)

Why not
        msdosdjgpp*)
? What comes before "msdosdjgpp"?

> It will also add the DJGPP specific files:
>   gettext-2001-02-05/djgpp/config.bat
>   gettext-2001-02-05/djgpp/config.sed
>   gettext-2001-02-05/djgpp/config.site
>   gettext-2001-02-05/djgpp/edtest.bat
>   gettext-2001-02-05/djgpp/fnchange.lst
>   gettext-2001-02-05/djgpp/readme
>   gettext-2001-02-05/djgpp/tscript.sed

It's fine that you put this into a subdirectory.

> It should be noticed that the file m4/gettext.m4 contains the following line:
>      [case " $CONFIG_FILES " in *" po/Makefile.in "*)
> I am not really familiar with Autoconf stuff so I will *not* claim that the
> above line is a bug but it should be noticed that the pattern:
>   *" po/Makefile.in "*
> will inhibit the use of the expression:
>   po/Makefile:po/Makefile.in-in

Looks like a bug I made. Thanks for noticing it.

>   MS-DOS 6.22 COUNTRY.TXT file
> available from:
>   <ftp://ftp.microsoft.com/peropsys/msdos/kb/q117/8/50.txt>

Perfect. You got the exhaustive list.

> The recoding on-the-fly of the installed .mo files works ok.

Great! Excellent work!

Bruno