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

11–20 of 74 posts

Re: Why is strlen so complex in C?

#11

Post by kelnos »

saagarjha wrote: post #3

The accepted answer fails to understand that the standard library is exempt from following the C standard and makes a number of false or overly prescriptive assertions. (It also doesn't answer the question, but that's par for the course on Stack Overflow…)

> The accepted answer fails to understand that the standard library is exempt from following the C standard

I didn't read it that way at all. Consider the audience: the questioner admits that they are new to C. Because of that, the author of the accepted answer wanted to make it crystal clear that code like this should never be written "especially if you're not a C compiler / standard library vendor". The answerer explicitly acknowledges that the code depends on implementation-defined behavior.

IMO, the answer is great. It starts with a strong warning to never write code like that in your own programs (which you shouldn't), and then explains how it works, and why it works in the context of where it's written.

Re: Why is strlen so complex in C?

#12

Post by saagarjha »

compiler-guy wrote: post #10
raverbashing wrote: post #4

Earlier quoted context omitted.

It's such a shame that C gets some things like strings so wrong. Writing in C shouldn't have to be so painful, but I guess they were the pioneers in a lot of things and the "high level assembly" idea stuck. (Premature optimization?) Also having objects and method calls, even if it's syntactic sugar deep down, is the best kind of syntactic sugar

There was nothing "premature" about C's "high-level assembly" idea. It is somewhat archaic now, but C took off because it was so, so much better than normal assembly. If handling strings in plain C is hard, handling them in assembly is 10x as hard.

repne scasb disagrees with you :)

Re: Why is strlen so complex in C?

#13

Post by gonzo »

saagarjha wrote: post #3

The accepted answer fails to understand that the standard library is exempt from following the C standard and makes a number of false or overly prescriptive assertions. (It also doesn't answer the question, but that's par for the course on Stack Overflow…)

The accepted answer fails to note that the subject code is a high-performance variant of strlen(), and has basically taken the ideas from many highly-optimized memcpy() routines.

There is nothing wrong with the simpler version, but it’s not as fast (for longer strings).

Re: Why is strlen so complex in C?

#14

Post by saagarjha »

kelnos wrote: post #11
saagarjha wrote: post #3

The accepted answer fails to understand that the standard library is exempt from following the C standard and makes a number of false or overly prescriptive assertions. (It also doesn't answer the question, but that's par for the course on Stack Overflow…)

> The accepted answer fails to understand that the standard library is exempt from following the C standard I didn't read it that way at all. Consider the audience: the questioner admits that they are new to C. Because of that, the author of the accepted answer wanted to make it crystal clear that code like this should never be written "especially if you're not a C compiler / standard library vendor". The answerer ex…

s/especially/unless/: there is a good reason why the strlen is written that way; it's because it's fast and the standard library is allowed to make assumptions about the platform it's running on. But the answer instead dilutes itself and keeps saying things like "supposedly" and calling the code "bad", along with a long tangent by using the sanitizers to "prove" that the code is "wrong". For a beginner, I feel that this answer is much better than the one that's accepted: https://stackoverflow.com/a/57655203/5230900. It's not as long, so it would be nice to have more details about why the code does what it does, but it's not pushing an agenda.

Re: Why is strlen so complex in C?

#15

Post by scarface74 »

Ididntdothis wrote: post #2

Have there been any efforts to add real string types and maybe arrays to C? Seems a lot of complications come from the primitive/not existing implementation of strings and arrays.

Sure, Microsoft has added plenty of them over the years...

- BSTR

- CString

- bstr_t

- basic_string

- and a bunch of typedefs...

Re: Why is strlen so complex in C?

#16

Post by xenadu02 »

saagarjha wrote: post #14
kelnos wrote: post #11

Earlier quoted context omitted.

> The accepted answer fails to understand that the standard library is exempt from following the C standard I didn't read it that way at all. Consider the audience: the questioner admits that they are new to C. Because of that, the author of the accepted answer wanted to make it crystal clear that code like this should never be written "especially if you're not a C compiler / standard library vendor". The answerer ex…

