4 ms·

I think some things like null terminated strings etc are not inevitable in a fast language like C. There were definitely design mistakes that cost security and

• Scaevolus 13y ago
  It affects performance more on old, register poor, slow CPUs. Memory latency dominates processing time now, but it used to be a real issue.
  • pjmlp 13y ago
    Sure, but we always had the option to switch off bound checking on the code spots where it really made a difference.
• _delirium 13y ago
  If anything, null-terminated strings are bad for performance as often as good for it. One example that comes up reasonably often: comparing strings that have different lengths but common prefixes is fast with length-tagged (Pascal-style) strings, but expensive with C-style strings, because you have to scan both strings until you find either a string end, or a difference. So instead of quickly answering "not equal" after one integer comparison, you could end up doing hundreds (or thousands) of byte comparisons in degenerate cases. Anything that calls strlen() also ends up doing extra work.
  • adobriyan 13y ago
    Well, as far as kernel is concerned strings aren't a problem. Outside VFS they don't exist. Inside VFS everything is chopped into usually short pathname components which are hashed for dcache consumption. On x86_64 hashing is not byte-by-byte anymore. Fixing pathetic macro system and type system (if that qualifies at all) would get rid of many many bugs.