On 2014-05-16 16:19:28 -0400, Tom Lane wrote: > Andres Freund <and...@2ndquadrant.com> writes: > > On 2014-05-16 15:44:53 -0400, Tom Lane wrote: > >> But according to previous research, we don't > >> really guarantee that glibc thinks the encoding is what we think, anyway. > >> The commit messages for 54cd4f04576833abc394e131288bf3dd7dcf4806 and > >> ed437e2b27c48219a78f3504b0d05c17c2082d02 are relevant here. The second > >> one suggests that only "%.*s" is at risk not "%*s", but I'm not really > >> convinced right now. My recollection is that glibc will abandon > >> processing either format spec if it thinks the string is wrongly encoded. > > > I've tested it here. From what it looks like it prints just fine but > > misjudges the width for padding. > > Oh, good. We can live with that.
Yea, seems pretty harmless. It's a pretty new glibc version though, so things might have been different in the past. On the other hand I can see more justification to stop processing on input than output... > (In any case, we could retain the feature and just do the padding > computations ourselves. But I now think we don't have to.) Might actually make the code somewhat less ugly... But I am not volunteering. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
