On Mon, Jun 08, 2015 at 10:50:25PM +0900, Michael Paquier wrote:
> And the caller needs to be sure that str actually allocates enough
> space.. That's not directly ECPG's business, still it feels
But there is no way for us to fix this as we want to implement the API as
defined in Informix.
> uncomfortable. I fixed it with the attached.
Thanks, committed.
> The world is full of surprises, and even if free(NULL) is a noop on
> modern platforms, I would rather take it defensively and check for a
> NULL pointer as Postgres supports many platforms. Other code paths
> tend to do already so, per se for example ECPGconnect.
Right, that's because they were developed before free received the safeguard, or the programmer simply didn't know at
thatpoint in time. Unless I'm mistaken we have other code that only calls free() without an additional safeguard, so
whyshuld ecpglib be special? If you don't like it using both approaches, feel free to remove the check in the other
case.:)
More seriously, though, does anyone know of any platform where free(NULL) is *not* a noop?
I don't like adding stuff just because of the world being full of surprises.
There may also be other functions not working as advertized. Wouldn't that
then mean we cannot use any function nor provided by ourselves?
> Perhaps I am overdoing it. I would have them for correctness (some
> other code paths do so) but if you think that the impact is minimal
> there then I am fine to not modify descriptor.c.
Sorry, I wasn't referring to descriptor.c but to the whole preproc/ subtree. But as I already said, since we went
throughthe effort we can of course apply it.
Will be in my next push.
Thanks.
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Meskes at (Debian|Postgresql) dot Org
Jabber: michael.meskes at gmail dot com
VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL
