On Sat, Feb 11, 2017 at 2:41 PM, Gerald Pfeifer gerald@pfeifer.com wrote:
... With that dlls/kernel32/tests/heap.c triggers three warnings, all of which are correct positives, but in fact do want to test those corner cases:
I'm not convinced that this statement is true. For example, while "~(SIZE_T)0 - 7" gives us 4294967288 (matching what is indicated by the warning), HeapReAlloc accepts a SIZE_T. So, this should support a maximum value of 4294967295 (not 2147483647). This says to me that gcc thinks SIZE_T is a signed value instead of an unsigned value, do you have any idea why this might be the case?
Best, Erich
On 21 February 2017 at 15:03, Erich E. Hoover erich.e.hoover@wine-staging.com wrote:
I'm not convinced that this statement is true. For example, while "~(SIZE_T)0 - 7" gives us 4294967288 (matching what is indicated by the warning), HeapReAlloc accepts a SIZE_T. So, this should support a maximum value of 4294967295 (not 2147483647). This says to me that gcc thinks SIZE_T is a signed value instead of an unsigned value, do you have any idea why this might be the case?
It doesn't check against the type's size, but against the size specified by -Walloc-size-larger-than=. If that's not explicitly set, that's PTRDIFF_MAX.
On Tue, 21 Feb 2017, Erich E. Hoover wrote:
On Sat, Feb 11, 2017 at 2:41 PM, Gerald Pfeifer gerald@pfeifer.com wrote:
With that dlls/kernel32/tests/heap.c triggers three warnings, all of which are correct positives, but in fact do want to test those corner cases:
I'm not convinced that this statement is true. For example, while "~(SIZE_T)0 - 7" gives us 4294967288 (matching what is indicated by the warning), HeapReAlloc accepts a SIZE_T. So, this should support a maximum value of 4294967295 (not 2147483647). This says to me that gcc thinks SIZE_T is a signed value instead of an unsigned value, do you have any idea why this might be the case?
Hmm, so here is an excerpt from the documentation of the forthcoming GCC 7 release about this warning:
Warn about calls to functions decorated with attribute @code{alloc_size} that attempt to allocate objects larger than the specified number of bytes, or where the result of the size computation in an integer type with infinite precision would exceed @code{SIZE_MAX / 2}.
(I believe this boils down to "half the address space", which indeed would be at least unusual for a memory allocation. ;-)
Gerald
On Tue, Feb 21, 2017 at 9:16 AM, Gerald Pfeifer gerald@pfeifer.com wrote:
...
Hmm, so here is an excerpt from the documentation of the forthcoming GCC 7 release about this warning:
Warn about calls to functions decorated with attribute @code{alloc_size} that attempt to allocate objects larger than the specified number of bytes, or where the result of the size computation in an integer type with infinite precision would exceed @code{SIZE_MAX / 2}.
(I believe this boils down to "half the address space", which indeed would be at least unusual for a memory allocation. ;-)
Ok, clearly I misunderstood the purpose of this specific warning.
Henri, do you know if we allow gcc-specific pragmas like this? I don't see anything like this in the current code, so it may be that we need to make this something we detect at ./configure time.
Best, Erich
-
Erich E. Hoover -
Gerald Pfeifer -
Henri Verbeet