s/especially/unless/: there is a good reason why the strlen is written that way; it's because it's fast and the standard library is allowed to make assumptions about the platform it's running on. But the answer instead dilutes itself and keeps saying things like "supposedly" and calling the code "bad", along with a long tangent by using the sanitizers to "prove" that the code is "wrong". For a beginner, I feel that t…

> it's because it's fast

Is it? We have to ask a few questions:

1. Is it actually faster on today's CPUs? (Any linear memory access pattern is going to be detected by the prefetcher)

2. Would the compiler do the same or better? eg, could it be auto-vectorizing the loop if we didn't play tricks?

3. If we really care about trading complexity for speed, wouldn't a hand-written SSE/SSE2/AVX implementation be even faster? Why not spend our complexity budget there?

Re: Why is strlen so complex in C?

#17

Post by compiler-guy »

saagarjha wrote: post #12
compiler-guy wrote: post #10

Earlier quoted context omitted.

There was nothing "premature" about C's "high-level assembly" idea. It is somewhat archaic now, but C took off because it was so, so much better than normal assembly. If handling strings in plain C is hard, handling them in assembly is 10x as hard.

repne scasb disagrees with you :)

As would many other assembly instructions on many other architectures.... and thereby proving my point. :-)

Re: Why is strlen so complex in C?

#18

Post by xenadu02 »

Ididntdothis wrote: post #2

Have there been any efforts to add real string types and maybe arrays to C? Seems a lot of complications come from the primitive/not existing implementation of strings and arrays.

In theory the standards committee could decide to add _array_ref to the language (or some variation on pointer+length). &myArray[10] could create an _array_ref where sizeof works against it and attempts to take a slice past the end of the array abort. I can even imagine compatibility shims like __attribute__((array_ref(1,2))) similar to printf-style format decorators that tell the compiler how to map function parameters of pointer+length to _array_ref.

There are many technical details to be worked out and choices to be made but there is no fundamental intractable problem preventing it. We'd have incremental adoption over many years. Maybe some legacy code would never be updated.

The primary blocker is getting the committee members to admit this is a problem that should be solved. That is difficult enough here on HN, where some people are still arguing that C is fine as-is and we just need to invent better programmers / better tools.

Ultimately C's lack of better string support comes from its lack of better array support. That comes from a certain subset of the programmer community that believes the status-quo is fine and isn't interested in such changes.

Re: Why is strlen so complex in C?

#19

Post by user5994461 »

Ididntdothis wrote: post #2

Have there been any efforts to add real string types and maybe arrays to C? Seems a lot of complications come from the primitive/not existing implementation of strings and arrays.

If you mean string as in text string, it's not done and I doubt it could ever be achieved in C++. It's too complicated because of unicode and string encoding aspects.

The new type wouldn't be usable either, because it would have to be converted down to another representation all the time when calling functions and libraries that are not aware of it. Think of C string to C++ string to boost string to whatever.

I think the closest usable thing is QString if you are using Qt.

Re: Why is strlen so complex in C?

#20

Post by saagarjha »

xenadu02 wrote: post #16
saagarjha wrote: post #14

Earlier quoted context omitted.

s/especially/unless/: there is a good reason why the strlen is written that way; it's because it's fast and the standard library is allowed to make assumptions about the platform it's running on. But the answer instead dilutes itself and keeps saying things like "supposedly" and calling the code "bad", along with a long tangent by using the sanitizers to "prove" that the code is "wrong". For a beginner, I feel that t…

> it's because it's fast Is it? We have to ask a few questions: 1. Is it actually faster on today's CPUs? (Any linear memory access pattern is going to be detected by the prefetcher) 2. Would the compiler do the same or better? eg, could it be auto-vectorizing the loop if we didn't play tricks? 3. If we really care about trading complexity for speed, wouldn't a hand-written SSE/SSE2/AVX implementation be even faster?…

Honestly, I don't know: I trust that the glibc people know what they are doing. However, in an attempt answer some of your questions: there is an SSE2 implementation available that might be used on computers that support it: https://github.com/bminor/glibc/blob/master/sysdeps/x86_64/s... . Perhaps this version is for platforms that don't have a hand-optimized implementation? I'm not sure if the compiler is smart enough to auto-vectorize an arbitrary strlen implementation (or delegate it to a library call).
Post reply on HN