This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Potential issue with strstr on x86 with sse4.2 in glibc-2.18

On Tue, Aug 20, 2013 at 01:40:56PM +0000, Joseph S. Myers wrote:
> On Tue, 20 Aug 2013, Rich Felker wrote:
> > Also, I question whether the set of files that use callbacks is
> > complete. Due to fopencookie and register_printf_function, all of
> > stdio could potentially call application code. I suspect there are a
> > lot more places like this where, due to glibc extensions, functions
> > which seemingly do not use callbacks actually might... (malloc?)
> As I noted in <>, 
> printf should logically be using $(uses-callbacks) but is actually using 
> $(exceptions).
> I've expanded the corresponding item on the wiki todo list to request 
> better consistency checks.  But I suspect there will be lots of false 
> positives - libc functions can call snprintf internally using only 
> standard formats, for example, and it would be undefined behavior if a 
> user had overridden those standard formats at that time, so the fact that 
> a library function calls snprintf does not mean that function can use 
> callbacks even though snprintf can - unless it calls snprintf with a fully 
> user-controlled format, in which case of course it does need to allow for 
> user callbacks.  Likewise, use of qsort with a callback function defined 
> within the library is always fine.

I agree that's a non-issue. The real issue is that the current CFLAGS
permit GCC to assume that, on entry to snprintf, the stack is aligned
mod 16. This is actually false when snprintf is called from other
parts of glibc.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]