gnuplot-beta

gnuplot on 64-bit Windows

[Allin C. <cot...@wf...>]

I have need of a 64-bit Windows build of gnuplot and I've been 
working on cross-compiling from Linux using mingw64. I see 
several places in current CVS where the code generates errors 
and warnings. I'm attaching a patch-set which quells the 
errors and warnings, but unfortunately I'm not able to test on 
win64 at present.

If I'm understanding the code correctly there's one place that 
I haven't patched which may be a problem, namely the 
definition of struct tagLS in win/wgraph.c. The first member 
of this struct is an int ("widtype"). I believe it should be 
redefined for win64 as LONG_PTR, since it is assigned to via
the function GetWindowLong(), which maps to GetWindowLongPtr() 
on win64, and the latter returns a 64-bit pointer.

Some of the changes I've made are actually OK for win32, from 
Windows 2000 onward. But I guess gnuplot aims to support older 
Windows versions than that; I've therefore bracketed all my 
changes with "#ifdef _WIN64" so as to leave the 32-bit code 
unaffected.

--
Allin Cottrell
Department of Economics
Wake Forest University, NC

Re: gnuplot on 64-bit Windows

[sfeam (E. Merritt) <eam...@gm...>]

On Wednesday, 24 July 2013, Allin Cottrell wrote:
> I have need of a 64-bit Windows build of gnuplot and I've been 
> working on cross-compiling from Linux using mingw64. I see 
> several places in current CVS where the code generates errors 
> and warnings. I'm attaching a patch-set which quells the 
> errors and warnings, but unfortunately I'm not able to test on 
> win64 at present.

I can't help with evaluation of the full patch, but one set of 
changes strikes me as being wrong on the face of it:

%%%%%%%%%%%%%%
+#ifdef _WIN64
+INT_PTR CALLBACK PrintDlgProc(HWND hDlg, UINT message, WPARAM wParam, LPARAM lParam);
+#else
 BOOL CALLBACK PrintDlgProc(HWND hDlg, UINT message, WPARAM wParam, LPARAM lParam);
+#endif
%%%%%%%%%%%%%%

There's no way it can be correct to label a Boolean value  as a pointer.

The equivalent substitution occurs several places in your patch.
I didn't check each one, but the routine PrintDlgProc really does return
TRUE or FALSE, so I think at least in this case, if not all of them, 
the original code was correct.

	Ethan

> 
> If I'm understanding the code correctly there's one place that 
> I haven't patched which may be a problem, namely the 
> definition of struct tagLS in win/wgraph.c. The first member 
> of this struct is an int ("widtype"). I believe it should be 
> redefined for win64 as LONG_PTR, since it is assigned to via
> the function GetWindowLong(), which maps to GetWindowLongPtr() 
> on win64, and the latter returns a 64-bit pointer.
> 
> Some of the changes I've made are actually OK for win32, from 
> Windows 2000 onward. But I guess gnuplot aims to support older 
> Windows versions than that; I've therefore bracketed all my 
> changes with "#ifdef _WIN64" so as to leave the 32-bit code 
> unaffected.
> 
> --
> Allin Cottrell
> Department of Economics
> Wake Forest University, NC

Re: gnuplot on 64-bit Windows

[Allin C. <cot...@wf...>]

On Wed, 24 Jul 2013, sfeam (Ethan Merritt) wrote:

