From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Dave Page" <dpage(at)vale-housing(dot)co(dot)uk> |
Cc: | pgsql-odbc(at)postgresql(dot)org, "Didier Moens" <moensd(at)xs4all(dot)be> |
Subject: | Re: SQLGetInfo Bug |
Date: | 2003-01-02 15:03:12 |
Message-ID: | 20229.1041519792@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-odbc |
"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.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Dave Page | 2003-01-02 15:31:20 | Re: SQLGetInfo Bug |
Previous Message | Dave Page | 2003-01-02 14:47:41 | Re: SQLGetInfo Bug |