Mailing-List: contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-developers-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-developers/>
List-Post: <mailto:cygwin-developers AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-developers-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-developers-owner AT sources DOT redhat DOT com
Delivered-To: mailing list cygwin-developers AT sources DOT redhat DOT com
Subject: Re: cinstall patch
From: Robert Collins <robert DOT collins AT itdomain DOT com DOT au>
To: Matt <matt AT use DOT net>
Cc: cygwin-developers AT sources DOT redhat DOT com
In-Reply-To: <Pine.NEB.4.30.0110271948520.22094-200000@cesium.clock.org>
References: <Pine DOT NEB DOT 4 DOT 30 DOT 0110271948520 DOT 22094-200000 AT cesium DOT clock DOT org>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Mailer: Evolution/0.15 (Preview Release)
Date: 31 Oct 2001 23:57:09 +1100
Message-Id: <1004533030.1701.123.camel@lifelesswks>
Mime-Version: 1.0
X-OriginalArrivalTime: 31 Oct 2001 13:01:23.0660 (UTC) FILETIME=[249EC8C0:01C1620C]

On Sun, 2001-10-28 at 14:00, Matt wrote:
> 
> 
> There were a few lint wanrings I wasn't sure what to do about. The warning
> and my question:
> 
> geturl.cc(95) : Warning 578: Declaration of symbol 'gw_dialog' hides
> symbol
>     'gw_dialog' (line 40)
> 
> Is this intentional?

Yes but - it's confusing and should be changed. The reason things work
with this is that that function is just a message loop, line 73 is where
the real gw_dialog is set.

Long term I think this need some objectising rather than global vars,
some things would become more clear (IMNSHO).

> ----
> choose.cc(448) : Warning 533: function 'list_click(struct HWND__ *, int,
> int,
>     int, unsigned int)' should return a value (see line 402)
> 
> what should the return value be at the end of the function?
 
did list_vscroll and list_hscroll also return errors?

It looks to me like those three functions where generated by some
interface wizard. The WM_LBUTTONDOWN is documented as _requiring_ a
return code of 0 if it is processed by the application - and I suspect
the same for the HSCROLL and VSCROLL messages. (I haven't checked yet).

For now, lets leave this, and once I've checked the other two cases I
think we can get rid of the HANDLE_WM_.. macros, call the functions
directly and always return 0;

> -----
> choose.cc(911) : Warning 644: Variable 'n' (line 891) may not have been
>     initialized
> 
> what should initial value for n be?

It's set by the if then else in /* part 1 */

I've added a bailout clause if nothing matches which should make gcc
happy. I've also caught a parameter validation bug in the same function.

> ----
>           if (src && srcsz)
> choose.cc(1488) : Warning 506: Constant value Boolean
> 
> Should this be *src && *srcsz?

I think src[0] && srcsz. It's checking that there really is something to
list there.