Maybe it did, but I'm not sure it's the right step. The front end
shouldn't assume any knowledge of NAMEDATALEN, I believe. What will you
do if someone compiles a server with a larger NAMEDATALEN believeing,
correctly, that the client won't know and shouldn't care? DBD::Pg will
mysteriously truncate the names, it looks like. What is more, in all
these cases it looks like we are actually calling strlen nearby anyway.
Wouldn't it be better to move the strlen() calls out of line and then
reuse the result instead of a possibly bogus NAMEDATALEN?
cheers
andrew
David E. Wheeler wrote:
That fixed it, thanks.
All tests pass.
Best,
David
On Jan 22, 2008, at 09:14, [EMAIL PROTECTED] wrote:
Author: turnstep
Date: Tue Jan 22 09:14:21 2008
New Revision: 10637
Modified:
DBD-Pg/trunk/dbdimp.c
Log:
Explicitly define NAMEDATALEN if not already. Setting to 64 should be
safe, as it is rare for people to manually change this, and we only
use it for some snprintf() safety checks.
Modified: DBD-Pg/trunk/dbdimp.c
==============================================================================
--- DBD-Pg/trunk/dbdimp.c (original)
+++ DBD-Pg/trunk/dbdimp.c Tue Jan 22 09:14:21 2008
@@ -18,6 +18,10 @@
#include <wchar.h>
#include <strings.h>
+#ifndef NAMEDATALEN
+#define NAMEDATALEN 64
+#endif
+
/* Force preprocessors to use this variable. Default to something
valid yet noticeable */
#ifndef PGLIBVERSION
#define PGLIBVERSION 80009