> On Wednesday, 24 July 2013, Allin Cottrell wrote:
>> I have need of a 64-bit Windows build of gnuplot and I've been
>> working on cross-compiling from Linux using mingw64. I see
>> several places in current CVS where the code generates errors
>> and warnings. I'm attaching a patch-set which quells the
>> errors and warnings, but unfortunately I'm not able to test on
>> win64 at present.
>
> I can't help with evaluation of the full patch, but one set of
> changes strikes me as being wrong on the face of it:
>
> %%%%%%%%%%%%%%
> +#ifdef _WIN64
> +INT_PTR CALLBACK PrintDlgProc(HWND hDlg, UINT message, WPARAM wParam, LPARAM lParam);
> +#else
> BOOL CALLBACK PrintDlgProc(HWND hDlg, UINT message, WPARAM wParam, LPARAM lParam);
> +#endif
> %%%%%%%%%%%%%%
>
> There's no way it can be correct to label a Boolean value  as a pointer.
>
> The equivalent substitution occurs several places in your patch.
> I didn't check each one, but the routine PrintDlgProc really does return
> TRUE or FALSE, so I think at least in this case, if not all of them,
> the original code was correct.

It's strange, I agree, but the original code throws a warning. 
The caller, in all cases, is CreateDialogParam() and the 
callback is the fourth argument, of type DLGPROC, in relation 
to which the msdn doc points us to "DialogProc callback 
function"

http://msdn.microsoft.com/en-us/library/windows/desktop/ms645469%28v=vs.85%29.aspx

where we find:

<quote>
Return value

Type: INT_PTR

Typically, the dialog box procedure should return TRUE if it 
processed the message, and FALSE if it did not. If the dialog 
box procedure returns FALSE, the dialog manager performs the 
default dialog operation in response to the message.
</quote>

It's probably OK to leave the code as is and ignore the 
warning, but here it is:

../src/win/wgraph.c: In function 'LineStyle':
../src/win/wgraph.c:3607:2: warning: passing argument 4 of 
'DialogBoxParamA' from incompatible pointer type [enabled by 
default]
/opt/win64/lib/gcc/x86_64-w64-mingw32/4.6.4/../../../../x86_64-w64-mingw32/include/winuser.h:2104:29: 
note: expected 'DLGPROC' but argument is of type 'BOOL 
(*)(struct HWND__ *, UINT,  WPARAM,  LPARAM)'

Allin Cottrell

Re: gnuplot on 64-bit Windows

[sfeam (E. Merritt) <eam...@gm...>]

On Wednesday, 24 July 2013, Allin Cottrell wrote:
> On Wed, 24 Jul 2013, sfeam (Ethan Merritt) wrote:
> 
> > On Wednesday, 24 July 2013, Allin Cottrell wrote:
> >> I have need of a 64-bit Windows build of gnuplot and I've been
> >> working on cross-compiling from Linux using mingw64. I see
> >> several places in current CVS where the code generates errors
> >> and warnings. I'm attaching a patch-set which quells the
> >> errors and warnings, but unfortunately I'm not able to test on
> >> win64 at present.
> >
> > I can't help with evaluation of the full patch, but one set of
> > changes strikes me as being wrong on the face of it:
> >
> > %%%%%%%%%%%%%%
> > +#ifdef _WIN64
> > +INT_PTR CALLBACK PrintDlgProc(HWND hDlg, UINT message, WPARAM wParam, LPARAM lParam);
> > +#else
> > BOOL CALLBACK PrintDlgProc(HWND hDlg, UINT message, WPARAM wParam, LPARAM lParam);
> > +#endif
> > %%%%%%%%%%%%%%
> >
> > There's no way it can be correct to label a Boolean value  as a pointer.
> >
> > The equivalent substitution occurs several places in your patch.
> > I didn't check each one, but the routine PrintDlgProc really does return
> > TRUE or FALSE, so I think at least in this case, if not all of them,
> > the original code was correct.
> 
> It's strange, I agree, but the original code throws a warning. 
> The caller, in all cases, is CreateDialogParam() and the 
> callback is the fourth argument, of type DLGPROC, in relation 
> to which the msdn doc points us to "DialogProc callback 
> function"
> 
> http://msdn.microsoft.com/en-us/library/windows/desktop/ms645469%28v=vs.85%29.aspx
> 
> where we find:
> 
> <quote>
> Return value
> 
> Type: INT_PTR
> 
> Typically, the dialog box procedure should return TRUE if it 
> processed the message, and FALSE if it did not. If the dialog 
> box procedure returns FALSE, the dialog manager performs the 
> default dialog operation in response to the message.
> </quote>

