MinGW - Minimalist GNU for Windows

Bugs item #2960729, was opened at 2010-02-28 19:47
Message generated for change (Comment added) made by bonez92
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=2960729&group_id=2435

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: w32api
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Eugene M. (bonez92)
Assigned to: Nobody/Anonymous (nobody)
Summary: sockaddr_in structure

Initial Comment:
Hi! I am using w32api 3.14.

In winsock2.h sockaddr_in declared as:
struct sockaddr_in {
	short	sin_family;
	u_short	sin_port;
	struct	in_addr sin_addr;
	char	sin_zero[8];
} ;

when trying to compile the code where sockaddr_in is used gcc.exe reports an error "`SOCKADDR_IN' undeclared (first use this function)". g++ doesn't report any errors and compiles successfully.

After changing structure declaration:
typedef struct sockaddr_in {
	short	sin_family;
	u_short	sin_port;
	struct	in_addr sin_addr;
	char	sin_zero[8];
} sockaddr_in;

gcc compiles successfully.

----------------------------------------------------------------------

>Comment By: Eugene M. (bonez92)
Date: 2010-02-28 19:48

Message:
Forgot to include. GCC's version is 4.4.0

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=2960729&group_id=2435

Bugs item #2960729, was opened at 2010-02-28 16:47
Message generated for change (Comment added) made by keithmarshall
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=2960729&group_id=2435

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: w32api
>Group: Behaves as Documented
>Status: Pending
>Resolution: Invalid
Priority: 5
Private: No
Submitted By: Eugene M. (bonez92)
Assigned to: Nobody/Anonymous (nobody)
Summary: sockaddr_in structure

Initial Comment:
Hi! I am using w32api 3.14.

In winsock2.h sockaddr_in declared as:
struct sockaddr_in {
	short	sin_family;
	u_short	sin_port;
	struct	in_addr sin_addr;
	char	sin_zero[8];
} ;

when trying to compile the code where sockaddr_in is used gcc.exe reports an error "`SOCKADDR_IN' undeclared (first use this function)". g++ doesn't report any errors and compiles successfully.

After changing structure declaration:
typedef struct sockaddr_in {
	short	sin_family;
	u_short	sin_port;
	struct	in_addr sin_addr;
	char	sin_zero[8];
} sockaddr_in;

gcc compiles successfully.

----------------------------------------------------------------------

>Comment By: Keith Marshall (keithmarshall)
Date: 2010-03-01 14:16

Message:
AFAICT, this is a bug in *your* code, *not* in MinGW.

