http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48916
Summary: Falsely reported buffer overrun due to incorrect __builtin_object_size. Product: gcc Version: 4.5.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: j...@sanger.ac.uk Created attachment 24199 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24199 Demonstration of failure for -O -D_FORTIFY_SOURCE=2 I have a case where __builtin_object_size() appears to return an incorrect value (1), causing strcpy when used under -D_FORTIFY_SOURCE=2 to claim a buffer overrun has been detected. We allocate a block of memory sufficiently large to hold both a structure and a string immediately following it. The structure holds a pointer to this string and, for ease of programming, a terminal member whose address will be the start of the string. An example: typedef struct { char *name; // == &foo.data char data; // Note: vs char data[], char data[1] or char data[0] } foo_t; In this situation, __bos(foo->name) is neither -1 nor is it the correct size. Instead it appears to be the space remaining up to the end of the structure rather than up to the end of the malloced block of memory. More oddly is that only the first call to __builtin_object_size returns a value while all subsequent calls return -1 instead. This is the primary reason I suspect this to be a compiler bug rather than simply allowably undefined behaviour, as we would expect a consistent result. The error is easily worked around (from a coder's point of view) by changing the terminal "char data" member to the C99 recommended "char data[]", the prior GCC equivalent "char data[0]" or even "char data[1]" (which I'd assume to be identical in behaviour to "char data"). Note that I am unsure of whether this sneaky practice is strictly conforming to the C standard when not using data[] or data[0], as it means writing to &foo->data will be performing pointer arithmetic which starts within the struct and ends up outside of the struct, albeit still within the same malloc heap element. If it is non-standard, then this may simply fall into the realm of "undefined behaviour". The issue was initially discovered using Gentoo-11 with gcc 4.5.2, but has since been verified as failing on 4.4.4-10.fc13 (Red Hat's patched- for-Fedora version), 4.5.0, 4.5.2, 4.5.3, and 4.6.0. It works on 4.4.3 and earlier. It seems likely the implementation (specifically the non-constant result) of __builtin_object_size() is the issue. Sorry I do not know if this consistutes front-end or middle; please update the component as required. Attached is a program to demonstrate the issue. James