[shudder]
Nevertheless, wouldn't your change just shift the site of the
error/warning message?  Now the prototype says it returns
INT_PTR but the function itself still says it returns BOOL.
So there is still a mismatch in types.

I found a hideous example on that Microsoft site you linked to:
http://msdn.microsoft.com/en-us/library/windows/desktop/ff728900(v=vs.85).aspx

It declares a callback function
   INT_PTR CALLBACK OpenUrlDialogProc(HWND hDlg, UINT message, 
                                                                     WPARAM wParam, LPARAM lParam)
which exits with
   return (INT_PTR)FALSE;

I guess it's a matter of "choose your poison".

	Ethan



> It's probably OK to leave the code as is and ignore the 
> warning, but here it is:
> 
> ../src/win/wgraph.c: In function 'LineStyle':
> ../src/win/wgraph.c:3607:2: warning: passing argument 4 of 
> 'DialogBoxParamA' from incompatible pointer type [enabled by 
> default]
> /opt/win64/lib/gcc/x86_64-w64-mingw32/4.6.4/../../../../x86_64-w64-mingw32/include/winuser.h:2104:29: 
> note: expected 'DLGPROC' but argument is of type 'BOOL 
> (*)(struct HWND__ *, UINT,  WPARAM,  LPARAM)'
> 
> Allin Cottrell
> 

Re: gnuplot on 64-bit Windows

[Allin C. <cot...@wf...>]

On Wed, 24 Jul 2013, sfeam (Ethan Merritt) wrote:

> On Wednesday, 24 July 2013, Allin Cottrell wrote:
>> On Wed, 24 Jul 2013, sfeam (Ethan Merritt) wrote:
>>
>>> On Wednesday, 24 July 2013, Allin Cottrell wrote:
>>>> I have need of a 64-bit Windows build of gnuplot and I've been
>>>> working on cross-compiling from Linux using mingw64. I see
>>>> several places in current CVS where the code generates errors
>>>> and warnings. I'm attaching a patch-set which quells the
>>>> errors and warnings, but unfortunately I'm not able to test on
>>>> win64 at present.
>>>
>>> I can't help with evaluation of the full patch, but one set of
>>> changes strikes me as being wrong on the face of it:
>>>
>>> %%%%%%%%%%%%%%
>>> +#ifdef _WIN64
>>> +INT_PTR CALLBACK PrintDlgProc(HWND hDlg, UINT message, WPARAM wParam, LPARAM lParam);
>>> +#else
>>> BOOL CALLBACK PrintDlgProc(HWND hDlg, UINT message, WPARAM wParam, LPARAM lParam);
>>> +#endif
>>> %%%%%%%%%%%%%%
>>>
>>> There's no way it can be correct to label a Boolean value  as a pointer.
>>>
>>> The equivalent substitution occurs several places in your patch.
>>> I didn't check each one, but the routine PrintDlgProc really does return
>>> TRUE or FALSE, so I think at least in this case, if not all of them,
>>> the original code was correct.
>>
>> It's strange, I agree, but the original code throws a warning.
>> The caller, in all cases, is CreateDialogParam() and the
>> callback is the fourth argument, of type DLGPROC, in relation
>> to which the msdn doc points us to "DialogProc callback
>> function"
>>
>> http://msdn.microsoft.com/en-us/library/windows/desktop/ms645469%28v=vs.85%29.aspx
>>
>> where we find:
>>
>> <quote>
>> Return value
>>
>> Type: INT_PTR
>>
>> Typically, the dialog box procedure should return TRUE if it
>> processed the message, and FALSE if it did not. If the dialog
>> box procedure returns FALSE, the dialog manager performs the
>> default dialog operation in response to the message.
>> </quote>
>
> [shudder]

Yes, indeed.

