RE: [fltk.general] 1.3.1 warnings / build errors for msys2 mingw64 [General Use]

[MacArthur, Ian (Leonardo, UK)]

> Building the examples gives errors:

Hmm, this is a bit odd, as I was building using mingw64 at home last evening and I thought it worked without errors.

Mind you, I'm using svn rather than the tarballs, and I know a lot of these 64-bit Windows "features" have been resolved.

Might be worth trying the svn and see how that goes, or at least the most recent weekly, if you do not have svn.

> howto-add_fd-and-popen.cxx:66:50: error:
> invalid conversion from 'void (*)(int, void*)' to
> 'Fl_FD_Handler {aka void (*)(long long unsigned int, void*)}'
> [-fpermissive]


> compling with -fpermissive seems to work, but would be better
> if it wasn't required.


Strictly speaking, I think the "right" thing to do would be to "correct" howto-add_fd-and-popen.cxx, in that it defines:

void HandleFD(int fd, void *data) {...}

Whereas the "correct" definition would be:

void HandleFD(FL_SOCKET fd, void *data) {...}

Where FL_SOCKET is meant to resolve to the correct type on each platform.

That said, it seems odd to me that MS decided to change the base type of a socket from "int" to " unsigned __int64" which appears to be what is at issue here.

Did they *really* make a socket be an "unsigned __int64"?

Weird...
I wonder how many sockets they plan on opening simultaneously? 2 billion isn't enough?

Or, is our definition of FL_SOCKET as an "unsigned __int64" on 64-bit Windows actually the mistake here?


> Note that there are multiple warnings about int -> pointer
> casts when bulding FLTK libraries. These should probably
> have casts added if they are safe.

Again, I think a lot (though probably not yet all...) of these are resolved in svn.

It's an ongoing battle. When they switched to 64-bit, MS decided to peg a "long" at 32-bit to match an "int", as it always had been in 32-bit Windows.

Everybody else decided to make a "long" 64-bit and leave an "int" as 32-bit.

The kicker is that *a lot* of code (not just fltk) pretty much assumes that a "long" will hold a "void *" or any other pointer type.
Except that on 64-bit Windows, it will not, now.
Thanks, MS.
Hence a lot of tidying up...

Ongoing, work in progress.

I think we are actually safe, but... Well, at least my 64-bit Windows builds do not actually crash, FWIW!






Selex ES Ltd
Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL
A company registered in England & Wales. Company no. 02426132
********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

[Albrecht Schlosser]

On 11.08.2016 14:39 MacArthur, Ian (Leonardo, UK) wrote:
>> Building the examples gives errors:
>
> Hmm, this is a bit odd, as I was building using mingw64 at home last evening and I thought it worked without errors.

The problem the OP mentioned is in the examples/ folder which is not
built in the normal build process.

Note: I fixed one error (the one reported by the OP) and another warning
in the examples folder in svn r 11870 (1.3) and 11871 (porting).

> Mind you, I'm using svn rather than the tarballs, and I know a lot of these 64-bit Windows "features" have been resolved.

With current gcc (i.e. 6.1) *all* warnings are resolved, be it Windows
(32-bit or 64-bit) or Linux (64-bit). I don't have a Linux 32-bit system
for testing at hand (but I have a VM somewhere), so I can't tell right
now if we get warnings on 32-bit Linux.

Unfortunately I don't have a macOS system (aka Mac OS X) so I can't test
on those.

> Might be worth trying the svn and see how that goes, or at least the most recent weekly, if you do not have svn.

As noted above, current svn would be necessary to see all warnings
fixed, or the next weekly snapshot (tomorrow).

> Strictly speaking, I think the "right" thing to do would be to "correct" howto-add_fd-and-popen.cxx, in that it defines:
>
> void HandleFD(int fd, void *data) {...}
>
> Whereas the "correct" definition would be:
>
> void HandleFD(FL_SOCKET fd, void *data) {...}
>
> Where FL_SOCKET is meant to resolve to the correct type on each platform.

That's exactly what I did.

But FL_SOCKET is wrong here, as discussed before. Unfortunately that's
how it is in FLTK 1.3. I still hope that we can have a better solution
in FLTK 1.4.

>> Note that there are multiple warnings about int -> pointer
>> casts when bulding FLTK libraries. These should probably
>> have casts added if they are safe.
>
> Again, I think a lot (though probably not yet all...) of these are resolved in svn.

See above. AFAICT all warnings are fixed in gcc builds.

> It's an ongoing battle. When they switched to 64-bit, MS decided to peg a "long" at 32-bit to match an "int", as it always had been in 32-bit Windows.
>
> Everybody else decided to make a "long" 64-bit and leave an "int" as 32-bit.

Yep, there are still lots of warnings in Visual Studio builds under
Windows (32-bit) and even more with 64-bit builds.

Here's a trick: use CMake to build the IDE solution (don't use the
bundled one of FLTK 1.3). When using CMake, set

