Re: pg_dump vs malloc

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_dump vs malloc
Date: 2011-10-15 15:23:37
Message-ID: CABUevEyzj-w=U5CESFVzwzHhGNyXgSFY-tHh7kJZSEYO-UyQ4g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Oct 14, 2011 at 21:11, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> Magnus Hagander wrote:
>> On Wed, Jun 22, 2011 at 17:48, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> > Magnus Hagander <magnus(at)hagander(dot)net> writes:
>> >> Something along the line of this?
>> >
>> > I think this is a seriously, seriously bad idea:
>> >
>> >> +#define strdup(x) pg_strdup(x)
>> >> +#define malloc(x) pg_malloc(x)
>> >> +#define calloc(x,y) pg_calloc(x, y)
>> >> +#define realloc(x,y) pg_realloc(x, y)
>> >
>> > as it will render the code unreadable to people expecting the normal
>> > behavior of these fundamental functions; not to mention break any
>> > call sites that have some other means of dealing with an alloc failure
>> > besides going belly-up. ?Please take the trouble to do
>> > s/malloc/pg_malloc/g and so on, instead.
>>
>> Ok, I'll try that approach. This seemed like a "nicer" approach, but I
>> think once written out, i agree with your arguments :-)
>
> Where are we on this?

It's still sitting on my personal TODO list, just not with a really
high priority.

--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2011-10-15 15:32:16 .psqlrc version dependence (was Re: about EDITOR_LINENUMBER_SWITCH)
Previous Message Tom Lane 2011-10-15 15:13:56 Re: Call stacks and RAISE INFO