User: Password:
|
|
Subscribe / Log in / New account

The ups and downs of strlcpy()

The ups and downs of strlcpy()

Posted Jul 24, 2012 18:16 UTC (Tue) by renox (subscriber, #23785)
In reply to: The ups and downs of strlcpy() by nix
Parent article: The ups and downs of strlcpy()

> x86-64 GCC disables them by default (as does x86-32 modern GCC)

I wonder why the GCC developpers chose this default behaviour, x86-64 isn't register starved like x86-32.


(Log in to post comments)

The ups and downs of strlcpy()

Posted Jul 24, 2012 23:19 UTC (Tue) by nix (subscriber, #2304) [Link]

Because the ABI allows it, because it still provides a performance improvement (somewhere between 1% and 5%, not insignificant, though well below the 8--12% I've seen reported for x86-32), and because it's useless -- everything from GDB through libgcj and now I find even glibc backtrace() uses the DWARF unwinder tables instead. Why maintain a 'feature' which costs a register and adds runtime overhead to every function call when nobody needs it?

The ups and downs of strlcpy()

Posted Jul 25, 2012 15:11 UTC (Wed) by paulj (subscriber, #341) [Link]

One reason is debugging stack corruption, where normal tools may not give meaningful backtraces. With frame-pointers, you can easily figure out where earlier, uncorrupted, frames really are, and figuring out why it crashed.

The ups and downs of strlcpy()

Posted Jul 25, 2012 17:17 UTC (Wed) by nix (subscriber, #2304) [Link]

Yep. That's why frame pointers should be *enableable*. It doesn't mean they should be on by default.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds