Re: SQLGetInfo Bug

From: "Dave Page" <dpage(at)vale-housing(dot)co(dot)uk>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: <pgsql-odbc(at)postgresql(dot)org>, "Didier Moens" <moensd(at)xs4all(dot)be>
Subject: Re: SQLGetInfo Bug
Date: 2003-01-02 15:31:20
Message-ID: 03AF4E498C591348A42FC93DEA9661B8128E07@mail.vale-housing.co.uk
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-odbc

> -----Original Message-----
> From: Tom Lane [mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us]
> Sent: 02 January 2003 15:03
> To: Dave Page
> Cc: pgsql-odbc(at)postgresql(dot)org; Didier Moens
> Subject: Re: [ODBC] SQLGetInfo Bug
>
>
> "Dave Page" <dpage(at)vale-housing(dot)co(dot)uk> writes:
> > The garbage is not there if I use sprintf with a larger
> size of tmp.
> > I've tried variations of the code to check (without luck)
> but I assume
> > I'm not somehow knocking the null off the end of the string?
>
> You would be losing the trailing null if the snprintf is
> unable to fit its output into the buffer size it's told to
> use (at least, that's how most implementations of snprintf
> react, I think).
>
> It doesn't look like this should be enough data to overrun
> your buffer, but I don't have a better theory at the moment.
>
> Perhaps
>
> snprintf(tmp, sizeof(tmp) - 1, "%s %s", ...);
> tmp[sizeof(tmp) - 1] = '\0';
>
> would be better coding practice if you don't want to actually
> check snprintf's result.

Thanks Tom, that got it.

Regards, Dave.

Browse pgsql-odbc by date

  From Date Subject
Next Message Bruce Momjian 2003-01-02 22:29:25 Re: bug in info.c file - incorrect SQL
Previous Message Tom Lane 2003-01-02 15:03:12 Re: SQLGetInfo Bug