According to http://msdn.microsoft.com/en-us/library/zx63b042(VS.80).aspx,
sockaddr_in is correctly declared as a structure tag, but is *not* typedef
qualified.  Your code may compile as C++ source, because C++ treats structs
as classes, and the tagname for a class automatically becomes a type; it is
not so in C code, where you must either explicitly supply the typedef
yourself, (when it isn't predeclared in a system header), or you must
explicitly declare your variables as

  struct sockaddr_in my_socket;

and *not* as

  sockaddr_in my_socket;

----------------------------------------------------------------------

Comment By: Eugene M. (bonez92)
Date: 2010-02-28 16:48

Message:
Forgot to include. GCC's version is 4.4.0

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=2960729&group_id=2435

Bugs item #2960729, was opened at 2010-02-28 19:47
Message generated for change (Comment added) made by bonez92
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=2960729&group_id=2435

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: w32api
Group: Behaves as Documented
>Status: Open
Resolution: Invalid
Priority: 5
Private: No
Submitted By: Eugene M. (bonez92)
Assigned to: Nobody/Anonymous (nobody)
Summary: sockaddr_in structure

Initial Comment:
Hi! I am using w32api 3.14.

In winsock2.h sockaddr_in declared as:
struct sockaddr_in {
	short	sin_family;
	u_short	sin_port;
	struct	in_addr sin_addr;
	char	sin_zero[8];
} ;

when trying to compile the code where sockaddr_in is used gcc.exe reports an error "`SOCKADDR_IN' undeclared (first use this function)". g++ doesn't report any errors and compiles successfully.

After changing structure declaration:
typedef struct sockaddr_in {
	short	sin_family;
	u_short	sin_port;
	struct	in_addr sin_addr;
	char	sin_zero[8];
} sockaddr_in;

gcc compiles successfully.

----------------------------------------------------------------------

>Comment By: Eugene M. (bonez92)
Date: 2010-03-01 17:32

Message:
Hmmm... 
If it is bug in my code then how to compile it?
gcc reports the same error as without putting "struct". Here is the code:
//#include <winsock2.h>
#include <stdio.h>
#include <windows.h>

int main(void)
{
	char* header="GET / HTTP 1.1\nHost: localhost\nUser-Agent: MyBot\nAccept:
*/*\nPragma: no-cache\nCache-Control: no-cache\0";
	
	WORD wVersionRequested;
	WSADATA wsaData;
	SOCKET hSocket, client_socket;
    struct sockaddr_in client_addr;
	
	client_addr.sin_family=1;
	client_addr.sin_port=2;
	
	char msg[25];
	int msg_len, client_addr_len;

	wVersionRequested = 2;
	WSAStartup(wVersionRequested, &wsaData);
	
	puts ("HTTP. GET.\n\n");
	
	printf("%d\n", sizeof(sockaddr_in));
	puts (header);
	
	
	
	return 0;
}

I am trying to compile as 
gcc d001.c -o d001.exe -lws2_32

Now what am I doing wrong?

----------------------------------------------------------------------

Comment By: Keith Marshall (keithmarshall)
Date: 2010-03-01 17:16

Message:
AFAICT, this is a bug in *your* code, *not* in MinGW.

According to http://msdn.microsoft.com/en-us/library/zx63b042(VS.80).aspx,
sockaddr_in is correctly declared as a structure tag, but is *not* typedef
qualified.  Your code may compile as C++ source, because C++ treats structs
as classes, and the tagname for a class automatically becomes a type; it is
not so in C code, where you must either explicitly supply the typedef
yourself, (when it isn't predeclared in a system header), or you must
explicitly declare your variables as

  struct sockaddr_in my_socket;

and *not* as

  sockaddr_in my_socket;

----------------------------------------------------------------------

Comment By: Eugene M. (bonez92)
Date: 2010-02-28 19:48

Message:
Forgot to include. GCC's version is 4.4.0

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=2960729&group_id=2435

Bugs item #2960729, was opened at 2010-02-28 19:47
Message generated for change (Comment added) made by bonez92
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=2960729&group_id=2435

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: w32api
Group: Behaves as Documented
Status: Open
Resolution: Invalid
Priority: 5
Private: No
Submitted By: Eugene M. (bonez92)
Assigned to: Nobody/Anonymous (nobody)
Summary: sockaddr_in structure

Initial Comment:
Hi! I am using w32api 3.14.

In winsock2.h sockaddr_in declared as:
struct sockaddr_in {
	short	sin_family;
	u_short	sin_port;
	struct	in_addr sin_addr;
	char	sin_zero[8];
} ;

when trying to compile the code where sockaddr_in is used gcc.exe reports an error "`SOCKADDR_IN' undeclared (first use this function)". g++ doesn't report any errors and compiles successfully.

After changing structure declaration:
typedef struct sockaddr_in {
	short	sin_family;
	u_short	sin_port;
	struct	in_addr sin_addr;
	char	sin_zero[8];
} sockaddr_in;

gcc compiles successfully.

----------------------------------------------------------------------

>Comment By: Eugene M. (bonez92)
Date: 2010-03-01 17:42

Message:
By the way I opened winsock2.h

----------------------------------------------------------------------

Comment By: Eugene M. (bonez92)
Date: 2010-03-01 17:32

Message:
Hmmm... 
If it is bug in my code then how to compile it?
gcc reports the same error as without putting "struct". Here is the code:
//#include <winsock2.h>
#include <stdio.h>
#include <windows.h>

int main(void)
{
	char* header="GET / HTTP 1.1\nHost: localhost\nUser-Agent: MyBot\nAccept:
*/*\nPragma: no-cache\nCache-Control: no-cache\0";
	
	WORD wVersionRequested;
	WSADATA wsaData;
	SOCKET hSocket, client_socket;
    struct sockaddr_in client_addr;
	
	client_addr.sin_family=1;
	client_addr.sin_port=2;
	
	char msg[25];
	int msg_len, client_addr_len;

	wVersionRequested = 2;
	WSAStartup(wVersionRequested, &wsaData);
	
	puts ("HTTP. GET.\n\n");
	
	printf("%d\n", sizeof(sockaddr_in));
	puts (header);
	
	
	
	return 0;
}

I am trying to compile as 
gcc d001.c -o d001.exe -lws2_32

Now what am I doing wrong?

----------------------------------------------------------------------

Comment By: Keith Marshall (keithmarshall)
Date: 2010-03-01 17:16

Message:
AFAICT, this is a bug in *your* code, *not* in MinGW.

According to http://msdn.microsoft.com/en-us/library/zx63b042(VS.80).aspx,
sockaddr_in is correctly declared as a structure tag, but is *not* typedef
qualified.  Your code may compile as C++ source, because C++ treats structs
as classes, and the tagname for a class automatically becomes a type; it is
not so in C code, where you must either explicitly supply the typedef
yourself, (when it isn't predeclared in a system header), or you must
explicitly declare your variables as

  struct sockaddr_in my_socket;

and *not* as

  sockaddr_in my_socket;

----------------------------------------------------------------------

Comment By: Eugene M. (bonez92)
Date: 2010-02-28 19:48

Message:
Forgot to include. GCC's version is 4.4.0

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=2960729&group_id=2435

Bugs item #2960729, was opened at 2010-02-28 19:47
Message generated for change (Comment added) made by bonez92
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=2960729&group_id=2435

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: w32api
Group: Behaves as Documented
Status: Open
Resolution: Invalid
Priority: 5
Private: No
Submitted By: Eugene M. (bonez92)
Assigned to: Nobody/Anonymous (nobody)
Summary: sockaddr_in structure

Initial Comment:
Hi! I am using w32api 3.14.

In winsock2.h sockaddr_in declared as:
struct sockaddr_in {
	short	sin_family;
	u_short	sin_port;
	struct	in_addr sin_addr;
	char	sin_zero[8];
} ;

when trying to compile the code where sockaddr_in is used gcc.exe reports an error "`SOCKADDR_IN' undeclared (first use this function)". g++ doesn't report any errors and compiles successfully.

After changing structure declaration:
typedef struct sockaddr_in {
	short	sin_family;
	u_short	sin_port;
	struct	in_addr sin_addr;
	char	sin_zero[8];
} sockaddr_in;

gcc compiles successfully.

----------------------------------------------------------------------

>Comment By: Eugene M. (bonez92)
Date: 2010-03-01 17:48

Message:
By the way I opened winsock2.h from Microsoft's SDK 6.1 checked out about
sockaddr_in:
typedef struct sockaddr_in FAR *LPSOCKADDR_IN;

Also I opened ws2def.h (that is included by winsock2.h):
typedef struct sockaddr_in {

#if(_WIN32_WINNT < 0x0600)
    short   sin_family;    
#else //(_WIN32_WINNT < 0x0600)
    ADDRESS_FAMILY sin_family;
#endif //(_WIN32_WINNT < 0x0600)

    USHORT sin_port;
    IN_ADDR sin_addr;
    CHAR sin_zero[8];
} SOCKADDR_IN, *PSOCKADDR_IN;

Also I have checked out winsock2.h from MSVS 6.0 (version may be wrong,
but it was released in ~1998):
struct sockaddr_in {
        short   sin_family;
        u_short sin_port;
        struct  in_addr sin_addr;
        char    sin_zero[8];
};
from copy from MSDN.

Does it make sense of something?

----------------------------------------------------------------------

Comment By: Eugene M. (bonez92)
Date: 2010-03-01 17:42

Message:
By the way I opened winsock2.h

----------------------------------------------------------------------

Comment By: Eugene M. (bonez92)
Date: 2010-03-01 17:32

Message:
Hmmm... 
If it is bug in my code then how to compile it?
gcc reports the same error as without putting "struct". Here is the code:
//#include <winsock2.h>
#include <stdio.h>
#include <windows.h>

int main(void)
{
	char* header="GET / HTTP 1.1\nHost: localhost\nUser-Agent: MyBot\nAccept:
*/*\nPragma: no-cache\nCache-Control: no-cache\0";
	
	WORD wVersionRequested;
	WSADATA wsaData;
	SOCKET hSocket, client_socket;
    struct sockaddr_in client_addr;
	
	client_addr.sin_family=1;
	client_addr.sin_port=2;
	
	char msg[25];
	int msg_len, client_addr_len;

	wVersionRequested = 2;
	WSAStartup(wVersionRequested, &wsaData);
	
	puts ("HTTP. GET.\n\n");
	
	printf("%d\n", sizeof(sockaddr_in));
	puts (header);
	
	
	
	return 0;
}

I am trying to compile as 
gcc d001.c -o d001.exe -lws2_32

Now what am I doing wrong?

----------------------------------------------------------------------

Comment By: Keith Marshall (keithmarshall)
Date: 2010-03-01 17:16

Message:
AFAICT, this is a bug in *your* code, *not* in MinGW.

According to http://msdn.microsoft.com/en-us/library/zx63b042(VS.80).aspx,
sockaddr_in is correctly declared as a structure tag, but is *not* typedef
qualified.  Your code may compile as C++ source, because C++ treats structs
as classes, and the tagname for a class automatically becomes a type; it is
not so in C code, where you must either explicitly supply the typedef
yourself, (when it isn't predeclared in a system header), or you must
explicitly declare your variables as

  struct sockaddr_in my_socket;

and *not* as

  sockaddr_in my_socket;

----------------------------------------------------------------------

Comment By: Eugene M. (bonez92)
Date: 2010-02-28 19:48

Message:
Forgot to include. GCC's version is 4.4.0

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=2960729&group_id=2435

Bugs item #2960729, was opened at 2010-02-28 16:47
Message generated for change (Comment added) made by keithmarshall
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=2960729&group_id=2435

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: w32api
Group: Behaves as Documented
>Status: Deleted
Resolution: Invalid
Priority: 5
Private: No
Submitted By: Eugene M. (bonez92)
Assigned to: Nobody/Anonymous (nobody)
Summary: sockaddr_in structure

Initial Comment:
Hi! I am using w32api 3.14.

In winsock2.h sockaddr_in declared as:
struct sockaddr_in {
	short	sin_family;
	u_short	sin_port;
	struct	in_addr sin_addr;
	char	sin_zero[8];
} ;

when trying to compile the code where sockaddr_in is used gcc.exe reports an error "`SOCKADDR_IN' undeclared (first use this function)". g++ doesn't report any errors and compiles successfully.

After changing structure declaration:
typedef struct sockaddr_in {
	short	sin_family;
	u_short	sin_port;
	struct	in_addr sin_addr;
	char	sin_zero[8];
} sockaddr_in;

gcc compiles successfully.

----------------------------------------------------------------------

>Comment By: Keith Marshall (keithmarshall)
Date: 2010-03-02 14:17

Message:
Please DON'T show us code from Microsoft's SDKs!  We aren't allowed to look
at it, and by pushing it in our faces, you poison your ticket; even if this
does identify a legitimate MinGW bug, you force me to delete it, and we can
take no further action against it.

----------------------------------------------------------------------

Comment By: Eugene M. (bonez92)
Date: 2010-03-01 14:42

Message:
By the way I opened winsock2.h

----------------------------------------------------------------------

Comment By: Eugene M. (bonez92)
Date: 2010-03-01 14:32

Message:
Hmmm... 
If it is bug in my code then how to compile it?
gcc reports the same error as without putting "struct". Here is the code:
//#include <winsock2.h>
#include <stdio.h>
#include <windows.h>

int main(void)
{
	char* header="GET / HTTP 1.1\nHost: localhost\nUser-Agent: MyBot\nAccept:
*/*\nPragma: no-cache\nCache-Control: no-cache\0";
	
	WORD wVersionRequested;
	WSADATA wsaData;
	SOCKET hSocket, client_socket;
    struct sockaddr_in client_addr;
	
	client_addr.sin_family=1;
	client_addr.sin_port=2;
	
	char msg[25];
	int msg_len, client_addr_len;

	wVersionRequested = 2;
	WSAStartup(wVersionRequested, &wsaData);
	
	puts ("HTTP. GET.\n\n");
	
	printf("%d\n", sizeof(sockaddr_in));
	puts (header);
	
	
	
	return 0;
}

I am trying to compile as 
gcc d001.c -o d001.exe -lws2_32

Now what am I doing wrong?

----------------------------------------------------------------------

Comment By: Keith Marshall (keithmarshall)
Date: 2010-03-01 14:16

Message:
AFAICT, this is a bug in *your* code, *not* in MinGW.

According to http://msdn.microsoft.com/en-us/library/zx63b042(VS.80).aspx,
sockaddr_in is correctly declared as a structure tag, but is *not* typedef
qualified.  Your code may compile as C++ source, because C++ treats structs
as classes, and the tagname for a class automatically becomes a type; it is
not so in C code, where you must either explicitly supply the typedef
yourself, (when it isn't predeclared in a system header), or you must
explicitly declare your variables as

  struct sockaddr_in my_socket;

and *not* as

  sockaddr_in my_socket;

----------------------------------------------------------------------

Comment By: Eugene M. (bonez92)
Date: 2010-02-28 16:48

Message:
Forgot to include. GCC's version is 4.4.0

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=2960729&group_id=2435

Bugs item #2960729, was opened at 2010-02-28 16:47
Message generated for change (Comment added) made by keithmarshall
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=2960729&group_id=2435

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: w32api
Group: Behaves as Documented
Status: Deleted
Resolution: Invalid
Priority: 5
Private: No
Submitted By: Eugene M. (bonez92)
Assigned to: Nobody/Anonymous (nobody)
Summary: sockaddr_in structure

Initial Comment:
Hi! I am using w32api 3.14.

In winsock2.h sockaddr_in declared as:
struct sockaddr_in {
	short	sin_family;
	u_short	sin_port;
	struct	in_addr sin_addr;
	char	sin_zero[8];
} ;

when trying to compile the code where sockaddr_in is used gcc.exe reports an error "`SOCKADDR_IN' undeclared (first use this function)". g++ doesn't report any errors and compiles successfully.

After changing structure declaration:
typedef struct sockaddr_in {
	short	sin_family;
	u_short	sin_port;
	struct	in_addr sin_addr;
	char	sin_zero[8];
} sockaddr_in;

gcc compiles successfully.

----------------------------------------------------------------------

>Comment By: Keith Marshall (keithmarshall)
Date: 2010-03-02 14:50

Message:
My previous comment notwithstanding, since it isn't my intention to be
unhelpful:--

- I guess you are getting a compilation error saying "`sockaddr_in'
undeclared ..."; this definitely *is* a bug in your code!

- You must #include winsock2.h; in your example, it is commented out.

- The source of your error is *not* related to this declaration:

    struct sockaddr_in client_addr;

which is (now) perfectly correct usage.

- The source of your error *is* this statement:

    printf("%d\n", sizeof(sockaddr_in));

where you are *still* trying to use sockaddr_in as a defined type, which
it isn't; the type you need is `struct sockaddr_in', so change your code
to:

    printf( "%d\n", sizeof( struct sockaddr_in ));

and it should compile correctly.

BTW, it took me longer to strip the copy-and-paste artifact garbage from
your sample code, than it did to subsequently run it through the compiler
and identify your bug.  There is a file attachment facility on these
trackers; please use it, when submitting code samples.

----------------------------------------------------------------------

Comment By: Keith Marshall (keithmarshall)
Date: 2010-03-02 14:17

Message:
Please DON'T show us code from Microsoft's SDKs!  We aren't allowed to look
at it, and by pushing it in our faces, you poison your ticket; even if this
does identify a legitimate MinGW bug, you force me to delete it, and we can
take no further action against it.

----------------------------------------------------------------------

Comment By: Eugene M. (bonez92)
Date: 2010-03-01 14:42

Message:
By the way I opened winsock2.h

----------------------------------------------------------------------

Comment By: Eugene M. (bonez92)
Date: 2010-03-01 14:32

Message:
Hmmm... 
If it is bug in my code then how to compile it?
gcc reports the same error as without putting "struct". Here is the code:
//#include <winsock2.h>
#include <stdio.h>
#include <windows.h>

int main(void)
{
	char* header="GET / HTTP 1.1\nHost: localhost\nUser-Agent: MyBot\nAccept:
*/*\nPragma: no-cache\nCache-Control: no-cache\0";
	
	WORD wVersionRequested;
	WSADATA wsaData;
	SOCKET hSocket, client_socket;
    struct sockaddr_in client_addr;
	
	client_addr.sin_family=1;
	client_addr.sin_port=2;
	
	char msg[25];
	int msg_len, client_addr_len;

	wVersionRequested = 2;
	WSAStartup(wVersionRequested, &wsaData);
	
	puts ("HTTP. GET.\n\n");
	
	printf("%d\n", sizeof(sockaddr_in));
	puts (header);
	
	
	
	return 0;
}

I am trying to compile as 
gcc d001.c -o d001.exe -lws2_32

Now what am I doing wrong?

----------------------------------------------------------------------

Comment By: Keith Marshall (keithmarshall)
Date: 2010-03-01 14:16

Message:
AFAICT, this is a bug in *your* code, *not* in MinGW.

According to http://msdn.microsoft.com/en-us/library/zx63b042(VS.80).aspx,
sockaddr_in is correctly declared as a structure tag, but is *not* typedef
qualified.  Your code may compile as C++ source, because C++ treats structs
as classes, and the tagname for a class automatically becomes a type; it is
not so in C code, where you must either explicitly supply the typedef
yourself, (when it isn't predeclared in a system header), or you must
explicitly declare your variables as

  struct sockaddr_in my_socket;

and *not* as

  sockaddr_in my_socket;

----------------------------------------------------------------------

Comment By: Eugene M. (bonez92)
Date: 2010-02-28 16:48

Message:
Forgot to include. GCC's version is 4.4.0

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=2960729&group_id=2435

Bugs item #2960653, was opened at 2010-02-28 14:07
Message generated for change (Comment added) made by keithmarshall
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=2960653&group_id=2435

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: w32api
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Jacek Caban (cjacek)
Assigned to: Nobody/Anonymous (nobody)
Summary: Invalid cast in POINTTOPOINTS macro

Initial Comment:
POINTTOPOINTS shouldn't cast result of MAKELONG to POINTS, The result should be of type LONG. Attached test proves that. It compiles on MSVC, but doesn't on MinGW. Removing cast in POINTTOPOINTS define fixes the problem.

----------------------------------------------------------------------

>Comment By: Keith Marshall (keithmarshall)
Date: 2010-03-01 13:49

Message:
Thanks for the report.  I agree that there is a problem here; however, your
analysis and proposed solution seem flawed.

According to http://msdn.microsoft.com/en-us/library/dd162810(VS.85).aspx,
the result of POINTTOPOINTS is a POINTS struct.  Simply removing the cast
from the present definition makes the result a LONG, which is incompatible
with the required POINTS struct; changing line 5 of your test case from

  LONG l = POINTTOPOINTS(p);

to

  POINTS l = POINTTOPOINTS(p);

(as it should be for correct usage), proves that your proposed solution is
inappropriate, (notwithstanding that MSVC apparently, and improperly IMO,
appears to compile your sample code).

Surely, something like

  #define POINTTOPOINTS(p)  (POINTS){ (SHORT)((p).x), (SHORT)((p).y) }

is what is required?  (And for some symmetry, in spite of the intrinsic
asymmetry of the prototypes, maybe we could also redefine

  #define POINTSTOPOINT(p,ps)  (p) = (POINT){ (LONG)((ps).x),
(LONG)((ps).y) }

rather than the present hideous address/pointer dereferencing kludge)?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=2960653&group_id=2435

Bugs item #2960653, was opened at 2010-02-28 14:07
Message generated for change (Comment added) made by cjacek
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=2960653&group_id=2435

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: w32api
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Jacek Caban (cjacek)
Assigned to: Nobody/Anonymous (nobody)
Summary: Invalid cast in POINTTOPOINTS macro

Initial Comment:
POINTTOPOINTS shouldn't cast result of MAKELONG to POINTS, The result should be of type LONG. Attached test proves that. It compiles on MSVC, but doesn't on MinGW. Removing cast in POINTTOPOINTS define fixes the problem.

----------------------------------------------------------------------

>Comment By: Jacek Caban (cjacek)
Date: 2010-03-01 19:54

Message:
Thanks for the answer. I believe that MSDN is wrong (again). My test
compiles on MSVC because the result is LONG in MS SDK and that's also what
Mozilla code (which I was trying to compile when I've found this bug)
assumes as well. It's used to pass POINT structure to PostMessage. Given
that, your change won't help.

----------------------------------------------------------------------

Comment By: Keith Marshall (keithmarshall)
Date: 2010-03-01 13:49

Message:
Thanks for the report.  I agree that there is a problem here; however, your
analysis and proposed solution seem flawed.

According to http://msdn.microsoft.com/en-us/library/dd162810(VS.85).aspx,
the result of POINTTOPOINTS is a POINTS struct.  Simply removing the cast
from the present definition makes the result a LONG, which is incompatible
with the required POINTS struct; changing line 5 of your test case from

  LONG l = POINTTOPOINTS(p);

to

  POINTS l = POINTTOPOINTS(p);

(as it should be for correct usage), proves that your proposed solution is
inappropriate, (notwithstanding that MSVC apparently, and improperly IMO,
appears to compile your sample code).

Surely, something like

  #define POINTTOPOINTS(p)  (POINTS){ (SHORT)((p).x), (SHORT)((p).y) }

is what is required?  (And for some symmetry, in spite of the intrinsic
asymmetry of the prototypes, maybe we could also redefine

  #define POINTSTOPOINT(p,ps)  (p) = (POINT){ (LONG)((ps).x),
(LONG)((ps).y) }

rather than the present hideous address/pointer dereferencing kludge)?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=2960653&group_id=2435

Bugs item #2960226, was opened at 2010-02-27 15:00
Message generated for change (Settings changed) made by keithmarshall
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=2960226&group_id=2435

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: w32api
>Group: Behaves as Documented
>Status: Closed
>Resolution: Invalid
Priority: 5
Private: No
Submitted By: Francois Grieu (fgrieu)
Assigned to: Nobody/Anonymous (nobody)
Summary: SystemTimeToTzSpecificLocalTime prototype constness

Initial Comment:
I get "warning: passing arg 2 of `SystemTimeToTzSpecificLocalTime' discards qualifiers from pointer target type" for the valid code given below.

In winbase.h from w32api-3.13-mingw32-dev there is
WINBASEAPI BOOL WINAPI SystemTimeToTzSpecificLocalTime(LPTIME_ZONE_INFORMATION,LPSYSTEMTIME,LPSYSTEMTIME);
which I guess should be changed to
WINBASEAPI BOOL WINAPI SystemTimeToTzSpecificLocalTime(LPTIME_ZONE_INFORMATION,const SYSTEMTIME*,LPSYSTEMTIME);

Code extract causing the issue:

#include <windows.h>

// type for a frame
typedef struct tFrame
	{
	SYSTEMTIME		fDate;			// system time on first byte of the frame
	} tFrame;

void zShowFrame(const tFrame *inFrame)
	{
	SYSTEMTIME vLocalTime;
	(void)SystemTimeToTzSpecificLocalTime(NULL,&inFrame->fDate,&vLocalTime);
	}


----------------------------------------------------------------------

>Comment By: Keith Marshall (keithmarshall)
Date: 2010-02-27 19:19

Message:
Sorry, but I must disagree with your presumption of validity, in your
sample code.  The MinGW prototype for the SystemTimeToTzSpecificLocalTime()
function *exactly* matches that documented by Microsoft on MSDN; there is
absolutely no promise of constancy in the entity referenced by the second,
or any other argument.

The fault here is in your code; in your zShowFrame() function, you promise
constancy of the struct referenced by its argument, yet you then pass a
reference to one of its members to the SystemTimeToTzSpecificLocalTime()
function, which makes no such supporting promise, *may* modify the
referenced entity, and therefore may cause your function to break its
promise.  GCC is quite correct to warn you of this possibility.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=2960226&group_id=2435

Bugs item #2960226, was opened at 2010-02-27 16:00
Message generated for change (Comment added) made by fgrieu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=2960226&group_id=2435

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: w32api
Group: Behaves as Documented
Status: Closed
Resolution: Invalid
Priority: 5
Private: No
Submitted By: Francois Grieu (fgrieu)
Assigned to: Nobody/Anonymous (nobody)
Summary: SystemTimeToTzSpecificLocalTime prototype constness

Initial Comment:
I get "warning: passing arg 2 of `SystemTimeToTzSpecificLocalTime' discards qualifiers from pointer target type" for the valid code given below.

In winbase.h from w32api-3.13-mingw32-dev there is
WINBASEAPI BOOL WINAPI SystemTimeToTzSpecificLocalTime(LPTIME_ZONE_INFORMATION,LPSYSTEMTIME,LPSYSTEMTIME);
which I guess should be changed to
WINBASEAPI BOOL WINAPI SystemTimeToTzSpecificLocalTime(LPTIME_ZONE_INFORMATION,const SYSTEMTIME*,LPSYSTEMTIME);

Code extract causing the issue:

#include <windows.h>

// type for a frame
typedef struct tFrame
	{
	SYSTEMTIME		fDate;			// system time on first byte of the frame
	} tFrame;

void zShowFrame(const tFrame *inFrame)
	{
	SYSTEMTIME vLocalTime;
	(void)SystemTimeToTzSpecificLocalTime(NULL,&inFrame->fDate,&vLocalTime);
	}


----------------------------------------------------------------------

Comment By: Francois Grieu (fgrieu)
Date: 2010-03-01 09:27

Message:
May I point that
1) the second parameter to SystemTimeToTzSpecificLocalTime *IS POSITIVELY*
a const pointer in the current Windows SDK released last July; see
GRMSDK_EN_DVD.iso available from
http://www.microsoft.com/downloads/details.aspx?FamilyID=71DEB800-C591-4F97-A900-BEA146E4FAE1
2) adding the constness to the prototype (on the first two arguments)
should not break any existing code.

Granted
- this is new (that was not in SDK 5, did not check 6)
- this is not (yet?) reflected by the online help on
SystemTimeToTzSpecificLocalTime at
http://msdn.microsoft.com/en-us/library/ms724949%28VS.85%29.aspx

Here are the relevant extracts of my copies of C:\Program Files\Microsoft
SDKs\Windows\v7.0\Include\WinBase.h

WINBASEAPI
BOOL
WINAPI
SystemTimeToTzSpecificLocalTime(
    __in_opt CONST TIME_ZONE_INFORMATION *lpTimeZoneInformation,
    __in     CONST SYSTEMTIME *lpUniversalTime,
    __out    LPSYSTEMTIME lpLocalTime
    );

	
and C:\Program Files\Microsoft SDKs\Windows\v5.0\Include\WinBase.h
	
WINBASEAPI
BOOL
WINAPI
SystemTimeToTzSpecificLocalTime(
    __in_opt LPTIME_ZONE_INFORMATION lpTimeZoneInformation,
    __in     LPSYSTEMTIME lpUniversalTime,
    __out    LPSYSTEMTIME lpLocalTime
    );


----------------------------------------------------------------------

Comment By: Keith Marshall (keithmarshall)
Date: 2010-02-27 20:19

Message:
Sorry, but I must disagree with your presumption of validity, in your
sample code.  The MinGW prototype for the SystemTimeToTzSpecificLocalTime()
function *exactly* matches that documented by Microsoft on MSDN; there is
absolutely no promise of constancy in the entity referenced by the second,
or any other argument.

The fault here is in your code; in your zShowFrame() function, you promise
constancy of the struct referenced by its argument, yet you then pass a
reference to one of its members to the SystemTimeToTzSpecificLocalTime()
function, which makes no such supporting promise, *may* modify the
referenced entity, and therefore may cause your function to break its
promise.  GCC is quite correct to warn you of this possibility.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=2960226&group_id=2435

Bugs item #2960226, was opened at 2010-02-27 15:00
Message generated for change (Comment added) made by keithmarshall
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=2960226&group_id=2435

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: w32api
Group: Behaves as Documented
>Status: Deleted
Resolution: Invalid
Priority: 5
Private: No
Submitted By: Francois Grieu (fgrieu)
Assigned to: Nobody/Anonymous (nobody)
Summary: SystemTimeToTzSpecificLocalTime prototype constness

Initial Comment:
I get "warning: passing arg 2 of `SystemTimeToTzSpecificLocalTime' discards qualifiers from pointer target type" for the valid code given below.

In winbase.h from w32api-3.13-mingw32-dev there is
WINBASEAPI BOOL WINAPI SystemTimeToTzSpecificLocalTime(LPTIME_ZONE_INFORMATION,LPSYSTEMTIME,LPSYSTEMTIME);
which I guess should be changed to
WINBASEAPI BOOL WINAPI SystemTimeToTzSpecificLocalTime(LPTIME_ZONE_INFORMATION,const SYSTEMTIME*,LPSYSTEMTIME);

Code extract causing the issue:

#include <windows.h>

// type for a frame
typedef struct tFrame
	{
	SYSTEMTIME		fDate;			// system time on first byte of the frame
	} tFrame;

void zShowFrame(const tFrame *inFrame)
	{
	SYSTEMTIME vLocalTime;
	(void)SystemTimeToTzSpecificLocalTime(NULL,&inFrame->fDate,&vLocalTime);
	}


----------------------------------------------------------------------

>Comment By: Keith Marshall (keithmarshall)
Date: 2010-03-01 11:16

Message:
May I point out that, by quoting from proprietary Microsoft SDK headers,
you have now poisoned this ticket, irretrievably.  I *must* now delete it,
and no further action can be taken in this respect.

----------------------------------------------------------------------

Comment By: Francois Grieu (fgrieu)
Date: 2010-03-01 08:27

Message:
May I point that
1) the second parameter to SystemTimeToTzSpecificLocalTime *IS POSITIVELY*
a const pointer in the current Windows SDK released last July; see
GRMSDK_EN_DVD.iso available from
http://www.microsoft.com/downloads/details.aspx?FamilyID=71DEB800-C591-4F97-A900-BEA146E4FAE1
2) adding the constness to the prototype (on the first two arguments)
should not break any existing code.

Granted
- this is new (that was not in SDK 5, did not check 6)
- this is not (yet?) reflected by the online help on
SystemTimeToTzSpecificLocalTime at
http://msdn.microsoft.com/en-us/library/ms724949%28VS.85%29.aspx

Here are the relevant extracts of my copies of C:\Program Files\Microsoft
SDKs\Windows\v7.0\Include\WinBase.h

WINBASEAPI
BOOL
WINAPI
SystemTimeToTzSpecificLocalTime(
    __in_opt CONST TIME_ZONE_INFORMATION *lpTimeZoneInformation,
    __in     CONST SYSTEMTIME *lpUniversalTime,
    __out    LPSYSTEMTIME lpLocalTime
    );

	
and C:\Program Files\Microsoft SDKs\Windows\v5.0\Include\WinBase.h
	
WINBASEAPI
BOOL
WINAPI
SystemTimeToTzSpecificLocalTime(
    __in_opt LPTIME_ZONE_INFORMATION lpTimeZoneInformation,
    __in     LPSYSTEMTIME lpUniversalTime,
    __out    LPSYSTEMTIME lpLocalTime
    );


----------------------------------------------------------------------

Comment By: Keith Marshall (keithmarshall)
Date: 2010-02-27 19:19

Message:
Sorry, but I must disagree with your presumption of validity, in your
sample code.  The MinGW prototype for the SystemTimeToTzSpecificLocalTime()
function *exactly* matches that documented by Microsoft on MSDN; there is
absolutely no promise of constancy in the entity referenced by the second,
or any other argument.

The fault here is in your code; in your zShowFrame() function, you promise
constancy of the struct referenced by its argument, yet you then pass a
reference to one of its members to the SystemTimeToTzSpecificLocalTime()
function, which makes no such supporting promise, *may* modify the
referenced entity, and therefore may cause your function to break its
promise.  GCC is quite correct to warn you of this possibility.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=2960226&group_id=2435

Bugs item #2955201, was opened at 2010-02-19 21:40
Message generated for change (Comment added) made by keithmarshall
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=2955201&group_id=2435

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
>Group: Known Feature
>Status: Closed
>Resolution: Invalid
>Priority: 5
Private: No
Submitted By: Glenn Rhoads (gcrhoads)
Assigned to: Nobody/Anonymous (nobody)
Summary: "Bad file number" 

Initial Comment:
When trying to execute the file names "patcher.exe" which
compiled without errors, I receive the following error message.

sh: ./patcher.exe : Bad file number

Environment details:
I'm running under Windows Vista
gcc version 3.4.5 (mingw-vista special r3)
Binutils linker version 2.20
Using MSYS 1.0.11

The output from entering "gcc -v" is

Reading specs from c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/specs
Configured with: ../gcc-3.4.5-20060117-3/configure --with-gcc --with-gnu-ld --with-gnu-as --host=mingw32 --target=mingw32 --prefix=/mingw --enable-threads --disable-shared --enable-languages=c,c++,f77,ada,objc,java --disable-win32-registry --disable-shared --enable sjlj-exceptions --enable-libgcj --disable-java-awt --without-x --enable-java-gc=boehm --disable-libgcj-debug --enable-interpreter --enable-hash-synchronization --enable-libstdcxx-debug
Thread model: win32
gcc version 3.4.5 (mingw-vista special r3)

The output of entering "ld -v" is
GNU ld (GNU Binutils) 2.20

Note that my program makes use of the "QD" high-precision
library (version 2.3.9) which can be downloaded from
http://crd.lbl.gov/~dhbailey/mpdist/  (the file is
qd-2.3.9.tar.gz).

I successfully installed this package -- it passed all the tests
performed by the test programs.  Also, I have several other
C++ programs which use this package and all of them work
correctly.

Any idea of what the problem might be and how to fix it?

Note that the code for this program, and the other ones
that use the QD package, is very complex and is made
up of 4 or 5 source files.   I haven't been able to
reproduce this error on a simpler test case but I will try
again later.


----------------------------------------------------------------------

>Comment By: Keith Marshall (keithmarshall)
Date: 2010-02-27 19:49

Message:
As noted in the complementary discussion on the users' list, you seem to
have fallen foul of a Vista/Windows-7 quirk, whereby the system refuses to
run programs with names such as

  <anything>setup<anything>.exe
  <anything>instal<anything>.exe
  <anything>patch<anything>.exe

without privilege escalation.  The only possible bug here is that MSYS
provides a less than helpful diagnostic message, but presumably the system
hasn't set an errno which would let it do better.  The solution, for you,
is to choose an alternative program name, which doesn't match any
heuristically questionable prototype, or to provide a manifest file to
placate the system.

----------------------------------------------------------------------

Comment By: Glenn Rhoads (gcrhoads)
Date: 2010-02-23 20:15

Message:
When I execute the program through the Command Prompt window (cmd.exe), my
program works correctly!  So I have a workaround solution.


----------------------------------------------------------------------

Comment By: Glenn Rhoads (gcrhoads)
Date: 2010-02-23 15:35

Message:
I managed to create a very small "do-nothing" program that has the same
problem.
I'm attaching this example program.  From the example, it is obvious that
the problem has nothing to do with my code but is instead a problem with
MinGW/mysys/gcc

Note that I really need to get this problem fixed in order to finish my
research project.  After finishing the project, I plan on writing up the
results and submitting it to a research journal for publication.

-- Dr. Glenn C. Rhoads


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=2955201&group_id=2435

Patches item #2955991, was opened at 2010-02-21 17:56
Message generated for change (Comment added) made by crazyjacky
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=302435&aid=2955991&group_id=2435

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Jacky Lai (crazyjacky)
Assigned to: Nobody/Anonymous (nobody)
Summary: Fix swprintf/vswprintf when compiled with -ansi switch

Initial Comment:
Refer to https://sourceforge.net/tracker/index.php?func=detail&aid=2373234&group_id=2435&atid=102435
This patch implements swprintf() and vswprintf() as inline functions when __STRICT_ANSI__ is present

It also handles correct ISO C declarations of swprintf() and vswprintf() in msvcr80.dll
(http://msdn.microsoft.com/en-us/library/ybk95axf%28VS.80%29.aspx)

----------------------------------------------------------------------

>Comment By: Jacky Lai (crazyjacky)
Date: 2010-02-27 01:22

Message:
A new patch is attached.
1. The two functions are now implemented as inline functions in
stdio.h/wchar.h
2, msvcr80.dll and msvcr90.dll do not export swprintf() or vswprintf(),
so do not add them in corresponding def file

----------------------------------------------------------------------

Comment By: Jacky Lai (crazyjacky)
Date: 2010-02-25 00:42

Message:
I just found out that msvcr80.dll does not export the functions.
I will post another patch tomorrow

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=302435&aid=2955991&group_id=2435