From 2e6427502a953fd0cf3ffa66dee68f70734d5c02 Mon Sep 17 00:00:00 2001
From: Karl Williamson <public@khwilliamson.com>
Date: Mon, 9 Dec 2013 16:06:01 -0700
Subject: [PATCH] pod/perlhacktips: Further info on glibc bug

Commit 6bfe0388956736a32b874cc5e31cc6437260b227 prompted me to do some
more digging.  The bug in glibc has apparently been fixed in 2.17.
---
 pod/perlhacktips.pod | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/pod/perlhacktips.pod b/pod/perlhacktips.pod
index 0112751..e3ef6f9 100644
--- a/pod/perlhacktips.pod
+++ b/pod/perlhacktips.pod
@@ -609,11 +609,12 @@ fancier than a plain byte string, use
 L<C<Perl_form>()|perlapi/form> or SVs and
 L<C<Perl_sv_catpvf()>|perlapi/sv_catpvf>.
 
-Note that some versions of all the C<sprintf()> forms are buggy in
-glibc as of version 2.17.  They won't allow a C<%s> format to create a
-string that isn't valid UTF-8 if the current underlying locale of the
-program is UTF-8.  What happens is that the C<%s> and its operand are
+Note that glibc C<printf()>, C<sprintf()>, etc. are buggy before glibc
+version 2.17.  They won't allow a C<%.s> format with a precision to
+create a string that isn't valid UTF-8 if the current underlying locale
+of the program is UTF-8.  What happens is that the C<%s> and its operand are
 simply skipped without any notice.
+L<https://sourceware.org/bugzilla/show_bug.cgi?id=6530>.
 
 =back
 
-- 
2.7.4