Re: BUG #16157: handling of pg_malloc(0)

From: cilizili <cilizili(at)protonmail(dot)com>
To: "pgsql-bugs(at)lists(dot)postgresql(dot)org" <pgsql-bugs(at)lists(dot)postgresql(dot)org>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: BUG #16157: handling of pg_malloc(0)
Date: 2019-12-10 09:51:29
Message-ID: TFa1jMTmjmJjo4Rpg3y3oB3q_3G8281BgQ9-rQUS307iiToepVHj75mry6CtEkdIVzNx1xX8FV0vW8ioIjQVnCCRmv6C7uj2hXDK_q40Duk=@protonmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

> PG Bug reporting form noreply(at)postgresql(dot)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,

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Alejandro Meseguer 2019-12-10 11:03:24 Bug in pg_dump
Previous Message Etsuro Fujita 2019-12-10 09:33:08 Re: BUG #16139: Assertion fails on INSERT into a postgres_fdw' table with two AFTER INSERT triggers