Re: BUG #16157: handling of pg_malloc(0)
От | cilizili |
---|---|
Тема | Re: BUG #16157: handling of pg_malloc(0) |
Дата | |
Msg-id | TFa1jMTmjmJjo4Rpg3y3oB3q_3G8281BgQ9-rQUS307iiToepVHj75mry6CtEkdIVzNx1xX8FV0vW8ioIjQVnCCRmv6C7uj2hXDK_q40Duk=@protonmail.com обсуждение исходный текст |
Ответ на | Re: BUG #16157: handling of pg_malloc(0) (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-bugs |
> 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,
В списке pgsql-bugs по дате отправления: