> PG Bug reporting form noreply@postgresql.org writes:
>
> > While checking code, I found a potential bug. To avoid unportable behavior
> > of malloc(0), pg_malloc family functions in fe_memutils.c replace the size 0
> > with 1. I think 1 is poor, any size of chunk enought for structure or
> > pointer may be required.
>
> I don't see your point. The reason we're doing anything special here
> is that the C/POSIX standard for malloc() says
>
> If the size of the space requested is 0, the behavior is
> implementation-defined: either a null pointer shall be returned, or
> the behavior shall be as if the size were some non-zero value, except
> that the behavior is undefined if the returned pointer is used to
> access an object.
>
> We don't want the first behavior, so we're forcing it to be the second
> one. But the behavior is still undefined if you try to actually store
> anything in the returned space, so there's no point in making it any
> bigger than we have to. Indeed, doing so would make it easier for
> buggy code that tries to store something there to escape detection.
Thank you for your explanation. I've read again the comments near the codes written malloc() or realloc(), I understand
well.My reported issue is not a bug.
regards,