Differences in 32bit and 64bit builds

[Richard Shaw]

I'm working on the ability to produce Windows builds of fldigi using the
Fedora MinGW stack.

Currently the 32bit builds compile with little to no warnings and appear to
function properly, however, on 64bit builds there is a ton more warnings (I
have to use -fpermissive) and the program segfaults shortly after launching.

I have tried to capture a gdb stack trace but it produces no results...
zero.

For instance:
dialogs/fl_digi.cxx: In function 'void cb_mnuVisitURL(Fl_Widget*, void*)':
dialogs/fl_digi.cxx:2616:68: error: cast from 'HINSTANCE' {aka
'HINSTANCE__*'} to 'int' loses precision [-fpermissive]
 2616 |  if ((int)ShellExecute(NULL, "open", url, NULL, NULL,
SW_SHOWNORMAL) <= 32)
      |                                                                    ^

I see no such issues building for Fedora x86_64. I now the MinGW gcc is a
port, but it's still based on GCC so I guess I don't understand why all the
differences?

Thanks,
Richard

[Yaakov Selkowitz]

On Wed, 2020-06-10 at 10:26 -0500, Richard Shaw wrote:
> I'm working on the ability to produce Windows builds of fldigi using
> the Fedora MinGW stack.
>
> Currently the 32bit builds compile with little to no warnings and
> appear to function properly, however, on 64bit builds there is a ton
> more warnings (I have to use -fpermissive) and the program segfaults
> shortly after launching.
>
> I have tried to capture a gdb stack trace but it produces no results... zero.

The most common cause of this is work-size incorrectness, e.g. misuse
of LONG vs long, deprecated use of DWORD vs DWORD_PTR, etc. in variable
types being passed to (or returned from) Win32 APIs.  Those warnings
might be indicative of such issues.
> For instance:
> dialogs/fl_digi.cxx: In function 'void cb_mnuVisitURL(Fl_Widget*, void*)':
> dialogs/fl_digi.cxx:2616:68: error: cast from 'HINSTANCE' {aka 'HINSTANCE__*'} to 'int' loses precision [-fpermissive]
>  2616 |  if ((int)ShellExecute(NULL, "open", url, NULL, NULL, SW_SHOWNORMAL) <= 32)
>       |                                                                    ^

HINSTANCE is a pointer, so that's to be expected.  Even though the docs
say to cast to int, INT_PTR might be a safer choice here.

[Richard Shaw]

On Wed, Jun 10, 2020 at 11:34 AM Yaakov Selkowitz 
wrote:
> On Wed, 2020-06-10 at 10:26 -0500, Richard Shaw wrote:
> > I'm working on the ability to produce Windows builds of fldigi using
> > the Fedora MinGW stack.
> >
> > Currently the 32bit builds compile with little to no warnings and
> > appear to function properly, however, on 64bit builds there is a ton
> > more warnings (I have to use -fpermissive) and the program segfaults
> > shortly after launching.
> >
> > I have tried to capture a gdb stack trace but it produces no results...
>
> zero.
>
> The most common cause of this is work-size incorrectness, e.g. misuse
> of LONG vs long, deprecated use of DWORD vs DWORD_PTR, etc. in variable
> types being passed to (or returned from) Win32 APIs.  Those warnings
> might be indicative of such issues.

Ok, I'm grepping through the sources and do see DWORD used quite a bit but
not in the areas giving me trouble...
> > For instance:
> > dialogs/fl_digi.cxx: In function 'void cb_mnuVisitURL(Fl_Widget*,
>
> void*)':
> > dialogs/fl_digi.cxx:2616:68: error: cast from 'HINSTANCE' {aka
>
> 'HINSTANCE__*'} to 'int' loses precision [-fpermissive]
> > 2616 |  if ((int)ShellExecute(NULL, "open", url, NULL, NULL,
>
> SW_SHOWNORMAL) <= 32)
> >   |
>
> ^
>
> HINSTANCE is a pointer, so that's to be expected.  Even though the docs
> say to cast to int, INT_PTR might be a safer choice here.

