Re: sys/socket.h: define SOL_IPV6?

On Apr 27 00:31, Christopher Faylor wrote:
> On Sun, Apr 26, 2009 at 10:22:07PM -0500, Yaakov (Cygwin/X) wrote:
> >Does it make sense to define SOL_IPV6 now?  Patch attached if so.
> 
> I think it does.  I've checked in this patch.  I'm sure Corinna will
> revert it if I am wrong.

It's not wrong but unfortunately it won't help either.  The only SOL_xxx
option supported by Winsock is SOL_SOCKET.  But since we already have
the other SOL_xxx options defined, it's a good idea to have SOL_IPV6
defined as well.

Corinna

--

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

avoid compiler warning with DEBUGGING

I noticed a complaint about comparing signed and unsigned values, when
compiling with DEBUGGING enabled.  net.cc also has a lot of trailing blanks.

2009-05-20  Eric Blake  <ebb9 <at> byu.net>

	* net.cc (gethostby_helper): Use correct signedness.

--
Don't work too hard, make some time for fun as well!

Eric Blake             ebb9 <at> byu.net

diff --git a/winsup/cygwin/net.cc b/winsup/cygwin/net.cc
index cb0a5cd..79b2dfa 100644
--- a/winsup/cygwin/net.cc
+++ b/winsup/cygwin/net.cc
 <at>  <at>  -960,7 +960,8  <at>  <at>  gethostby_helper (const char *name, const int af, const int type,

   record * anptr = NULL, * prevptr = NULL, * curptr;
   int i, alias_count = 0, string_size = 0, address_count = 0;
-  int complen, namelen1 = 0, address_len = 0, antype, anclass, ansize;
+  unsigned int complen;
+  int namelen1 = 0, address_len = 0, antype, anclass, ansize;

   /* Get the count of answers */
   ancount = ntohs (((HEADER *) msg)->ancount);
--

-- 
1.6.2.4

Re: avoid compiler warning with DEBUGGING

On Wed, May 20, 2009 at 06:51:19AM -0600, Eric Blake wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>I noticed a complaint about comparing signed and unsigned values, when
>compiling with DEBUGGING enabled.  net.cc also has a lot of trailing blanks.
>
>2009-05-20  Eric Blake  <ebb9 <at> byu.net>
>
>	* net.cc (gethostby_helper): Use correct signedness.

I've applied this even though I couldn't duplicate the problem with gcc 4.
I think that may be a first since gcc 4 is much more picky than gcc 3.4.

Thanks.

cgf

[PATCH] Re: [1.5] ls -l on /cygdrive/d doesn't work

I have fixed the error in ntea.cc handling the return value of 
NTQueryEaFile. This patch is only needed for the 1.5 release. Maybe this 
error should be considered as critical due to uninitialized stack usage 
of the variable fea when the function returned an error.

2009-05-26 David Engraf <david.engraf <at> sysgo.com>

	* ntea.cc (read_ea): Fix error handling and avoid using
	uninitialized stack.

David Engraf schrieb:
> I think this error is located in the cygwin/ntea.cc read_ea function. 
> NtQueryEaFile fails due to unsupported extended attributes on fat32 and 
> iso9660 and ret is set to -1. After setting ret to -1 the function 
> checks fea->EaValueLength which is in my case 8313 (see log) due to an 
> uninitialized stack and read_ea return 8313. Now the calling function 
> (fhandler_base::fstat_helper) is using the uninitialized data for the 
> timestamp and file size and returns incorrect values.
> This error doesn't happen on the new 1.7 release, but I need a solution 
> for the stable version.
> 
> 
> if (!NT_SUCCESS (status))
>     {
>       ret = -1;
>       debug_printf ("%x = NtQueryEaFile (%s, %s), Win32 error %d",
>                     status, file, attrname, RtlNtStatusToDosError 
> (status));
>     }
>   if (!fea->EaValueLength)

[PATCH] Re: [1.5] ls -l on /cygdrive/d doesn't work

From: David Engraf <david.engraf <at> sysgo.com>
Subject: [PATCH] Re: [1.5] ls -l on /cygdrive/d doesn't work
Date: 2009-05-26 10:18:54 GMT

I have fixed the error in ntea.cc handling the return value of 
NTQueryEaFile. This patch is only needed for the 1.5 release. Maybe this 
error should be considered as critical due to uninitialized stack usage 
of the variable fea when the function returned an error.

2009-05-26 David Engraf <david.engraf <at> sysgo.com>

	* ntea.cc (read_ea): Fix error handling and avoid using
	uninitialized stack.

David Engraf schrieb:
> I think this error is located in the cygwin/ntea.cc read_ea function. 
> NtQueryEaFile fails due to unsupported extended attributes on fat32 and 
> iso9660 and ret is set to -1. After setting ret to -1 the function 
> checks fea->EaValueLength which is in my case 8313 (see log) due to an 
> uninitialized stack and read_ea return 8313. Now the calling function 
> (fhandler_base::fstat_helper) is using the uninitialized data for the 
> timestamp and file size and returns incorrect values.
> This error doesn't happen on the new 1.7 release, but I need a solution 

Re: [PATCH] Re: [1.5] ls -l on /cygdrive/d doesn't work

On Tue, May 26, 2009 at 12:41:03PM +0200, David Engraf wrote:
>I have fixed the error in ntea.cc handling the return value of 
>NTQueryEaFile. This patch is only needed for the 1.5 release. Maybe this 
>error should be considered as critical due to uninitialized stack usage 
>of the variable fea when the function returned an error.
>
>
>2009-05-26 David Engraf <david.engraf <at> sysgo.com>
>
>	* ntea.cc (read_ea): Fix error handling and avoid using
>	uninitialized stack.

Thanks for the patch but this will have to be a known limitation of
1.5.x.  We don't plan on making any new releases before 1.7 is rolled
out.

cgf

Re: [PATCH] Re: [1.5] ls -l on /cygdrive/d doesn't work

Christopher Faylor wrote:
> On Tue, May 26, 2009 at 12:41:03PM +0200, David Engraf wrote:
>> I have fixed the error in ntea.cc handling the return value of 
>> NTQueryEaFile. This patch is only needed for the 1.5 release. Maybe this 
>> error should be considered as critical due to uninitialized stack usage 
>> of the variable fea when the function returned an error.
>>
>>
>> 2009-05-26 David Engraf <david.engraf <at> sysgo.com>
>>
>> 	* ntea.cc (read_ea): Fix error handling and avoid using
>> 	uninitialized stack.
> 
> Thanks for the patch but this will have to be a known limitation of
> 1.5.x.  We don't plan on making any new releases before 1.7 is rolled
> out.
> 
> cgf

But this could be a security problem and as long as we don't have 
released the 1.7 we should continue fixing critical parts because most 
of the users are using the stable version.

- David