Glibc change exposing bugs

Glibc change exposing bugs

Posted Nov 17, 2010 19:08 UTC (Wed) by oak (guest, #2786)
In reply to: Glibc change exposing bugs by meuh
Parent article: Glibc change exposing bugs

> And one should know that GCC provides inline versions of such functions

Wasn't this article about Glibc memcpy(), not the GCC (libgcc?) one?

Anyway, AFAIK GCC does that only if code is compiled with optimizations. Valgrind and -O0 compiled code are speed-wise pretty horrible combination though. Then it might be better to use one of the other memory debugging tools that don't do CPU emulation like Valgrind does...

Note that GCC doesn't inline its memcpy() code just for explicit (fixed size) memcpy() calls. Inlined version may also be used for assignments and developers are able to mess up addresses of variables used in thing like this too:

  struct foobar_t *a = arg1, *b = arg2;
  ...
  *a = *b;

(I found this issue on implicit GCC memcpy() when my code didn't have correct alignment for one of above kind of pointers on platform that required things to be properly aligned. It triggering a kernel alignment exception handler bug had me scratching my head until more knowledgeable colleague came to rescue... I think with overlapping pointer addresses results may be even more mysterious as they show up later.)

---

(Log in to post comments)