My first thought is that probably isn't serious enough to warrant a change. I
was porting libncftp to the latest TDM-GCC environment, as we plan to upgrade
from MinGW32. I spent enough time on it that I thought I'd note it on the
mailing list. Thank you for your interest.
I see this code in _ip_types.h:
#ifdef __LP64__
struct __ms_timeval {
__LONG32 tv_sec;
__LONG32 tv_usec;
};
typedef struct __ms_timeval TIMEVAL;
typedef struct __ms_timeval *PTIMEVAL;
typedef struct __ms_timeval *LPTIMEVAL;
#else
typedef struct timeval TIMEVAL;
typedef struct timeval *PTIMEVAL;
typedef struct timeval *LPTIMEVAL;
#endif
My inclination would be to omit that code, and revise _timeval.h to be:
#ifdef __LP64__
struct timeval {
__LONG32 tv_sec;
__LONG32 tv_usec;
};
#else
struct timeval
{
long tv_sec;
long tv_usec;
};
#endif
And actually 'tv_sec' should be time_t.
But I'm not familiar with all the issues, and would have to study it a bit....
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of David Grayson
Sent: Friday, October 30, 2015 11:49 AM
To: Burkhardt, Glenn B UTAS; [email protected]
Subject: [External] Re: [Mingw-w64-public] [patch] Replace struct timeval usage
If you want to get mingw-w64 fixed, I suggest posting a patch file to this list
so the developers can see what change you would want to make and easily apply
it. In case it helps, I usually clone the git repository and prepare patches
using "git diff", and you can look at the archives of this list to see some
example patches.
Are you arguing that "const PTIMEVAL" should be expanded to "const struct
timeval *" when the typedef is expanded? You might be right, but it would be
more convincing to cite another compiler that behaves that way, or cite the
appropriate part of the C standard if you want to convince people.
--David
On Fri, Oct 30, 2015 at 5:21 AM, Burkhardt, Glenn B UTAS
<[email protected]> wrote:
>> The types "const struct timeval *" and "struct timeval * const" are not the
>> same.
>
> Right, of course. But there seems to be a fundamental limitation in gcc when
> it comes to recognizing that two types are "equal". It appears that it
> doesn't make that check.
>
> Consider this code, which avoids using headers for clarity:
>
> struct timeval {
> long tv_sec; /* seconds */
> long tv_usec; /* microseconds */
> };
> typedef unsigned int u_int;
> typedef unsigned int * SOCKET;
> typedef struct fd_set
> {
> u_int fd_count;
> SOCKET fd_array[64];
> } fd_set;
> typedef struct timeval *PTIMEVAL;
>
> int select(int nfds,fd_set *readfds,fd_set *writefds,fd_set *exceptfds,
> const PTIMEVAL timeout);
>
> void sub()
> {
> struct timeval tv;
>
> select(0, 0, 0, 0, (const struct timeval *)&tv); }
>
> Both gcc 4.8.4 on Linux and TDM-GCC 5.1.0 give this warning:
> t.c:21:24: warning: passing argument 5 of 'select' discards 'const' qualifier
> from pointer target type [-Wdiscarded-qualifiers]
> select(0, 0, 0, 0, (const struct timeval *)&tv);
> ^
> t.c:14:5: note: expected 'PTIMEVAL {aka struct timeval * const}' but argument
> is of type 'const struct timeval *'
> int select(int nfds,fd_set *readfds,fd_set *writefds,fd_set *exceptfds,
> ^
>
> I can't explain why the other warning came out with "struct timeval * const".
> But I think the long and the short of it is that using a typedef to switch
> to a different 'timeval' structure instead of using conditionals to define
> different 'timeval' will cause this minor problem.
>
> Ironically, the libncftp code that cast the 5th argument to select was
> probably written simply to document the fact that the Microsoft edition of
> select doesn't change the timer value, as Linux does. The code would compile
> without warnings if the cast was simply dropped.
------------------------------------------------------------------------------
_______________________________________________
Mingw-w64-public mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
