Re: get_progname() should not be const char *?

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Phil Sorber <phil(at)omniti(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: get_progname() should not be const char *?
Date: 2013-02-06 14:43:06
Message-ID: CA+Tgmob=heimU9JOuN81Spib5TygayWjAP32-hZiLA0rS6m3jQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Feb 5, 2013 at 12:18 AM, Phil Sorber <phil(at)omniti(dot)com> wrote:
> On Mon, Feb 4, 2013 at 10:52 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Phil Sorber <phil(at)omniti(dot)com> writes:
>>> get_progname() returns a strdup()'d value. Shouldn't it then be simply
>>> char * and not const char *? Otherwise free() complains loudly without
>>> a cast.
>>
>> I don't believe that callers should be trying to free() the result.
>> Whether it's been strdup'd or not is not any of their business.
>
> Is that just because of the nature of this specific function?

I can't presume to speak for Tom, but I think so. Sometimes the API
of a function includes the notion that the caller should pfree the
result. Sometimes it doesn't. The advantage of NOT including that in
the API contract is that you can sometimes do optimizations that would
be impossible otherwise - e.g. you can return the same palloc'd string
on successive calls to the function; or you can sometimes return a
statically allocated string.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dimitri Fontaine 2013-02-06 14:44:52 Re: sql_drop Event Trigger
Previous Message Alvaro Herrera 2013-02-06 14:40:38 Re: sql_drop Event Trigger