Hallo Corinna,
2012/7/26 Corinna Vinschen <[email protected]>:
> Hi,
>
> more avoidance of __MSABI_LONG below.
>
> Here's a question. I already had a look into the end result after
> applying the bulk __MSABI_LONG patch. Apart from the fact that it
> affects a 5 digit number of lines, it looks... ugly. The string
> __MSABI_LONG looks kind of intrusive:
>
> #define IO_REPARSE_TAG_MOUNT_POINT (0xA0000003L)
>
> becomes
>
> #define IO_REPARSE_TAG_MOUNT_POINT (__MSABI_LONG(0xA0000003))
>
> I was wondering if we shouldn't make it less intrusive, something like
>
> #define IO_REPARSE_TAG_MOUNT_POINT (__LONG(0xA0000003))
> #define IO_REPARSE_TAG_MOUNT_POINT (__L(0xA0000003))
>
> OTOH, it's still a fact that any numerical constant without 'L' qualifier
> is int, which has the same size as LONG, ULONG, DWORD, etc., regardless
> of using LLP64, LP64, ILP64, whatever. Therefore it should have no
> impact at all, if we just drop the 'L' qualifier from the headers.
>
> Even better: If the target type is long, and sizeof(long) != sizeof(int),
> it has still no impact. I tried something like this on x86_64 Linux
> (LP64):
>
> const unsigned long foo = -1;
>
> Compile this with all possible warning flags:
>
> $ g++ -pedantic -ansi -c -g -O2 -Wall -Wextra foo.c
>
> and you will see no warning at all. The reason is that in C and C++
> the conversion from int to long is well defined!
>
> So, I would prefer just to drop the 'L'. Baring that, I would
> prefer __L or __LONG over __MSABI_LONG for pure readability.
>
> If the below patch is ok, it's the last patch prior to the bulk
> __MSABI_LONG patch, so it would be nice if we could discuss the final
> solution for the above change.
>
>
> Thanks,
> Corinna
So the point about C++ and constant-type is clear (we discussed that
on IRC). For the other people on mailing-list a short example
illustrating the issue for C++.
void foo (int i) { abort (); }
void foo (long i) { cout << i << endl; }
...
foo (LONGCONST);
...
Changes in cdosys.h are ok.
In pdh.h I have the following nits:
> +#define IsSuccessSeverity(ErrorCode) ((((DWORD)(ErrorCode) &
> (0xC0000000))==(DWORD)0x00000000) ? TRUE : FALSE)
Here please replace the 'X == (DWORD) 0x0' by '!(X)'. Additional
remove the frame around the constant. It looks ugly IMHO.
> +#define IsInformationalSeverity(ErrorCode) ((((DWORD)(ErrorCode) &
> (0xC0000000))==(DWORD)0x40000000) ? TRUE : FALSE)
> +#define IsWarningSeverity(ErrorCode) ((((DWORD)(ErrorCode) &
> (0xC0000000))==(DWORD)0x80000000) ? TRUE : FALSE)
> +#define IsErrorSeverity(ErrorCode) ((((DWORD)(ErrorCode) &
> (0xC0000000))==(DWORD)0xC0000000) ? TRUE : FALSE)
As above the frame around inner constant 0xc0000000 should go away IMHO.
Changes in richole.h are ok.
Changes in windowsx.h (always again a nightmare):
> -#define HANDLE_WM_CREATE(hwnd,wParam,lParam,fn)
> ((fn)((hwnd),(LPCREATESTRUCT)(lParam)) ? (LRESULT)0 : (LRESULT)-1L)
> +#define HANDLE_WM_CREATE(hwnd,wParam,lParam,fn)
> ((fn)((hwnd),(LPCREATESTRUCT)(lParam)) ? (LRESULT)0 : (LRESULT)-1)
are ok, but wouldn't be #define
HANDLE_WM_CREATE(hwnd,wParam,lParam,fn) (LRESULT)
((fn)((hwnd),(LPCREATESTRUCT)(lParam)) ? 0 : -1)' better?
Changes in winerror.h, lmaccess.h, subsmgr.h, netmon.h, penwin.h,
lmstats.h, naperror.h, urlmon.h, cdoex.h, and advpub.h are ok.
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