> Nevertheless, wouldn't your change just shift the site of the
> error/warning message?  Now the prototype says it returns
> INT_PTR but the function itself still says it returns BOOL.
> So there is still a mismatch in types.

My patches also change the return type of the relevant 
callback functions to INT_PTR for win64. However, given how 
broken the MS design is, I'd be happy to leave things as they 
were (in respect of CreateDialogParam) and put up with the 
warnings from gcc. If it might be useful I can submit an 
alternative version of the patch-set.

Allin Cottrell

Re: gnuplot on 64-bit Windows

[Bastian M. <bma...@we...>]

Am 25.07.2013 10:41, schrieb Allin Cottrell:
> On Wed, 24 Jul 2013, sfeam (Ethan Merritt) wrote:
>
>> On Wednesday, 24 July 2013, Allin Cottrell wrote:
>>> On Wed, 24 Jul 2013, sfeam (Ethan Merritt) wrote:
>>>
>>>> On Wednesday, 24 July 2013, Allin Cottrell wrote:
>>>>> I have need of a 64-bit Windows build of gnuplot and I've been
>>>>> working on cross-compiling from Linux using mingw64. I see
>>>>> several places in current CVS where the code generates errors
>>>>> and warnings. I'm attaching a patch-set which quells the
>>>>> errors and warnings, but unfortunately I'm not able to test on
>>>>> win64 at present.
>>>>
>>>> I can't help with evaluation of the full patch, but one set of
>>>> changes strikes me as being wrong on the face of it:
>>>>
>>>> %%%%%%%%%%%%%%
>>>> +#ifdef _WIN64
>>>> +INT_PTR CALLBACK PrintDlgProc(HWND hDlg, UINT message, WPARAM wParam, LPARAM lParam);
>>>> +#else
>>>> BOOL CALLBACK PrintDlgProc(HWND hDlg, UINT message, WPARAM wParam, LPARAM lParam);
>>>> +#endif
>>>> %%%%%%%%%%%%%%
>>>>
>>>> There's no way it can be correct to label a Boolean value  as a pointer.
>>>>

This is an (understandable) misunderstanding. INT_PTR is not a pointer 
type, but an integer large enough to do pointer calculations with. See e.g.
http://msdn.microsoft.com/en-us/library/windows/desktop/aa383751%28v=vs.85%29.aspx
Thus, the changes are indeed correct and is now included in CVS.

   Bastian


>>>> The equivalent substitution occurs several places in your patch.
>>>> I didn't check each one, but the routine PrintDlgProc really does return
>>>> TRUE or FALSE, so I think at least in this case, if not all of them,
>>>> the original code was correct.
>>>
>>> It's strange, I agree, but the original code throws a warning.
>>> The caller, in all cases, is CreateDialogParam() and the
>>> callback is the fourth argument, of type DLGPROC, in relation
>>> to which the msdn doc points us to "DialogProc callback
>>> function"
>>>
>>> http://msdn.microsoft.com/en-us/library/windows/desktop/ms645469%28v=vs.85%29.aspx
>>>
>>> where we find:
>>>
>>> <quote>
>>> Return value
>>>
>>> Type: INT_PTR
>>>
>>> Typically, the dialog box procedure should return TRUE if it
>>> processed the message, and FALSE if it did not. If the dialog
>>> box procedure returns FALSE, the dialog manager performs the
>>> default dialog operation in response to the message.
>>> </quote>
>>
>> [shudder]
>
> Yes, indeed.
>
>> Nevertheless, wouldn't your change just shift the site of the
>> error/warning message?  Now the prototype says it returns
>> INT_PTR but the function itself still says it returns BOOL.
>> So there is still a mismatch in types.
>
> My patches also change the return type of the relevant
> callback functions to INT_PTR for win64. However, given how
> broken the MS design is, I'd be happy to leave things as they
> were (in respect of CreateDialogParam) and put up with the
> warnings from gcc. If it might be useful I can submit an
> alternative version of the patch-set.
>
> Allin Cottrell