[prev in list] [next in list] [prev in thread] [next in thread] 

List:       mingw-notify
Subject:    MinGW-notify Digest, Vol 46, Issue 2
From:       mingw-notify-request () lists ! sourceforge ! net
Date:       2010-03-01 19:54:10
Message-ID: mailman.46382.1267473250.5170.mingw-notify () lists ! sourceforge ! net
[Download RAW message or body]

Send MinGW-notify mailing list submissions to
	mingw-notify@lists.sourceforge.net

To subscribe or unsubscribe via the World Wide Web, visit
	https://lists.sourceforge.net/lists/listinfo/mingw-notify
or, via email, send a message with subject or body 'help' to
	mingw-notify-request@lists.sourceforge.net

You can reach the person managing the list at
	mingw-notify-owner@lists.sourceforge.net

When replying, please edit your Subject line so it is more specific
than "Re: Contents of MinGW-notify digest..."


This list is used to send updates of submitted patches, bug reports and file \
releases.  You are discouraged from posting to this list.  If you wish to unsubscribe \
you can do so at https://lists.sourceforge.net/lists/listinfo/mingw-notify.

Today's Topics:

   1. [ mingw-Bugs-2960653 ] Invalid cast in POINTTOPOINTS	macro
      (SourceForge.net)
   2. [ mingw-Bugs-2960729 ] sockaddr_in structure (SourceForge.net)
   3. [ mingw-Bugs-2960729 ] sockaddr_in structure (SourceForge.net)
   4. [ mingw-Bugs-2960729 ] sockaddr_in structure (SourceForge.net)
   5. [ mingw-Bugs-2960729 ] sockaddr_in structure (SourceForge.net)
   6. [ mingw-Bugs-2960653 ] Invalid cast in POINTTOPOINTS	macro
      (SourceForge.net)


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

Message: 1
Date: Mon, 01 Mar 2010 13:49:01 +0000
From: "SourceForge.net" <noreply@sourceforge.net>
Subject: [Mingw-notify] [ mingw-Bugs-2960653 ] Invalid cast in
	POINTTOPOINTS	macro
To: noreply@sourceforge.net
Message-ID: <E1Nm5zZ-0004jw-D5@sfs-web-4.v29.ch3.sourceforge.com>
Content-Type: text/plain; charset="UTF-8"

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



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

Message: 2
Date: Mon, 01 Mar 2010 14:16:30 +0000
From: "SourceForge.net" <noreply@sourceforge.net>
Subject: [Mingw-notify] [ mingw-Bugs-2960729 ] sockaddr_in structure
To: noreply@sourceforge.net
Message-ID: <E1Nm6QA-0005wz-NL@sfs-web-10.v29.ch3.sourceforge.com>
Content-Type: text/plain; charset="UTF-8"

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



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

Message: 3
Date: Mon, 01 Mar 2010 14:32:10 +0000
From: "SourceForge.net" <noreply@sourceforge.net>
Subject: [Mingw-notify] [ mingw-Bugs-2960729 ] sockaddr_in structure
To: noreply@sourceforge.net
Message-ID: <E1Nm6fK-0000ji-05@sfs-web-6.v29.ch3.sourceforge.com>
Content-Type: text/plain; charset="UTF-8"

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



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

Message: 4
Date: Mon, 01 Mar 2010 14:42:09 +0000
From: "SourceForge.net" <noreply@sourceforge.net>
Subject: [Mingw-notify] [ mingw-Bugs-2960729 ] sockaddr_in structure
To: noreply@sourceforge.net
Message-ID: <E1Nm6oz-0005q2-0k@sfs-web-4.v29.ch3.sourceforge.com>
Content-Type: text/plain; charset="UTF-8"

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



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

Message: 5
Date: Mon, 01 Mar 2010 14:48:28 +0000
From: "SourceForge.net" <noreply@sourceforge.net>
Subject: [Mingw-notify] [ mingw-Bugs-2960729 ] sockaddr_in structure
To: noreply@sourceforge.net
Message-ID: <E1Nm6v6-0006o6-3v@sfs-web-2.v29.ch3.sourceforge.com>
Content-Type: text/plain; charset="UTF-8"

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



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

Message: 6
Date: Mon, 01 Mar 2010 19:54:09 +0000
From: "SourceForge.net" <noreply@sourceforge.net>
Subject: [Mingw-notify] [ mingw-Bugs-2960653 ] Invalid cast in
	POINTTOPOINTS	macro
To: noreply@sourceforge.net
Message-ID: <E1NmBgv-0007ed-Cq@sfs-web-6.v29.ch3.sourceforge.com>
Content-Type: text/plain; charset="UTF-8"

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



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

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev

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

_______________________________________________
MinGW-notify mailing list
MinGW-notify@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-notify


End of MinGW-notify Digest, Vol 46, Issue 2
*******************************************


[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic