On 01/11/2018 12:22 PM, Jeff Law wrote:
On 01/11/2018 11:56 AM, Martin Sebor wrote:
On 01/10/2018 04:20 PM, Jeff Law wrote:
On 01/09/2018 05:57 AM, Prathamesh Kulkarni wrote:
As Jakub pointed out for the case:
void *f()
{
return __builtin_malloc (0);
}
The malloc propagation would set f() to malloc.
However AFAIU, malloc(0) returns NULL (?) and the function shouldn't
be marked as malloc ?
This seems like a pretty significant concern. Given:
return n ? 0 : __builtin_malloc (n);
Is the function malloc-like enough to allow it to be marked?
A call to malloc(0) is specified to return either NULL or
a pointer to a distinct object of zero size. As useless as
it is, the function above satisfies the requirement. That
said, suggesting to mark it as such wouldn't be terribly
helpful (a different warning pointing out that it's useless
and so probably buggy might be).
I'm mostly concerned with making sure it is not harmful to mark. If it
were harmful to mark then the bar for marking gets much higher, possibly
to the point where the analysis really isn't worth it.
I doubt either case is worth the effort to try and detect for a warning
though.
As long as the marked definition still satisfies the assumptions
GCC makes about the function it won't be harmful. I don't know
all the nuances of pointer aliasing in GCC that might rely on it
but assuming they faithfully reflect the standard requirements
it will be safe.
The other aspect of the question is under what the conditions
is suggesting the attribute meaningful. Without spending too
much time on it, I think the condition should be that the
function must return a pointer obtained from a call to
an allocation function that depends on one or more of its
arguments, either directly or indirectly, or NULL. Does that
make sense or can you or someone think of some realistic use
cases where this would be too broad?
Martin
