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

50 years of C, the good, the bad and the ugly [video]

streaming.media.ccc.de

Post reply on HN
Print view View original

211–220 of 257 posts

Re: 50 years of C, the good, the bad and the ugly [video]

#211

Post by menaerus »

zozbot234 wrote: post #117
menaerus wrote: post #111

Earlier quoted context omitted.

In the absence of CPU instruction which does the saturated ADD, how do you solve the overflow problem in a bare-metal language without introducing the performance hit?

The performance hit of overflow has nothing to do with lacking assembly instructions. It's all about having to preserve error states whenever overflow occurs and inhibiting optimization.

I don't follow. If we had the saturated ADD instruction supported in hardware we wouldn't have to deal with saturation logic in software. Compiler would simply be able to emit SADD instruction whenever we asked for it to and would be given a chance to spit out more optimized code because that would essentially be a branchless code.

Reality though is that we don't have such hardware and we have to deal with it in software, so, instead of a single instruction emitted there will be a bunch of them, and of which there will be certainly branches involved.

Re: 50 years of C, the good, the bad and the ugly [video]

#212

Post by menaerus »

titzer wrote: post #122
menaerus wrote: post #111

Earlier quoted context omitted.

In the absence of CPU instruction which does the saturated ADD, how do you solve the overflow problem in a bare-metal language without introducing the performance hit?

It depends on how you define your language semantics. If you choose 2's complement wraparound semantics, which is what nearly all CPUs in the world have standardized on, there is nothing for the compiler to do. It's a pure operation, a single instruction, and can be constant-folded, strength-reduced, CSE'd, moved, dead-code-eliminated, etc. If you want a different semantics at the source level, e.g. overflow is an ex…

> If you want a different semantics at the source level, e.g. overflow is an exception, then the compiler needs to emit additional code.

Yes, and which is exactly what I hinted at with my question to your comment. With the HW we have today, implementing such semantics without an extra hit is not possible and which is why I thought your comment wasn't completely fair but coming from more theoretical stance.

Re: 50 years of C, the good, the bad and the ugly [video]

#213

Post by sylware »

flohofwoe wrote: post #32
sylware wrote: post #14

Earlier quoted context omitted.

C syntax is already way too rich and complex, not to mention the bazillions of gcc extensions required to compile the linux kernel. Namely, if it has to be "replaced", that would be with something with a much simpler syntax, which will require a bit more of finger power. We don't want to find ourself locked-in by very few compiler vendors (open source or not), that only because it is not reasonable to code a real-lif…

TBH that sounds a lot like Zig (it has two loop keywords though: for and while, but those are for different use cases - for is only for iterating over ranges, and while is the 'vanilla loop' for everything else). Zig does introduce a bit of syntax pollution for its comptime features though (mainly the 'inline' variants of existing keywords), and it adds some syntax sugar for the builtin error handling and optionals -…

This is one too many loop keyword.

And something must be done about breaking changes of the syntax (or any never ending "features" additions).

We all know that some syntaxic constructs will be nasty in the end and will reasonably need fixing (basically, to keep them excrusiatingly simple from a compiler writing point of view). I am thinking about something like "syntax breakage provisions" from the language authors: for instance, no more than 4 iterations of major syntax breakages, then the language syntax will be frozen for forever.

Whatever, I am a everything in assembly kind of guy (with high-level language interpreters written themselves in assembly).

All that is a thought experiment for me, nothing more.

Re: 50 years of C, the good, the bad and the ugly [video]

#214

Post by WastingMyTime89 »

kazinator wrote: post #197
WastingMyTime89 wrote: post #186

Earlier quoted context omitted.

I am extremely familiar with C. I used to work on a static analyser for it. The issue is that there is very little to like in how C is designed from a PL point of view. You are confusing what the language can do and what is semantic is. C strings are just a contiguous allocation of byte and a bunch of functions which interprets it as ascii characters and stop on a specific value. That’s literally the worst representa…

I think it's a nice representation, allowing easy recursion. const char *my_strchr(const char *str, int ch) { if (*str == 0) return NULL; if (*str == ch) return str; return my_strchr(str + 1); } It's a good format for storage and communication. Name any other string data structure and I will cite you all the disadvantages compared to the C string. - If the format contains pointers, you have to marshal it to a flat re…

C null terminated strings are not magic. Protocols between the sender and receiver have to be defined. You face exactly the same problem regarding byte order, size consideration and marshalling with C strings.

You are basically arguing that C strings are a good default because they are the default. If they were something else, well, we would have saner FFI in a lot of place.

C strings are a terrible default. They are fundamentally unsafe. Mishandle the null char for any reason and you now face a serious security issue.

Re: 50 years of C, the good, the bad and the ugly [video]

#215

Post by imran0 »

Koshkin wrote: post #167
asveikau wrote: post #153

Earlier quoted context omitted.

There are plenty of interesting C works out there, as well as data structures or algorithms that C can express elegantly. Small example, linked lists. I don't think non-C linked list code tends to be as straightforward as I've seen in C. Or the character-at-a-time style of string processing. It's kind of unique to C. You can say there is stuff about that you don't like. That's fine. Linked lists suck with modern CPU…

> as straightforward as I've seen in C To be fair, the most straightforward definition of the linked list is generic, and C completely lacks such facility. > fascist - Sounds familiar. https://news.ycombinator.com/item?id=33478321

