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

31–40 of 74 posts

Re: Why is strlen so complex in C?

#31

Post by justinmeiners »

kllrnohj wrote: post #30
MadWombat wrote: post #24

Earlier quoted context omitted.

This is kind of the point of C. It maps directly to the hardware. There are very few decisions the compiler has to make about the code. And it is for that reason that C does not allow for higher level abstractions. On one hand, it is a pain to write. On the other hand, you know exactly what is going on under the hood and nothing is ever going to stop you from shooting yourself in a body part of your choice :)

> This is kind of the point of C. It maps directly to the hardware. No it doesn't. It didn't in the past, it was a high-level abstraction. And it doesn't today, because CPUs don't behave at all like C's defined virtual machine.

> CPUs don't behave at all like C's defined virtual machine

What "virtual machine" are you referring to?

Re: Why is strlen so complex in C?

#32

Post by CameronNemo »

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.

As for arrays, I frequently find implementations of hash maps and linked lists that come with macros for iteration, appending, etc. libnih is the first to come to mind (GPLv2 only), but I also know that the LXC project has some similar code floating around in there... probably LGPLv2+.

Re: Why is strlen so complex in C?

#33

Post by saagarjha »

bjourne wrote: post #25

It wouldn't surprise me if the "unoptimized" strlen is just as fast or even faster on modern x86 hw. Both algorithms need to process the same amount of data. Thus they will fetch exactly the same number of cache lines from main memory. Likely, the cost of fetching those cache lines dominates, meaning that it doesn't matter that the "unoptimized" version does more processing per byte. Only way to find out for sure is…

I would expect a vectorized implementation to perform better than this one.

Re: Why is strlen so complex in C?

#34

Post by saagarjha »

justinmeiners wrote: post #31
kllrnohj wrote: post #30

Earlier quoted context omitted.

> This is kind of the point of C. It maps directly to the hardware. No it doesn't. It didn't in the past, it was a high-level abstraction. And it doesn't today, because CPUs don't behave at all like C's defined virtual machine.

> CPUs don't behave at all like C's defined virtual machine What "virtual machine" are you referring to?

The one defined in the standard.

Re: Why is strlen so complex in C?

#35

Post by adrianmonk »

bjourne wrote: post #25

It wouldn't surprise me if the "unoptimized" strlen is just as fast or even faster on modern x86 hw. Both algorithms need to process the same amount of data. Thus they will fetch exactly the same number of cache lines from main memory. Likely, the cost of fetching those cache lines dominates, meaning that it doesn't matter that the "unoptimized" version does more processing per byte. Only way to find out for sure is…

The optimized implementation might use less power, though. With a slower algorithm, the CPU isn't the bottleneck, but it might still have more work to do.

Re: Why is strlen so complex in C?

#37

Post by ncmncm »

saagarjha wrote: post #6
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.

None that have succeeded, obviously. There are a number of alternative string libraries, though; here's one: https://github.com/antirez/sds . And I'm sure some programmers would suggest C++ as the real "effort to add real string types and maybe arrays to C" ;)

I, in fact, do suggest C++ as the right answer, where it is not precluded for practical or silly reasons.

It is generally quite easy to compile a C program with a C++ compiler, and then the sky's the limit on code improvements. I recommend it, and suggest starting with improvements to memory safety.

There is really no excuse for writing a new C program anymore.

Re: Why is strlen so complex in C?

#38

Post by ncmncm »

pornel wrote: post #26
xenadu02 wrote: post #18

Earlier quoted context omitted.

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 paramet…

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.

We already know C's future.

The people using old C are self-selected as those who like it the way it is. They accepted atomics because of new hardware. The place to ask for new, better stuff is at the C++ desk, and it has lots already.

Re: Why is strlen so complex in C?

#39

Post by wahern »

zamalek wrote: post #27
bcaa7f3a8bbc wrote: post #23

It's worth pointing out that the author was reading an outdated implementation of strlen() from glibc. The generic implementation is still here with the same code, and would be complied if no ARCH-specific implementation is written, as seen here, https://github.com/bminor/glibc/blob/master/string/strlen.c . But it's probably irrelevant to most systems today, as the assembly version is almost always used, e.g. * i386:…

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 suppressions to account for hacks like this that violate the standard rules.

Re: Why is strlen so complex in C?

#40

Post by ncmncm »

MadWombat wrote: post #24
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

This is kind of the point of C. It maps directly to the hardware. There are very few decisions the compiler has to make about the code. And it is for that reason that C does not allow for higher level abstractions. On one hand, it is a pain to write. On the other hand, you know exactly what is going on under the hood and nothing is ever going to stop you from shooting yourself in a body part of your choice :)

C gives the illusion of mapping to the hardware. Hardware manufacturers have moved heaven and earth to help maintain the illusion. It finally got too hard and they had to admit atomics and cores ro the model. The next watershed will be along soon enough, but the ability to present as a C machine has long been the gateway to success or failure of a new hardware architecture. Myriads of arguably superior machine designs have foundered on "but can I code for it in C?"
Post reply on HN