X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f
X-Recipient: djgpp AT delorie DOT com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :cc:content-type:content-transfer-encoding;
        bh=kG8LQLdNu2ydNnijOLT1mzp7Q80SH4hkpGXgcpASAaI=;
        b=XpaUrJOn1ZHooZIaLuwqjQgb0EsdPQ/1IiwmGoup/yf405HOxxxk3h9Zn5GRRbuWdT
         XPqt3Kh6D41z4wxAouPrHV+hBznNwd2Ig0Jo1daayQnpVGHVPJ6VkOi1+qV0EEMI8rYo
         COzb65FuGySsnpkEvgNlSHl8+4BQvo8Rpy+Yc=
MIME-Version: 1.0
In-Reply-To: <201109260029.41840.juan.guerrero@gmx.de>
References: <201109260029 DOT 41840 DOT juan DOT guerrero AT gmx DOT de>
Date: Mon, 26 Sep 2011 09:48:56 +0300
Message-ID: <CAA2C=vALYg1n8+-GJ_NbfYHqg-qjXmoSDuRchSCyXTFoh-niAg@mail.gmail.com>
Subject: Re: Isues concerning the INT 21 Windows95 - LONG FILENAME FUNCTIONS
 (0x71XX) implementation.
From: Ozkan Sezer <sezeroz AT gmail DOT com>
To: Juan Manuel Guerrero <juan DOT guerrero AT gmx DOT de>
Cc: djgpp AT delorie DOT com
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id p8Q6n0c4016473
Reply-To: djgpp AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

On Mon, Sep 26, 2011 at 1:29 AM, Juan Manuel Guerrero
<juan DOT guerrero AT gmx DOT de> wrote:
> OFYI, I have produced a second version of the patch presented the last time.
> This time the patch shall fix the same issues but for djdev 2.03.
>
> Suggestions, objections, comments are welcome.
>


Using gcc-4.4.7, I got two compilation errors, for both v2.03
and for v2.04 versions of your patches:


> diff -aprNU5 djgpp-2.03.orig/src/libc/dos/lfn/lfnshort.c djgpp-2.03/src/libc/dos/lfn/lfnshort.c
> --- djgpp-2.03.orig/src/libc/dos/lfn/lfnshort.c 1999-06-03 17:27:34 +0000
> +++ djgpp-2.03/src/libc/dos/lfn/lfnshort.c      2011-09-25 14:41:02 +0000
[...]
> @@ -19,10 +20,11 @@ char *
>  _lfn_gen_short_fname (const char *long_fname, char *short_fname)
>  {
>   __dpmi_regs r;
>   unsigned long tbuf = __tb;
>
> +  r.x.flags |= 1;  /* Always set CF before calling a 0x71NN function. */

First was here:

cc1: warnings being treated as errors
In file included from lfnshort.c:8:
../../../../include/fcntl.h: In function '_lfn_gen_short_fname':
lfnshort.c:25: error: 'r' is used uninitialized in this function
lfnshort.c:22: note: 'r' was declared here

> diff -aprNU5 djgpp-2.03.orig/src/libc/posix/dirent/opendir.c djgpp-2.03/src/libc/posix/dirent/opendir.c
> --- djgpp-2.03.orig/src/libc/posix/dirent/opendir.c     1998-11-15 13:48:38 +0000
> +++ djgpp-2.03/src/libc/posix/dirent/opendir.c  2011-09-24 20:31:52 +0000
[..]
> @@ -19,15 +20,19 @@
>  void
>  _lfn_find_close(int handle)
>  {
>   __dpmi_regs r;
>
> +  r.x.flags |= 1;  /* Always set CF before calling a 0x71NN function. */

And the second one here in the same way:

In file included from opendir.c:15:
../../../../include/dirent.h: In function '_lfn_find_close':
opendir.c:46: error: 'r' is used uninitialized in this function
opendir.c:44: note: 'r' was declared here
make[3]: *** [opendir.o] Error 1

In both cases directly setting flags to 1 instead of OR'ing, i.e.:
  r.x.flags = 1;  /* Always set CF before calling a 0x71NN function. */
... cures the flag.  Compiler is right, because r is not initialized
and OR'ing a value to a member of it seems wrong.  You need
to audit other places like this in your patch.

--
O.S.