OPTION_OPTIM:STRING="/wd4244 /wd4267 /wd4305 /wd4996 /wd4312 /wd4334
/wd4838"

This disables all warnings I could find. Lots of these warnings are
related to variable (value) truncation, but there are also these
warnings about "Posix compatible" functions: _open instead of open etc.

I'm aware that this does not _fix_ the warnings, but I'm not going to
"fix" any of these in FLTK 1.3. Maybe in 1.4? Volunteers?

[Albrecht Schlosser]

On 11.08.2016 14:39 MacArthur, Ian (Leonardo, UK) wrote:

...

> Where FL_SOCKET is meant to resolve to the correct type on each platform.
>
> That said, it seems odd to me that MS decided to change the base type of a socket from "int" to " unsigned __int64" which appears to be what is at issue here.
>
> Did they *really* make a socket be an "unsigned __int64"?
>
> Weird...
> I wonder how many sockets they plan on opening simultaneously? 2 billion isn't enough?
>
> Or, is our definition of FL_SOCKET as an "unsigned __int64" on 64-bit Windows actually the mistake here?

Our definition is "correct" WRT MS's definition.

It's really weird, although I can understand that the socket definition
should better be unsigned int (not signed int), as well as file
descriptors, but ... no need to think about this. It is as it is in the
U*X world, and MS went their own way.

[Spacen]

On Thursday, 11 August 2016 13:39:06 UTC+1, MacArthur, Ian (Leonardo, UK) wrote:

> Building the examples gives errors:

Hmm, this is a bit odd, as I was building using mingw64 at home last evening and I thought it worked without errors.

Mind you, I'm using svn rather than the tarballs, and I know a lot of these 64-bit Windows "features" have been resolved.

I see. Yes I shall try out svn. Thanks.

 

The kicker is that *a lot* of code (not just fltk) pretty much assumes that a "long" will hold a "void *" or any other pointer type.
Except that on 64-bit Windows, it will not, now.
Thanks, MS.
Hence a lot of tidying up...

Well yes, but then again the C and C++ standard says roughly.... sizeof short <= int <=  long <= long long and sizeof(int)  >= 16, sizeof (long long) >= 64 Something like that*. The point is long can be what size it wants to be within the limits. So you can't really blame the compiler if it is following the standard. Perhaps opaque types should be of type void *. or of type "opaque" and have a typedef for it. I do see a lot of api's using void * for opaque 'things'. In particular thread start functions, that take an optional data argument. e.g:

int pthread_create(pthread_t *thread, const pthread_attr_t *attr,
                          void *(*start_routine) (void *), void *arg);

and:

HANDLE WINAPI CreateThread(
  _In_opt_  LPSECURITY_ATTRIBUTES  lpThreadAttributes,
  _In_      SIZE_T                 dwStackSize,
  _In_      LPTHREAD_START_ROUTINE lpStartAddress,
  _In_opt_  LPVOID                 lpParameter, ////////// THIS
  _In_      DWORD                  dwCreationFlags,
  _Out_opt_ LPDWORD                lpThreadId
);

* http://stackoverflow.com/questions/589575/what-does-the-c-standard-state-the-size-of-int-long-type-to-be

 

[MacArthur, Ian (Leonardo, UK)]

> Well yes, but then again the C and C++ standard says roughly.... sizeof
> short <= int <= long <= long long and sizeof(int) >= 16, sizeof (long
> long) >= 64 Something like that*. The point is long can be what size it
> wants to be within the limits. So you can't really blame the compiler if
> it is following the standard.

Indeed: but my grumble is not that they didn’t follow the standard.
Rather, it is that where they had a choice, they chose to do something that was at odds with what everyone else did when faced with the same choice, and we are all paying a price for their decision.

I have access to 64-bit platforms running a variety of operating systems; only one of these (Windows) has a 32-bit "long" type. All the others have 64-bit "long"s. Porting code between these is easy, right up until I have to build for Windows...

> Perhaps opaque types should be of type void *. or of type "opaque" and
> have a typedef for it. I do see a lot of api's using void * for opaque
> 'things'.

That's one option. I usually prefer to go for using a [u]intptr_t type; i.e. an integral type that is guaranteed to be big enough to hold a pointer. Fltk does implement its own fl_uintptr_t and fl_intptr_t types, and we have been making more use of them to help out. They may become more prevalent in 1.4, as there are a few API and ABI places we can't "fix" in 1.3 without breaking stuff!

[imm]

On 11 August 2016 at 14:00, Albrecht Schlosser wrote:

On 11.08.2016 14:39 MacArthur, Ian (Leonardo, UK) wrote:

Building the examples gives errors:

Hmm, this is a bit odd, as I was building using mingw64 at home last evening and I thought it worked without errors.

The problem the OP mentioned is in the examples/ folder which is not built in the normal build process.

​
Oh yes, I know - what I had meant was that I ​quite often (usually) build the examples folder too when I update, so I was pretty sure I had also built that for my mingw64 build.

It does seem that I was mistaken, however.