Work around a subtle portability problem in use of printf %s format.

Depending on which spec you read, field widths and precisions in %s may be
counted either in bytes or characters.  Our code was assuming bytes, which
is wrong at least for glibc's implementation, and in any case libc might
have a different idea of the prevailing encoding than we do.  Hence, for
portable results we must avoid using anything more complex than just "%s"
unless the string to be printed is known to be all-ASCII.

This patch fixes the cases I could find, including the psql formatting
failure reported by Hernan Gonzalez.  In HEAD only, I also added comments
to some places where it appears safe to continue using "%.*s".

1 files changed, 13 insertions, 3 deletions

diff --git a/src/backend/parser/scansup.c b/src/backend/parser/scansup.c
index cf588c1de8b..bc20b5a943e 100644
--- a/src/backend/parser/scansup.c
+++ b/src/backend/parser/scansup.c
@@ -9,7 +9,7 @@
  *
  *
  * IDENTIFICATION
- *	  $PostgreSQL: pgsql/src/backend/parser/scansup.c,v 1.29 2004/12/31 22:00:27 pgsql Exp $
+ *	  $PostgreSQL: pgsql/src/backend/parser/scansup.c,v 1.29.4.1 2010/05/08 16:40:45 tgl Exp $
  *
  *-------------------------------------------------------------------------
  */
@@ -177,10 +177,20 @@ truncate_identifier(char *ident, int len, bool warn)
 	{
 		len = pg_mbcliplen(ident, len, NAMEDATALEN - 1);
 		if (warn)
+		{
+			/*
+			 * Cannot use %.*s here because some machines interpret %s's
+			 * precision in characters, others in bytes.
+			 */
+			char	buf[NAMEDATALEN];
+
+			memcpy(buf, ident, len);
+			buf[len] = '\0';
 			ereport(NOTICE,
 					(errcode(ERRCODE_NAME_TOO_LONG),
-				errmsg("identifier \"%s\" will be truncated to \"%.*s\"",
-					   ident, len, ident)));
+					 errmsg("identifier \"%s\" will be truncated to \"%s\"",
+							ident, buf)));
+		}
 		ident[len] = '\0';
 	}
 }