That worked (at least for compiling), I still need to get through other
problems before I can test the resultant package.

Now seeing a few similar to this:

rigcontrol/FreqControl.cxx: In function 'void cbSelectDigit(Fl_Widget*,
void*)':
rigcontrol/FreqControl.cxx:63:49: error: cast from 'void*' to 'long int'
loses precision [-fpermissive]
   63 |  int Nbr = (INT_PTR)(reinterpret_cast<long> (nbr));

Thanks,
Richard

[Richard Shaw]

So why does this only show up in MinGW? If a 64bit pointer can't find it a
32bit int, shouldn't I also get an error when building for 64bit Fedora?

Or is the C/C++ library handling this automagically for me on linux?

Thanks,
Richard

[Jan Niklas Hasse]

On Wed, 10 Jun 2020, at 23:09, Richard Shaw wrote:
> So why does this only show up in MinGW? If a 64bit pointer can't find it a 32bit int, shouldn't I also get an error when building for 64bit Fedora?

Because ShellExecute is a Windows function, thus that part of the code won't be compiled when building for 64 bit Linux.

[Richard Shaw]

On Thu, Jun 11, 2020 at 10:43 AM Jan Niklas Hasse 
wrote:
> On Wed, 10 Jun 2020, at 23:09, Richard Shaw wrote:
>
> So why does this only show up in MinGW? If a 64bit pointer can't find it a
> 32bit int, shouldn't I also get an error when building for 64bit Fedora?
>
> Because ShellExecute is a Windows function, thus that part of the code
> won't be compiled when building for 64 bit Linux.

Well, I guess I meant more generally. I "fixed" a bunch of other "precison"
issues for the MinGW build that don't show up in the Fedora build., one
example:

@@ -852,7 +852,7 @@ static void xmlrpc_rig_set_pwrmeter(void *data)
  smeter->hide();
  pwrmeter->show();
  }
- int val = reinterpret_cast<long>(data);
+ int val = reinterpret_cast<intptr_t>(data);
  pwrmeter->value(val);
  }

Per my google-fu this needed to be changed because long (or int) isn't
guaranteed to be big enough to store a 64bit pointer, but this compiles
without warning on Fedora which is on 10.1.1 and later versions of gcc tend
to be more pedantic but mingw is on 9.2.1.

Thanks,
Richard

[Kalev Lember]

On 6/11/20 17:49, Richard Shaw wrote:
> On Thu, Jun 11, 2020 at 10:43 AM Jan Niklas Hasse <[e-mail] 
> > wrote:
> __
> On Wed, 10 Jun 2020, at 23:09, Richard Shaw wrote:
> > So why does this only show up in MinGW? If a 64bit pointer can't
> > find it a 32bit int, shouldn't I also get an error when building
> > for 64bit Fedora?
> Because ShellExecute is a Windows function, thus that part of the
> code won't be compiled when building for 64 bit Linux.
>
>
> Well, I guess I meant more generally. I "fixed" a bunch of other 
> "precison" issues for the MinGW build that don't show up in the Fedora 
> build., one example:
>
> @@ -852,7 +852,7 @@ static void xmlrpc_rig_set_pwrmeter(void *data)
>    smeter->hide();
>    pwrmeter->show();
>    }
> int val = reinterpret_cast<long>(data);
> int val = reinterpret_cast<intptr_t>(data);
>
> pwrmeter->value(val);
>    }
>
> Per my google-fu this needed to be changed because long (or int) isn't 
> guaranteed to be big enough to store a 64bit pointer, but this compiles 
> without warning on Fedora which is on 10.1.1 and later versions of gcc 
> tend to be more pedantic but mingw is on 9.2.1.

This is because int and long are different on Windows.

On 64 bit Fedora, the size of int and long are both 64 bit. On 64 bit 
Windows, int and long are both 32 bit.