Re: [Mingw-w64-public] include: fix mingw64 build
On 07/15/12 14:21, Nicolas Le Cam wrote: > 2012/7/4 Jacek Caban : >> On 07/03/12 20:10, Jacek Caban wrote: >>> On 06/29/12 03:35, Austin English wrote: On Thu, Jun 28, 2012 at 6:30 PM, Nicolas Le Cam wrote: > 2012/6/29 Austin English : >> Fixes http://bugs.winehq.org/show_bug.cgi?id=30980 >> >> -- >> -Austin >> >> >> > Hi Austin, > > I already tried to fix it on Wine side, see [1], > but Alexandre told me on IRC that the bug needs to be fixed in mingw-w64, > as it shouldn't include crtdefs.h by default. > > BTW, won't that break mingw32 build ? > > [1] http://source.winehq.org/patches/data/84070 > > -- > Nicolas Le Cam Thanks for the info. Have you or anyone else discussed this with mingw64? I did a quick search on their bugtracker, but don't see anything.. http://sourceforge.net/search/?group_artifact_id=983354&type_of_search=artifact&group_id=202880&words=crtdefs >>> FWIW, here is my proposed patch to mingw-w64: >>> >>> http://repo.or.cz/w/mingw-w64/jacek.git/commitdiff/5db96424c7b9ac4aa5a66bd0e9724740624bf96f >>> >>> We will see if they like it. >> The (extended) fix is in mingw-w64 SVN now. >> >> Jacek >> >> >> >> > Hi Jacek, > > Could it be backported into stable 2.x ? This will allow distros to > package it with the next stable release of mingw-w64. I'm not sure bout that, it's quite an invasive change, so it may be too risky for stable branch. I'm CCing mingw-w64 ML to see what maintainers think. BTW, our Wine Gecko package requires trunk version, so distros compiling it themselves have provide its packages anyway (I don't really follow it close enough to have more details). It may be a good idea to use this version for Wine development. Jacek -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] include: fix mingw64 build
On Mon, Jul 16, 2012 at 11:33 AM, Jacek Caban wrote: > On 07/15/12 14:21, Nicolas Le Cam wrote: >> 2012/7/4 Jacek Caban : >>> On 07/03/12 20:10, Jacek Caban wrote: On 06/29/12 03:35, Austin English wrote: > On Thu, Jun 28, 2012 at 6:30 PM, Nicolas Le Cam > wrote: >> 2012/6/29 Austin English : >>> Fixes http://bugs.winehq.org/show_bug.cgi?id=30980 >>> >>> -- >>> -Austin >>> >>> >>> >> Hi Austin, >> >> I already tried to fix it on Wine side, see [1], >> but Alexandre told me on IRC that the bug needs to be fixed in mingw-w64, >> as it shouldn't include crtdefs.h by default. >> >> BTW, won't that break mingw32 build ? >> >> [1] http://source.winehq.org/patches/data/84070 >> >> -- >> Nicolas Le Cam > Thanks for the info. Have you or anyone else discussed this with > mingw64? I did a quick search on their bugtracker, but don't see > anything.. > http://sourceforge.net/search/?group_artifact_id=983354&type_of_search=artifact&group_id=202880&words=crtdefs FWIW, here is my proposed patch to mingw-w64: http://repo.or.cz/w/mingw-w64/jacek.git/commitdiff/5db96424c7b9ac4aa5a66bd0e9724740624bf96f We will see if they like it. >>> The (extended) fix is in mingw-w64 SVN now. >>> >>> Jacek >>> >>> >>> >>> >> Hi Jacek, >> >> Could it be backported into stable 2.x ? This will allow distros to >> package it with the next stable release of mingw-w64. > > I'm not sure bout that, it's quite an invasive change, so it may be too > risky for stable branch. I'm CCing mingw-w64 ML to see what maintainers > think. The repo.cz link gives "404 - Unknown commit object". If this is the crtdefs.h commit that went into the trunk, if the admins are OK with it then I am OK with it, too and feel free to test a patch and commit in that case. > > BTW, our Wine Gecko package requires trunk version, so distros compiling > it themselves have provide its packages anyway (I don't really follow it > close enough to have more details). It may be a good idea to use this > version for Wine development. > > Jacek -- O.S. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] include: fix mingw64 build
On 07/16/12 11:02, Ozkan Sezer wrote: > On Mon, Jul 16, 2012 at 11:33 AM, Jacek Caban wrote: >> On 07/15/12 14:21, Nicolas Le Cam wrote: >>> 2012/7/4 Jacek Caban : On 07/03/12 20:10, Jacek Caban wrote: > On 06/29/12 03:35, Austin English wrote: >> On Thu, Jun 28, 2012 at 6:30 PM, Nicolas Le Cam >> wrote: >>> 2012/6/29 Austin English : Fixes http://bugs.winehq.org/show_bug.cgi?id=30980 -- -Austin >>> Hi Austin, >>> >>> I already tried to fix it on Wine side, see [1], >>> but Alexandre told me on IRC that the bug needs to be fixed in >>> mingw-w64, >>> as it shouldn't include crtdefs.h by default. >>> >>> BTW, won't that break mingw32 build ? >>> >>> [1] http://source.winehq.org/patches/data/84070 >>> >>> -- >>> Nicolas Le Cam >> Thanks for the info. Have you or anyone else discussed this with >> mingw64? I did a quick search on their bugtracker, but don't see >> anything.. >> http://sourceforge.net/search/?group_artifact_id=983354&type_of_search=artifact&group_id=202880&words=crtdefs > FWIW, here is my proposed patch to mingw-w64: > > http://repo.or.cz/w/mingw-w64/jacek.git/commitdiff/5db96424c7b9ac4aa5a66bd0e9724740624bf96f > > We will see if they like it. The (extended) fix is in mingw-w64 SVN now. Jacek >>> Hi Jacek, >>> >>> Could it be backported into stable 2.x ? This will allow distros to >>> package it with the next stable release of mingw-w64. >> I'm not sure bout that, it's quite an invasive change, so it may be too >> risky for stable branch. I'm CCing mingw-w64 ML to see what maintainers >> think. > The repo.cz link gives "404 - Unknown commit object". If this is the > crtdefs.h commit that went into the trunk, Yes, that's this commit. For the reference, here is the committed diff: http://repo.or.cz/w/mingw-w64/jacek.git/commitdiff/8c4da30fd44a7a47e7ba64a0c461d409146b6ae3 > if the admins are OK with it > then I am OK with it, too and feel free to test a patch and commit in > that case. OK, thanks. Jacek -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] include: fix mingw64 build
On 7/16/2012 16:33, Jacek Caban wrote: > On 07/15/12 14:21, Nicolas Le Cam wrote: >> 2012/7/4 Jacek Caban: >>> On 07/03/12 20:10, Jacek Caban wrote: On 06/29/12 03:35, Austin English wrote: > On Thu, Jun 28, 2012 at 6:30 PM, Nicolas Le Cam wrote: >> 2012/6/29 Austin English : >>> Fixes http://bugs.winehq.org/show_bug.cgi?id=30980 >>> >>> -- >>> -Austin >>> >>> >>> >> Hi Austin, >> >> I already tried to fix it on Wine side, see [1], >> but Alexandre told me on IRC that the bug needs to be fixed in mingw-w64, >> as it shouldn't include crtdefs.h by default. >> >> BTW, won't that break mingw32 build ? >> >> [1] http://source.winehq.org/patches/data/84070 >> >> -- >> Nicolas Le Cam > Thanks for the info. Have you or anyone else discussed this with > mingw64? I did a quick search on their bugtracker, but don't see > anything.. > http://sourceforge.net/search/?group_artifact_id=983354&type_of_search=artifact&group_id=202880&words=crtdefs FWIW, here is my proposed patch to mingw-w64: http://repo.or.cz/w/mingw-w64/jacek.git/commitdiff/5db96424c7b9ac4aa5a66bd0e9724740624bf96f We will see if they like it. >>> The (extended) fix is in mingw-w64 SVN now. >>> >>> Jacek >>> >>> >>> >>> >> Hi Jacek, >> >> Could it be backported into stable 2.x ? This will allow distros to >> package it with the next stable release of mingw-w64. > > I'm not sure bout that, it's quite an invasive change, so it may be too > risky for stable branch. I'm CCing mingw-w64 ML to see what maintainers > think. > > BTW, our Wine Gecko package requires trunk version, so distros compiling > it themselves have provide its packages anyway (I don't really follow it > close enough to have more details). It may be a good idea to use this > version for Wine development. > > Jacek Hi, Those 2 links above seem to not lead anywhere, the wine link shows something about _INC_CRTDEFS. Can you elaborate more? signature.asc Description: OpenPGP digital signature -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] include: fix mingw64 build
On 07/16/12 11:06, JonY wrote: > On 7/16/2012 16:33, Jacek Caban wrote: >> On 07/15/12 14:21, Nicolas Le Cam wrote: >>> 2012/7/4 Jacek Caban: On 07/03/12 20:10, Jacek Caban wrote: > On 06/29/12 03:35, Austin English wrote: >> On Thu, Jun 28, 2012 at 6:30 PM, Nicolas Le Cam wrote: >>> 2012/6/29 Austin English : Fixes http://bugs.winehq.org/show_bug.cgi?id=30980 -- -Austin >>> Hi Austin, >>> >>> I already tried to fix it on Wine side, see [1], >>> but Alexandre told me on IRC that the bug needs to be fixed in >>> mingw-w64, >>> as it shouldn't include crtdefs.h by default. >>> >>> BTW, won't that break mingw32 build ? >>> >>> [1] http://source.winehq.org/patches/data/84070 >>> >>> -- >>> Nicolas Le Cam >> Thanks for the info. Have you or anyone else discussed this with >> mingw64? I did a quick search on their bugtracker, but don't see >> anything.. >> http://sourceforge.net/search/?group_artifact_id=983354&type_of_search=artifact&group_id=202880&words=crtdefs > FWIW, here is my proposed patch to mingw-w64: > > http://repo.or.cz/w/mingw-w64/jacek.git/commitdiff/5db96424c7b9ac4aa5a66bd0e9724740624bf96f > > We will see if they like it. The (extended) fix is in mingw-w64 SVN now. Jacek >>> Hi Jacek, >>> >>> Could it be backported into stable 2.x ? This will allow distros to >>> package it with the next stable release of mingw-w64. >> I'm not sure bout that, it's quite an invasive change, so it may be too >> risky for stable branch. I'm CCing mingw-w64 ML to see what maintainers >> think. >> >> BTW, our Wine Gecko package requires trunk version, so distros compiling >> it themselves have provide its packages anyway (I don't really follow it >> close enough to have more details). It may be a good idea to use this >> version for Wine development. >> >> Jacek > Hi, > > Those 2 links above seem to not lead anywhere, the wine link shows > something about _INC_CRTDEFS. > > Can you elaborate more? Sorry about that, I treat my git repository as a temporary place for patch reviews, so they may disappear once I push new versions. Here is a link to a patch already committed to the trunk (which should be persistent since it's already in mingw-w64): http://repo.or.cz/w/mingw-w64/jacek.git/commitdiff/8c4da30fd44a7a47e7ba64a0c461d409146b6ae3 Jacek -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] include: fix mingw64 build
On 7/16/2012 17:19, Jacek Caban wrote: > Sorry about that, I treat my git repository as a temporary place for > patch reviews, so they may disappear once I push new versions. Here is a > link to a patch already committed to the trunk (which should be > persistent since it's already in mingw-w64): > > http://repo.or.cz/w/mingw-w64/jacek.git/commitdiff/8c4da30fd44a7a47e7ba64a0c461d409146b6ae3 > > Jacek > > Looks like there are a lot of changes, but mostly cosmetic changes and moving things about, not exactly new stuff. Is the change part of a series of change? Are there any actual functionality change? If so, backporting might not be a good idea. If not, I'm OK with backporting, but Kai and Ozkan should comment on it first. signature.asc Description: OpenPGP digital signature -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] include: fix mingw64 build
On Mon, Jul 16, 2012 at 1:38 PM, JonY wrote: > On 7/16/2012 17:19, Jacek Caban wrote: >> Sorry about that, I treat my git repository as a temporary place for >> patch reviews, so they may disappear once I push new versions. Here is a >> link to a patch already committed to the trunk (which should be >> persistent since it's already in mingw-w64): >> >> http://repo.or.cz/w/mingw-w64/jacek.git/commitdiff/8c4da30fd44a7a47e7ba64a0c461d409146b6ae3 >> >> Jacek >> >> > > Looks like there are a lot of changes, but mostly cosmetic changes and > moving things about, not exactly new stuff. > > Is the change part of a series of change? Are there any actual > functionality change? > > If so, backporting might not be a good idea. If not, I'm OK with > backporting, but Kai and Ozkan should comment on it first. > IIRC, the patch didn't do any functionality changes. I'm OK with the admins' decisions on this one. -- O.S. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] include: fix mingw64 build
On 7/16/2012 18:46, Ozkan Sezer wrote: > On Mon, Jul 16, 2012 at 1:38 PM, JonY wrote: >> On 7/16/2012 17:19, Jacek Caban wrote: >>> Sorry about that, I treat my git repository as a temporary place for >>> patch reviews, so they may disappear once I push new versions. Here is a >>> link to a patch already committed to the trunk (which should be >>> persistent since it's already in mingw-w64): >>> >>> http://repo.or.cz/w/mingw-w64/jacek.git/commitdiff/8c4da30fd44a7a47e7ba64a0c461d409146b6ae3 >>> >>> Jacek >>> >>> >> >> Looks like there are a lot of changes, but mostly cosmetic changes and >> moving things about, not exactly new stuff. >> >> Is the change part of a series of change? Are there any actual >> functionality change? >> >> If so, backporting might not be a good idea. If not, I'm OK with >> backporting, but Kai and Ozkan should comment on it first. >> > > IIRC, the patch didn't do any functionality changes. I'm OK with the admins' > decisions on this one. > On closer inspection, it looks like all it does is fix a cross compile case with Wine, no real change to mingw-w64 itself, I'd say it's good to go. Kai? signature.asc Description: OpenPGP digital signature -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] include: fix mingw64 build
On 7/16/2012 19:10, JonY wrote: > On 7/16/2012 18:46, Ozkan Sezer wrote: >> On Mon, Jul 16, 2012 at 1:38 PM, JonY wrote: >>> On 7/16/2012 17:19, Jacek Caban wrote: Sorry about that, I treat my git repository as a temporary place for patch reviews, so they may disappear once I push new versions. Here is a link to a patch already committed to the trunk (which should be persistent since it's already in mingw-w64): http://repo.or.cz/w/mingw-w64/jacek.git/commitdiff/8c4da30fd44a7a47e7ba64a0c461d409146b6ae3 Jacek >>> >>> Looks like there are a lot of changes, but mostly cosmetic changes and >>> moving things about, not exactly new stuff. >>> >>> Is the change part of a series of change? Are there any actual >>> functionality change? >>> >>> If so, backporting might not be a good idea. If not, I'm OK with >>> backporting, but Kai and Ozkan should comment on it first. >>> >> >> IIRC, the patch didn't do any functionality changes. I'm OK with the admins' >> decisions on this one. >> > > On closer inspection, it looks like all it does is fix a cross compile > case with Wine, no real change to mingw-w64 itself, I'd say it's good to go. > > Kai? > Hi Ozkan, Kai approved by IRC, so feel free to commit the backport. signature.asc Description: OpenPGP digital signature -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] include: fix mingw64 build
On Mon, Jul 16, 2012 at 3:03 PM, JonY wrote: > On 7/16/2012 19:10, JonY wrote: >> On 7/16/2012 18:46, Ozkan Sezer wrote: >>> On Mon, Jul 16, 2012 at 1:38 PM, JonY wrote: On 7/16/2012 17:19, Jacek Caban wrote: > Sorry about that, I treat my git repository as a temporary place for > patch reviews, so they may disappear once I push new versions. Here is a > link to a patch already committed to the trunk (which should be > persistent since it's already in mingw-w64): > > http://repo.or.cz/w/mingw-w64/jacek.git/commitdiff/8c4da30fd44a7a47e7ba64a0c461d409146b6ae3 > > Jacek > > Looks like there are a lot of changes, but mostly cosmetic changes and moving things about, not exactly new stuff. Is the change part of a series of change? Are there any actual functionality change? If so, backporting might not be a good idea. If not, I'm OK with backporting, but Kai and Ozkan should comment on it first. >>> >>> IIRC, the patch didn't do any functionality changes. I'm OK with the >>> admins' >>> decisions on this one. >>> >> >> On closer inspection, it looks like all it does is fix a cross compile >> case with Wine, no real change to mingw-w64 itself, I'd say it's good to go. >> >> Kai? >> > > Hi Ozkan, > > Kai approved by IRC, so feel free to commit the backport. I believe I told Jacek that he can commit the backport. -- O.S. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] include: fix mingw64 build
On 07/16/12 14:26, Ozkan Sezer wrote: > On Mon, Jul 16, 2012 at 3:03 PM, JonY wrote: >> On 7/16/2012 19:10, JonY wrote: >>> On 7/16/2012 18:46, Ozkan Sezer wrote: On Mon, Jul 16, 2012 at 1:38 PM, JonY wrote: > On 7/16/2012 17:19, Jacek Caban wrote: >> Sorry about that, I treat my git repository as a temporary place for >> patch reviews, so they may disappear once I push new versions. Here is a >> link to a patch already committed to the trunk (which should be >> persistent since it's already in mingw-w64): >> >> http://repo.or.cz/w/mingw-w64/jacek.git/commitdiff/8c4da30fd44a7a47e7ba64a0c461d409146b6ae3 >> >> Jacek >> >> > Looks like there are a lot of changes, but mostly cosmetic changes and > moving things about, not exactly new stuff. > > Is the change part of a series of change? Are there any actual > functionality change? > > If so, backporting might not be a good idea. If not, I'm OK with > backporting, but Kai and Ozkan should comment on it first. > IIRC, the patch didn't do any functionality changes. I'm OK with the admins' decisions on this one. >>> On closer inspection, it looks like all it does is fix a cross compile >>> case with Wine, no real change to mingw-w64 itself, I'd say it's good to go. >>> >>> Kai? >>> >> Hi Ozkan, >> >> Kai approved by IRC, so feel free to commit the backport. > I believe I told Jacek that he can commit the backport. > Yeah, approval is all I need. I will backport it soon. Thanks, Jacek -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [patch] _mingw.h: Introduce the __32LONG macro
On Jul 13 09:54, Corinna Vinschen wrote: > On Jul 13 10:24, Ozkan Sezer wrote: > > On Fri, Jul 13, 2012 at 10:09 AM, Kai Tietz wrote: > > > The cause for that I was suggesting __32LONG is that name is more > > > unlikely to be mixed-up with a real type. > > > > > > > Yuck, nonetheless.. Maybe WINLONG32, making it similar to the WINBOOL > > thing? > > Just to be clear, I don't really care. However, it is a macro, it's not > a typedef. As such, it might be good idea to make it clearly distinct > from the usual uppercase Windows typedefs. As a macro it should start > with leading underscores anyway so as not to clutter the namespace. > If that's distinction enough, maybe something like > > __LONG32 > __WINLONG > __WINLONG32 > > Makes sense. Just pick your favorite. > > Apart from that, in contrast to Kai I would prefer to define the 32 bit > unsigned long equivalent as a macro as well. Instead of definitions like > > typedef unsigned __LONG32 ULONG; > > unsigned __LONG32 __RPC_API BSTR_UserSize(unsigned __LONG32 *,unsigned > __LONG32,BSTR *); > > I think that something like > > typedef __ULONG32 ULONG; > > __ULONG32 __RPC_API BSTR_UserSize(__ULONG32 *,__ULONG32,BSTR *); > > looks cleaner. > > But, either way, I go with what you decide. Ping? Corinna -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [patch] _mingw.h: Introduce the __32LONG macro
On Mon, Jul 16, 2012 at 4:43 PM, Corinna Vinschen wrote: > On Jul 13 09:54, Corinna Vinschen wrote: >> On Jul 13 10:24, Ozkan Sezer wrote: >> > On Fri, Jul 13, 2012 at 10:09 AM, Kai Tietz >> > wrote: >> > > The cause for that I was suggesting __32LONG is that name is more >> > > unlikely to be mixed-up with a real type. >> > > >> > >> > Yuck, nonetheless.. Maybe WINLONG32, making it similar to the WINBOOL >> > thing? >> >> Just to be clear, I don't really care. However, it is a macro, it's not >> a typedef. As such, it might be good idea to make it clearly distinct >> from the usual uppercase Windows typedefs. As a macro it should start >> with leading underscores anyway so as not to clutter the namespace. >> If that's distinction enough, maybe something like >> >> __LONG32 >> __WINLONG >> __WINLONG32 >> >> Makes sense. Just pick your favorite. >> >> Apart from that, in contrast to Kai I would prefer to define the 32 bit >> unsigned long equivalent as a macro as well. Instead of definitions like >> >> typedef unsigned __LONG32 ULONG; >> >> unsigned __LONG32 __RPC_API BSTR_UserSize(unsigned __LONG32 *,unsigned >> __LONG32,BSTR *); >> >> I think that something like >> >> typedef __ULONG32 ULONG; >> >> __ULONG32 __RPC_API BSTR_UserSize(__ULONG32 *,__ULONG32,BSTR *); >> >> looks cleaner. >> >> But, either way, I go with what you decide. > > Ping? > I hope no one is looking at me for this. Kai? > > Corinna > -- O.S. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] winpthreads patch for pthread_getspecific()/pthread_setspecific() function for restore WIN last error code
On Sat, Jul 14, 2012 at 12:23 PM, niXman wrote: > Patch in attachment. > > -- > Regards, > niXman This was discussed quite some time ago and the suggested changes look OK to me at first glance. As a reference, pthreads-win32 restores the last error for pthread_getspecific() (but not for pthread_setspecific() as far as I can see.) What do the admins think? -- O.S. winpthreads_lasterror.patch Description: Binary data -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [patch] _mingw.h: Introduce the __32LONG macro
Well, I would like to have here one define for long, which is then later on used consistently to replace use of 'long' type. I don't see much advantage in adding here a signed and a unsigned variant to _mingw.h header. We want to replace use of 'long' keyword. So by this, the keyword 'long' define isn't the same as the boolean type. So I am a bit opposed against the WIN prefix. IMHO it should be a define with two leading underscores, unlikely to be mixed with a destinguished type. So my vote goes all for __32LONG, but I am fine with __WINLONG too. As indeed we want to make sure that type 'long' is 32-bit to satisfy windows ABI.. Jacek is right that we will need additionally a macro, which handles the constant-postfix 'L'. Regards, Kai -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] winpthreads patch for pthread_getspecific()/pthread_setspecific() function for restore WIN last error code
2012/7/16 Ozkan Sezer:
> This was discussed quite some time ago and the suggested changes
> look OK to me at first glance. As a reference, pthreads-win32 restores
> the last error for pthread_getspecific() (but not for pthread_setspecific()
> as far as I can see.)
Without the restoration of the last error in pthread_setspecific(), this
code will always throw an exception:
boost::filesystem::exists("any non-existent file");
With the following message:
The operation completed successfully: "any non-existent file"
Why is this happening, you can read here:
http://forum.vingrad.ru/index.php?showtopic=353559&view=findpost&p=2499963
But, this is a Russian forum.
--
Regards,
niXman
___
Dual-target(32 & 64 bit) MinGW compilers for 32 and 64 bit Windows:
http://sourceforge.net/projects/mingwbuilds/
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] winpthreads patch for pthread_getspecific()/pthread_setspecific() function for restore WIN last error code
2012/7/16 niXman
> 2012/7/16 Ozkan Sezer:
>
> > This was discussed quite some time ago and the suggested changes
> > look OK to me at first glance. As a reference, pthreads-win32 restores
> > the last error for pthread_getspecific() (but not for
> pthread_setspecific()
> > as far as I can see.)
>
> Without the restoration of the last error in pthread_setspecific(), this
> code will always throw an exception:
> boost::filesystem::exists("any non-existent file");
>
> With the following message:
> The operation completed successfully: "any non-existent file"
>
I have had similar reports for my posix threades toolchains. If this patch
fixes that, it would be much appreciated :)
Ruben
>
> Why is this happening, you can read here:
> http://forum.vingrad.ru/index.php?showtopic=353559&view=findpost&p=2499963
>
> But, this is a Russian forum.
>
>
>
> --
> Regards,
> niXman
> ___
> Dual-target(32 & 64 bit) MinGW compilers for 32 and 64 bit Windows:
> http://sourceforge.net/projects/mingwbuilds/
>
>
> --
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] winpthreads patch for pthread_getspecific()/pthread_setspecific() function for restore WIN last error code
Well, I am fine by this patch, but I would love to get additional a testcase added for it. So patch is ok with a testcase. Thanks, Kai -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [patch] _mingw.h: Introduce the __32LONG macro
On Jul 16 15:56, Kai Tietz wrote: > Well, > > I would like to have here one define for long, which is then later on > used consistently to replace use of 'long' type. I don't see much > advantage in adding here a signed and a unsigned variant to _mingw.h > header. We want to replace use of 'long' keyword. > So by this, the keyword 'long' define isn't the same as the boolean > type. So I am a bit opposed against the WIN prefix. IMHO it > should be a define with two leading underscores, unlikely to be mixed > with a destinguished type. So my vote goes all for __32LONG, but I am __32LONG or __LONG32? Corinna -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] [patch] winbase.h: Use documented type in calls to Interlocked functions
Hi, as discussed on IRC, I propose the below patch. It changes the calls of the Interlocked functions from the C++ Interlocked inline functions defined at the end of winbase.h to use the system types just as these functions are defined. Ok to apply? Thanks, Corinna -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [patch] winbase.h: Use documented type in calls to Interlocked functions
[New and improved: This time with attachement!]
On Jul 16 18:58, Corinna Vinschen wrote:
> Hi,
>
> as discussed on IRC, I propose the below patch. It changes the
> calls of the Interlocked functions from the C++ Interlocked inline
> functions defined at the end of winbase.h to use the system types
> just as these functions are defined. Ok to apply?
>
>
> Thanks,
> Corinna
* winbase.h: Use system types in calls to Interlocked functions.
Index: winbase.h
===
--- winbase.h (revision 5223)
+++ winbase.h (working copy)
@@ -4062,90 +4062,90 @@
extern "C++" {
FORCEINLINE unsigned InterlockedIncrement(unsigned volatile *Addend) {
-return (unsigned)InterlockedIncrement((volatile long*)Addend);
+return (unsigned)InterlockedIncrement((volatile LONG*)Addend);
}
FORCEINLINE unsigned long InterlockedIncrement(unsigned long volatile
*Addend) {
-return (unsigned long)InterlockedIncrement((volatile long*)Addend);
+return (unsigned long)InterlockedIncrement((volatile LONG*)Addend);
}
FORCEINLINE unsigned __int64 InterlockedIncrement(unsigned __int64
volatile *Addend) {
-return (unsigned __int64)InterlockedIncrement64((volatile
__int64*)Addend);
+return (unsigned __int64)InterlockedIncrement64((volatile
LONGLONG*)Addend);
}
FORCEINLINE unsigned InterlockedDecrement(unsigned volatile *Addend) {
-return (unsigned long)InterlockedDecrement((volatile long*)Addend);
+return (unsigned long)InterlockedDecrement((volatile LONG*)Addend);
}
FORCEINLINE unsigned long InterlockedDecrement(unsigned long volatile
*Addend) {
-return (unsigned long)InterlockedDecrement((volatile long*)Addend);
+return (unsigned long)InterlockedDecrement((volatile LONG*)Addend);
}
FORCEINLINE unsigned __int64 InterlockedDecrement(unsigned __int64
volatile *Addend) {
-return (unsigned __int64)InterlockedDecrement64((volatile
__int64*)Addend);
+return (unsigned __int64)InterlockedDecrement64((volatile
LONGLONG*)Addend);
}
FORCEINLINE unsigned InterlockedExchange(unsigned volatile *Target,
unsigned Value) {
-return (unsigned)InterlockedExchange((volatile long*) Target,
(long)Value);
+return (unsigned)InterlockedExchange((volatile LONG*) Target,
(LONG)Value);
}
FORCEINLINE unsigned long InterlockedExchange(unsigned long volatile
*Target, unsigned long Value) {
-return (unsigned long)InterlockedExchange((volatile long*)Target,
(long)Value);
+return (unsigned long)InterlockedExchange((volatile LONG*)Target,
(LONG)Value);
}
FORCEINLINE unsigned __int64 InterlockedExchange(unsigned __int64 volatile
*Target, unsigned __int64 Value) {
-return (unsigned __int64)InterlockedExchange64((volatile
__int64*)Target, (__int64)Value);
+return (unsigned __int64)InterlockedExchange64((volatile
LONGLONG*)Target, (LONGLONG)Value);
}
FORCEINLINE unsigned InterlockedExchangeAdd(unsigned volatile *Addend,
unsigned Value) {
-return (unsigned)InterlockedExchangeAdd((volatile long*)Addend,
(long)Value);
+return (unsigned)InterlockedExchangeAdd((volatile LONG*)Addend,
(LONG)Value);
}
FORCEINLINE unsigned InterlockedExchangeSubtract(unsigned volatile
*Addend, unsigned Value) {
-return (unsigned)InterlockedExchangeAdd((volatile long*)Addend,
-(long)Value);
+return (unsigned)InterlockedExchangeAdd((volatile LONG*)Addend,
-(LONG)Value);
}
FORCEINLINE unsigned long InterlockedExchangeAdd(unsigned long volatile
*Addend, unsigned long Value) {
-return (unsigned long)InterlockedExchangeAdd((volatile long*)Addend,
(long)Value);
+return (unsigned long)InterlockedExchangeAdd((volatile LONG*)Addend,
(LONG)Value);
}
FORCEINLINE unsigned long InterlockedExchangeSubtract(unsigned long
volatile *Addend, unsigned long Value) {
-return (unsigned long)InterlockedExchangeAdd((volatile long*)Addend,
-(long)Value);
+return (unsigned long)InterlockedExchangeAdd((volatile LONG*)Addend,
-(LONG)Value);
}
FORCEINLINE unsigned __int64 InterlockedExchangeAdd(unsigned __int64
volatile *Addend, unsigned __int64 Value) {
-return (unsigned __int64)InterlockedExchangeAdd64((volatile
__int64*)Addend, (__int64)Value);
+return (unsigned __int64)InterlockedExchangeAdd64((volatile
LONGLONG*)Addend, (LONGLONG)Value);
}
FORCEINLINE unsigned __int64 InterlockedExchangeSubtract(unsigned __int64
volatile *Addend, unsigned __int64 Value) {
-return (unsigned __int64)InterlockedExchangeAdd64((volatile
__int64*)Addend, -(__int64)Value);
+return (unsigned __int64)InterlockedExchangeAdd64((volatile
LONGLONG*)Addend, -(LONGLONG)Value);
}
FORCEINLINE unsigned InterlockedCompareExchange(unsigned vola
Re: [Mingw-w64-public] [patch] winbase.h: Use documented type in calls to Interlocked functions
Hello Corinna, patch looks ok for me. I assume Jacek has no objections, so please go ahead. Thanks, Kai -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [patch] winbase.h: Use documented type in calls to Interlocked functions
On 7/16/12, Corinna Vinschen wrote:
> [New and improved: This time with attachement!]
>
> On Jul 16 18:58, Corinna Vinschen wrote:
>> Hi,
>>
>> as discussed on IRC, I propose the below patch. It changes the
>> calls of the Interlocked functions from the C++ Interlocked inline
>> functions defined at the end of winbase.h to use the system types
>> just as these functions are defined. Ok to apply?
>>
>>
>> Thanks,
>> Corinna
>
>
> * winbase.h: Use system types in calls to Interlocked functions.
>
>
> Index: winbase.h
> ===
> --- winbase.h (revision 5223)
> +++ winbase.h (working copy)
[...]
Why are types used inconsistently, e.g.:
> FORCEINLINE unsigned long InterlockedIncrement(unsigned long volatile
> *Addend) {
> -return (unsigned long)InterlockedIncrement((volatile long*)Addend);
> +return (unsigned long)InterlockedIncrement((volatile LONG*)Addend);
> }
>
> FORCEINLINE unsigned __int64 InterlockedIncrement(unsigned __int64
> volatile *Addend) {
> -return (unsigned __int64)InterlockedIncrement64((volatile
> __int64*)Addend);
> +return (unsigned __int64)InterlockedIncrement64((volatile
> LONGLONG*)Addend);
> }
--
O.S.
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [patch] winbase.h: Use documented type in calls to Interlocked functions
On Jul 16 20:44, Ozkan Sezer wrote:
> On 7/16/12, Corinna Vinschen wrote:
> > [New and improved: This time with attachement!]
> >
> > On Jul 16 18:58, Corinna Vinschen wrote:
> >> Hi,
> >>
> >> as discussed on IRC, I propose the below patch. It changes the
> >> calls of the Interlocked functions from the C++ Interlocked inline
> >> functions defined at the end of winbase.h to use the system types
> >> just as these functions are defined. Ok to apply?
> >>
> >>
> >> Thanks,
> >> Corinna
> >
> >
> > * winbase.h: Use system types in calls to Interlocked functions.
> >
> >
> > Index: winbase.h
> > ===
> > --- winbase.h (revision 5223)
> > +++ winbase.h (working copy)
> [...]
> Why are types used inconsistently, e.g.:
>
> > FORCEINLINE unsigned long InterlockedIncrement(unsigned long volatile
> > *Addend) {
> > -return (unsigned long)InterlockedIncrement((volatile long*)Addend);
> > +return (unsigned long)InterlockedIncrement((volatile LONG*)Addend);
>
> > }
> >
> > FORCEINLINE unsigned __int64 InterlockedIncrement(unsigned __int64
> > volatile *Addend) {
> > -return (unsigned __int64)InterlockedIncrement64((volatile
> > __int64*)Addend);
> > +return (unsigned __int64)InterlockedIncrement64((volatile
> > LONGLONG*)Addend);
>
> > }
It just looks inconsistent. The C++ functions are defined using base
types so the return type of the called Win32 functions still have to
be correctly casted to the type of the calling function.
I'm not sure these C++ functions really make sense, but apparently they
exist upstream as well.
Corinna
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] winpthreads patch for pthread_getspecific()/pthread_setspecific() function for restore WIN last error code
We also experience an issue with boost::filesystem::exists in blender. If this fixes that it will be a blessing :). -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
