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=Bf5D66xiDghU8yI0fKmnfrX4J04r+fwfjaDvXIMUXa4=;
        b=rIpvZvIhdd/UYmngYPvF7rurYNSlXwzmjgpqXT2idHvgtyvdZwcfY5/BHOex3kOc2k
         Z062pv8enPCHOUHVROam+ZWtTSeeULBGjC65O533fb7mNiVWK+6T+99AzuaT9awENBgJ
         rby6w8OfOu+vBi0W9opHIKXU5Qy4VUBPAqiH8=
MIME-Version: 1.0
In-Reply-To: <201109262218.12243.juan.guerrero@gmx.de>
References: <201109260029 DOT 41840 DOT juan DOT guerrero AT gmx DOT de>
	<CAA2C=vALYg1n8+-GJ_NbfYHqg-qjXmoSDuRchSCyXTFoh-niAg AT mail DOT gmail DOT com>
	<201109262218 DOT 12243 DOT juan DOT guerrero AT gmx DOT de>
Date: Mon, 26 Sep 2011 23:30:54 +0300
Message-ID: <CAA2C=vDwfo7MoA=Nqsc1OrTSbdxuDc4i4OLtR=3FrELw9632kA@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=UTF-8
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id p8QKUvqk009278
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 11:18 PM, Juan Manuel Guerrero
<juan DOT guerrero AT gmx DOT de> wrote:
> Am Montag, 26. September 2011 schrieb Ozkan Sezer:
>> 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:
> [snip]
>> > + �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
> [snip]
>> 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.
>
> Sorry but I cannot reproduce this.  I have checked out the repository today and
> compiled with gcc 4.6.1 and djdev204 using the patch presented in
> <http://www.delorie.com/archives/browse.cgi?p=djgpp/2011/09/18/17:03:04> and it
> compiles flawlessly.

Maybe 4.4 warns but 4.6 fails to do so (which would clearly
be a bug, but that's out of our topic)

>   Neitherless, you are right.  I will look for the places
> where CF is set and check that the flags variable is correctly initilized.
>

Yes. All of the lines setting CF can _probably_ be done
by simple assignment instead of OR'ing

> Regards,
> Juan M. Guerrero
>

--
O.S.