[The following is a cut and paste from my followup to Ville's post.
BTW, I see this as a cleanliness/inconvenience issue, but if some
one thinks it should be bumped to "security", be my guest.]

I'm not really worried about this kind of "vulnerability", but it 
seems to me that in most cases it's unfriendly to error just because 
the user passes "%s" into (lambda (s) (message s)).  May as well do 
something about (most of) the C cases too, although 
 
     fprintf (stderr, "%s", ENDOFLINE) 
 
where 
 
#define ENDOFLINE "\r\n" 
 
seems more obfuscatory than useful. 
 
So, thanks for the "heads up", we (FSVO "we") should do something 
about it (including documenting it somewhere, probably in the coding 
style guide).

Message-Id: <200908131809.29472.scop@xemacs.org> 
From: Ville Skyttä <scop@xemacs.org> 
To: xemacs-beta@xemacs.org 
Subject: Possible format string related improvements 
Date: Thu, 13 Aug 2009 18:09:29 +0300 
 
Hello, 
 
A few years ago I grepped through the XEmacs source tree looking for possible  
problems with format strings after discovering some in rpm-spec-mode.el.  At  
that time people were quite actively looking for format string vulnerabilities  
in various projects' C code as well. 
 
The attached diff against current hg is the result what I changed back then in  
the XEmacs source tree.  This is 100% untested (not even built), and not even  
really thought about work, something may be flat out wrong, something plain  
unnecessary, but there may be some useful bits in the diff.  I have no plans  
to do anything further about this diff, so if anyone sees something useful in  
it, by all means please feel free to grab and apply it. 

[See attached patch.]