> Sounds familiar.

I cannot decide whether it's an honor or an insult to be called a _fascist sympathizer_ for opposing the authoritarian suppression of speech.

Re: 50 years of C, the good, the bad and the ugly [video]

#216

Post by andsoitis »

kazinator wrote: post #197
WastingMyTime89 wrote: post #186

Earlier quoted context omitted.

I am extremely familiar with C. I used to work on a static analyser for it. The issue is that there is very little to like in how C is designed from a PL point of view. You are confusing what the language can do and what is semantic is. C strings are just a contiguous allocation of byte and a bunch of functions which interprets it as ascii characters and stop on a specific value. That’s literally the worst representa…

I think it's a nice representation, allowing easy recursion. const char *my_strchr(const char *str, int ch) { if (*str == 0) return NULL; if (*str == ch) return str; return my_strchr(str + 1); } It's a good format for storage and communication. Name any other string data structure and I will cite you all the disadvantages compared to the C string. - If the format contains pointers, you have to marshal it to a flat re…

This routine only works with ASCII, yea?

Re: 50 years of C, the good, the bad and the ugly [video]

#217

Post by hgs3 »

turndown wrote: post #194
hgs3 wrote: post #174

Earlier quoted context omitted.

Those are fair points, but they're probably too specific to the architecture to incorporate in C's general execution model. They're better exposed through platform specific programming interfaces like OpenMP or CUDA. Even a domain specific language, like GLSL, may be more appropriate.

I think that the general point being made here is that C’s general execution model, as you call it, really is just a PDP-like computer because that is what they had when making C.

The confusion I have is that the original commenter makes it sound like the abstract machine C is designed for is not relevant today. While modern desktop hardware may use various techniques to improve performance, like cache lines or specialized cores, they are an implementation detail of that abstract machine. I would not expect C to expose these hardware specifics because C targets a lowest common denominator, from consumer desktop hardware to microprocessors. If the criticism is that C is too general, then that's fair but also applies to every C competitor: Rust, Zig, D, etc... It's debatable how much these languages should include versus exposed by vendor specific API's. Perhaps we need a fork of C designed exclusively for modern desktop hardware.

Re: 50 years of C, the good, the bad and the ugly [video]

#218

Post by asveikau »

imran0 wrote: post #215
Koshkin wrote: post #167

Earlier quoted context omitted.

> as straightforward as I've seen in C To be fair, the most straightforward definition of the linked list is generic, and C completely lacks such facility. > fascist - Sounds familiar. https://news.ycombinator.com/item?id=33478321

> Sounds familiar. I cannot decide whether it's an honor or an insult to be called a _fascist sympathizer_ for opposing the authoritarian suppression of speech.

I didn't want to address this because it's a tangent, but I understand that free speech protects expressing fascist thought. I can still disapprove of it and not want to be around a lot of it, consider high concentrations of it to be a sign of an unhealthy community, without saying it should be somehow illegal.

Re: 50 years of C, the good, the bad and the ugly [video]

#219

Post by kazinator »

WastingMyTime89 wrote: post #214
kazinator wrote: post #197

Earlier quoted context omitted.

I think it's a nice representation, allowing easy recursion. const char *my_strchr(const char *str, int ch) { if (*str == 0) return NULL; if (*str == ch) return str; return my_strchr(str + 1); } It's a good format for storage and communication. Name any other string data structure and I will cite you all the disadvantages compared to the C string. - If the format contains pointers, you have to marshal it to a flat re…

C null terminated strings are not magic. Protocols between the sender and receiver have to be defined. You face exactly the same problem regarding byte order, size consideration and marshalling with C strings. You are basically arguing that C strings are a good default because they are the default. If they were something else, well, we would have saner FFI in a lot of place. C strings are a terrible default. They are…

> You face exactly the same problem regarding byte order, size consideration and marshalling with C strings.

Not char/byte C strings. You might be thinking of wchar_t strings.

> Mishandle the null char for any reason and you now face a serious security issue.

With what string data structure can applications peak into and mishandle an implementation detail and not risk creating a security problem?

Same you have a structure with the length and a pointer. Mishandle the length field or pointer and you have a problem.

It certainly is a problem and it's common for C applications to take on responsibilities for manipulating the internals of the string structure.

Re: 50 years of C, the good, the bad and the ugly [video]

#220

Post by kazinator »

andsoitis wrote: post #216
kazinator wrote: post #197

Earlier quoted context omitted.

I think it's a nice representation, allowing easy recursion. const char *my_strchr(const char *str, int ch) { if (*str == 0) return NULL; if (*str == ch) return str; return my_strchr(str + 1); } It's a good format for storage and communication. Name any other string data structure and I will cite you all the disadvantages compared to the C string. - If the format contains pointers, you have to marshal it to a flat re…

This routine only works with ASCII, yea?

It will also find ASCII characters in UTF-8. That's a common situation because delimiting characters are often in the ASCII range.

We can make a more complicated example that nevertheless uses recursion and essentially the same way, which looks for a UTF-8 character. We can examine and decode a prefix of the string as a UTF-8. If there are bad bytes or the character doesn't match then we recurse.

We can also write a wide character (wchar_t) version of the function which looks the same. That will handle all of Unicode on sane platforms, and the basic multilingual plane (BMP) on Windows.

Post reply on HN