Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why is strlen so complex in C?

stackoverflow.com

Post reply on HN
Print view View original

61–70 of 74 posts

Re: Why is strlen so complex in C?

#61

Post by pornel »

klingonopera wrote: post #52
pornel wrote: post #26

Earlier quoted context omitted.

It would be so nice if C had "fat pointers" (ptr+len). It's such an obvious small change that would have a massive impact on usability and safety. Unfortunately, C is dead. Microsoft thinks C is dead, and intentionally keeps their compiler awful. Even ISO WG doesn't seem to have a vision for C's future and have been rearranging deck chairs for the last 20 years.

Well, it has. You just said so, it's (ptr+len) . ...it's the philosophy of the C language: There's minimal bloat on the upside, but you have to know what you're doing and how to be able get it on the downside.

That's like saying C doesn't need pointers in the type system, because it already has pointer-sized integers (BCPL actually had that philosophy).

Slices greatly improve interfaces. Especially if you want to return a (sub)slice of something, C doesn't have any non-clunky solution.

Re: Why is strlen so complex in C?

#62

Post by compiler-guy »

saagarjha wrote: post #59
rurban wrote: post #56

Earlier quoted context omitted.

We had that effort in C++. As we saw it backfired. C++ stdlib strings are so overengineered that they are much slower and bigger in the general case.

What? C++ strings have an overhead of 16 bytes+the space left in the backing buffer. That’s really not all that much.

16 bytes is in no way guaranteed by the standard.

Re: Why is strlen so complex in C?

#63

Post by saagarjha »

compiler-guy wrote: post #62
saagarjha wrote: post #59

Earlier quoted context omitted.

What? C++ strings have an overhead of 16 bytes+the space left in the backing buffer. That’s really not all that much.

16 bytes is in no way guaranteed by the standard.

Of course–the implementation is free to do whatever it likes. But all reasonable ones will either use a three pointer (or some combination of a base pointer and pointers/integers representation bounds) or include a small buffer for SSO that overlaps with the storage for heap bounds.

Re: Why is strlen so complex in C?

#64

Post by bjourne »

BeeOnRope wrote: post #60
bjourne wrote: post #58

Earlier quoted context omitted.

Did you benchmark it? I did and found that on a Core-M with MSVC, the optimized strlen beats the naive one by about 20% and on Xeon with gcc, by about 40%. Depending on string length and other parameters. I would expect the difference to be smaller on more recent processors. But without benchmarking I don't think you can say.

Yes, I have benchmarked it in the past which is where I got the 4-6x figure from. Maybe it's worth a revisit, but unless the compiler is doing something special with the byte version, I would be surprised if the speedup was much less. You may have to unroll both to get max speed. If you could share your benchmark I would be interested to look at it.

Benchmarks are always worth revisits. Mine is here https://github.com/bjourne/c-examples/blob/master/programs/s...

Re: Why is strlen so complex in C?

#65

Post by anmorgan »

ncmncm wrote: post #50
anmorgan wrote: post #45

Earlier quoted context omitted.

On Arduino, from my experience, it is easy to run into memory constraints, especially when using dynamically allocated memory like strings. And I'm taking about both the flash memory for code and the ram for data, stack, and heap. I don't think C is always a win, but to say to never use for new projects seems overly biased. Why is your opinion about C so strong? I am curious.

Simply this: if you write C code, it produces the same instructions compiling with a C or C++ compiler. But a C compiler restricts you to the C subset. Many of the most useful features of C++ generate no extra instructions, but make the code more maintainable. There are libraries that compile to no code except exactly what you call, optimized down to exactly the circumstances of the call, wholly inexpressible in C, t…

Okay, I think this reply helps frame your stance much better. You are not necessarily proposing no C ever, but saying at least start a new project with a C++ compiler / IDE and if there are reasons to use C code or rules like "don't use dynamic memory allocation", when there is a substantial reason, then that is acceptable

Re: Why is strlen so complex in C?

#66

Post by flukus »

wahern wrote: post #39
zamalek wrote: post #27

Earlier quoted context omitted.

I was wondering how it would compare to the code produced by auto-vectorization, I guess it doesn't matter with hand-crafted assembly.

