This is the mail archive of the glibc-bugs@sourceware.org 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]

[Bug libc/11120] strncmp() will be broken if used in ld.so on x86-64


http://sourceware.org/bugzilla/show_bug.cgi?id=11120

--- Comment #13 from Don Hatch <dhatch at ilm dot com> 2013-03-26 05:43:37 UTC ---
(In reply to comment #12)
> (In reply to comment #11)
> > 
> > My question is about the fact that,
> > contrary to what both you and Mark Seaborn have said,
> > prior to your change,
> > strncmp was *not* acting like strcmp, at least not consistently.
> > On one call it acted like strcmp, on the next call
> > (with exactly the same effective input) it didn't.
> 
> If you have a look at the implementation, you'll see that it's all the same in
> the non-libc case no matter by what name it is called.
> The reason why you can see different results is that gcc is capable to optimize
> out some strncmp calls.  For example, in your case
> 
> $ echo -e '#include <string.h>\nint foo(void){return strncmp("abc", "ab", 2);}'
> |gcc -O2 -E - |tail -1

(in tcsh, this needs to say /bin/echo so it will understand the -e flag)

Ah!  Thank you, that makes perfect sense to me now.
It must be that __builtin_constant_p (abc) is returning false
but __builtin_constant_p("abc") is returning true,
resulting in two different execution paths taken, one of which actually
calls the function and the other doesn't.

Thanks very much for taking the time to examine and explain this.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.


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