The compiler can't autovectorize because it can't assume it's okay to read past the end of the string. Only the human or the machine can make that determination, using special knowledge about the environment, such as that when locating the NUL byte out-of-bounds reads are okay so long as they don't cross a page boundary. And "okay" is a stretch because tools like Valgrind ship with huge lists of manually maintained s…

But in this case a human applied their special knowledge in glibc, what's stopping the human applying the same knowledge to the compiler itself for this specific OS/arch?

Re: Why is strlen so complex in C?

#67

Post by m463 »

rurban wrote: post #55
m463 wrote: post #36

Optimization hacks aside, I swoon at the simple (and verified) seL4 implementation (note strNlen): word_t strnlen(const char *s, word_t maxlen) { word_t len; for (len = 0; len http://sel4.systems/ https://github.com/seL4/seL4 (from file src/string.c)

Nope, for sure not. A good implementation would stick to the standard (size_t nor word_t), and would inc the pointer, not the counter. Formatting would be better (the final ; ouch). This is junior stuff.

Maybe verification tools choke on pointer incrementing?

Having worked on a variety of code bases and coding styles, I think if there are coding rules and they are consistent across all the source files, it becomes easy to read even with wierdnesses. I hated perl with @_ and $_, but after working with it enough they became known quantities.

And you can probably read all the lines of code in your lifetime, since the whole microkernel is ~30k lines of code.

Re: Why is strlen so complex in C?

#68

Post by wahern »

flukus wrote: post #66
wahern wrote: post #39

Earlier quoted context omitted.

The compiler can't autovectorize because it can't assume it's okay to read past the end of the string. Only the human or the machine can make that determination, using special knowledge about the environment, such as that when locating the NUL byte out-of-bounds reads are okay so long as they don't cross a page boundary. And "okay" is a stretch because tools like Valgrind ship with huge lists of manually maintained s…

But in this case a human applied their special knowledge in glibc, what's stopping the human applying the same knowledge to the compiler itself for this specific OS/arch?

Primarily because it would make it more difficult to detect and debug out-of-bounds reads, so at the very least it's not something you'd want to do by default, even at high optimization levels.

Possibly it might also be an awkward, complex, or dangerous (as in risk of unintended consequences) optimization to selectively violate the memory model that way. But I'm not familiar with the internals of optimizing compilers, so that's just conjecture.

Re: Why is strlen so complex in C?

#69

Post by ncmncm »

anmorgan wrote: post #65
ncmncm wrote: post #50

Earlier quoted context omitted.

Simply this: if you write C code, it produces the same instructions compiling with a C or C++ compiler. But a C compiler restricts you to the C subset. Many of the most useful features of C++ generate no extra instructions, but make the code more maintainable. There are libraries that compile to no code except exactly what you call, optimized down to exactly the circumstances of the call, wholly inexpressible in C, t…

Okay, I think this reply helps frame your stance much better. You are not necessarily proposing no C ever, but saying at least start a new project with a C++ compiler / IDE and if there are reasons to use C code or rules like "don't use dynamic memory allocation", when there is a substantial reason, then that is acceptable

There is no connection between C++ and dynamic memory allocation. Most of my C++ programs allocate memory at startup, then run for weeks or months (on machines with 200+ GB of RAM) never allocating ever again. C programs routinely allocate dynamic memory, except where there is reason not to; likewise C++.

So, no, there is never a reason to confine yourself to the C subset, in a new program. "for (auto e : v)" is universally better than "for (i = 0; i != N; ++i)". Zero cost, better code.

But I would never, ever suggest using an IDE, under any circumstances, for any language.

Re: Why is strlen so complex in C?

#70

Post by seisvelas »

saagarjha wrote: post #8
seisvelas wrote: post #7

Earlier quoted context omitted.

>that's par for the course on Stack Overflow This is tangential to the meat of your comment but I feel compelled to nitpick based entirely on personal anecdote: I have been helped hundreds of times on StackOverflow by people who had nothing to gain from it and yet provided in depth, insightful answers. In my experience, the farther you get away from the big, overwhelmed tags, the better the quality is. But you don't…

Yes, I'm not saying that Stack Overflow doesn't have "birdies". For example, I really enjoy this user's consistently high quality answers: https://stackoverflow.com/users/224132/peter-cordes

He once answered a question of mine about recursion with x86!
Post reply on HN