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

The Development of the C Language (1993)

bell-labs.com

Post reply on HN
Print view View original

241–250 of 536 posts

Re: The Development of the C Language (1993)

#241

Post by adwn »

binjooou wrote: post #158
adwn wrote: post #37

Earlier quoted context omitted.

> the C representation closely matches what is actually happening It really doesn't, though. Although your CPU might present system RAM as one contiguous array of bytes to your program, the C compiler follows different rules – see strict aliasing and other pointer dereference rules. For example, the following is Undefined Behavior and your C compiler may or may not generate the assembly you expect: int x = *(int *)0x…

Casting an integer to a pointer is implementation defined, not UB. And every sane implementation does what everyone expects because its how memory mapped IO works (but you probably want a volatile in there and maybe a compiler or memory barrier as well depending on what the hardware guarantees about the access patterns for that particular range of addresses)

> Casting an integer to a pointer is implementation defined, not UB.

You're right, that was a bad example. Here's a better one:

    int x, y;
    ptrdiff_t diff = &x - &y;
This is Undefined Behavior, because &x and &y don't point to the same object.

Re: The Development of the C Language (1993)

#242

Post by jstimpfle »

Voultapher wrote: post #85
mytailorisrich wrote: post #15

Earlier quoted context omitted.

> The C representation of memory (and all the pointer arithmetic) is not a real representation of your hardware, and this too is an abstraction. By and large memory is a contiguous array and the C representation closely matches what is actually happening, so I am curious about which platforms you have worked on.

A couple points: - CPU memory subsystems are very complex these days and represent a lot of shared mutable micro-architectural state, which makes it hard to reason about. That's not linear and the C language does not offer concepts which represent that complexity. Short of some prefetching intrinsics. - Pretty much all memory will be virtually addressed, pushing you even further from the concept of flat linear memory…

AFAIK C's machine model is not that linear (see my other comment). On the other hand, what most CPUs offer as an abstraction (through their instruction set) is very much so.

There are couple of arguments like that floating around and it just doesn't make a whole lot of sense. The C model is in fact a usable abstraction (and easy enough to peel off when required), otherwise it wouldn't have stuck around for so long. No amount of "network effects" and "free beer" arguments can discuss this away.

There is an argument that instruction sets might have developped a linear address space abstraction because of C, but I doubt it. Binding the IR closer to a specific physical layout would be very bad for portability and longevity of the code.

Re: The Development of the C Language (1993)

#243

Post by csdreamer7 »

dahfizz wrote: post #218
Timpy wrote: post #207

My career is in full stack web development but I program in C in my master's degree coursework and as a hobby. Every time I have to peel back a decade's worth of CSS to move a button on a webapp I daydream of moving to a career in C. Is the grass actually greener on the other side?

I program in C (HFT) and I love it

That is interesting. Most HFT I hear uses C++. Why C?

Re: The Development of the C Language (1993)

#244

Post by matheusmoreira »

babarock wrote: post #6

People who still write C, honest question: Why? C is full of quirks. From cryptic "undefined behaviors" to a type system that isn't really a type system (more like "size hints for the compiler"), the language doesn't feel easy to use/debug. Add to this CPP macros, a universally recognized bad idea, a clunky import system, and lack of a single reference implementation of the compiler/libC, and you have a language that…

C just feels good to read and write. Every other language suffers from not being C.

Re: The Development of the C Language (1993)

#245

Post by csdreamer7 »

Timpy wrote: post #207

My career is in full stack web development but I program in C in my master's degree coursework and as a hobby. Every time I have to peel back a decade's worth of CSS to move a button on a webapp I daydream of moving to a career in C. Is the grass actually greener on the other side?

It depends on what you like. I do Linux kernel development, so I program in C and currently learning Rust.

The kernel has a lot of it's data structures and functions so my work revolves around using that instead of the built-ins.

Re: The Development of the C Language (1993)

#246

Post by matheusmoreira »

moffkalast wrote: post #19
qsort wrote: post #12

Earlier quoted context omitted.

Because everything speaks C. If you write a library in C, it can be easily exposed to a variety of high-level languages and platforms. You might argue this is more a property of the C ABI than of C itself, but unless the project is large enough that it's worth doing it in C++ or Rust instead, it's still a very reasonable choice. Also not everything is web. Sure, if you're writing API endpoints in C you're just shooti…

So we're gonna be stuck writing a precambrian prototype language till the end of time because there's so much legacy code already written in it? Never seemed to stop people moving from Pascal, or Perl or literally all other languages that are now obsolete. I really hate how for microcontrollers the only two choices are either C++ or Micropython, I mean how about some fucking middle ground instead of two polar opposit…

> So we're gonna be stuck writing a precambrian prototype language till the end of time because there's so much legacy code already written in it?

Yes. Unless somebody steps up and rewrites everything in Rust or Lisp or whatever, that's exactly what's going to happen. Lack of backwards compatibility with existing software will condemn programming languages to irrelevance on day one.

Re: The Development of the C Language (1993)

#247

Post by akavi »

jylam wrote: post #221
Timpy wrote: post #207

My career is in full stack web development but I program in C in my master's degree coursework and as a hobby. Every time I have to peel back a decade's worth of CSS to move a button on a webapp I daydream of moving to a career in C. Is the grass actually greener on the other side?

That's very fun, very demanding, very well paid (when you have experience and know what you are doing) (as much as you can with C)

Both a specific request here and a general proposal for a norm here on HN: Can you be more numerically explicit when you say "well paid"?

Software development is a very segmented world. In the various social circles I'm connected to, I know devs who were thrilled to finally be making 6 figures 7 years out of college (in line-of-business software in a regional hub) and devs who were disappointed not to have crossed 400 k$/yr in that same time span (at FAANG in the bay area).

Re: The Development of the C Language (1993)

#248

Post by owlbite »

matheusmoreira wrote: post #240
Timpy wrote: post #207

My career is in full stack web development but I program in C in my master's degree coursework and as a hobby. Every time I have to peel back a decade's worth of CSS to move a button on a webapp I daydream of moving to a career in C. Is the grass actually greener on the other side?

I'd love to have a career in C too. To me it seems like Linux kernel development is the most obvious C programmer career path. Anyone know of alternatives?

Pretty much any low-level library in userspace as well, though there's a (very slow) move towards more security-focused languages/variants in those areas (probably also true of kernel space). Though C++ creeps in as well (we see a lot of "C with templates" coding).

Re: The Development of the C Language (1993)

#249

Post by aninteger »

matheusmoreira wrote: post #240
Timpy wrote: post #207

My career is in full stack web development but I program in C in my master's degree coursework and as a hobby. Every time I have to peel back a decade's worth of CSS to move a button on a webapp I daydream of moving to a career in C. Is the grass actually greener on the other side?

I'd love to have a career in C too. To me it seems like Linux kernel development is the most obvious C programmer career path. Anyone know of alternatives?

Maybe whatever RedHat is working on. Last I read there are only 2 people paid to work full time on GTK. I'm not sure if they are looking though.

Re: The Development of the C Language (1993)

#250

Post by camel-cdr »

badsectoracula wrote: post #227
camel-cdr wrote: post #95

Earlier quoted context omitted.

> let me store some state or have a loop This is arguably already possible, and was possible even before c99 added variadic macros. Although the code is a bit cumbersome to write.

It it technically possible in that C macros are supposedly Turing complete, but i mean i want something like being able to add a value to a variable, iterate through values (proper list would be neat but i'd be ok with a string of space separate values), etc.

> It it technically possible in that C macros are supposedly Turing complete

It isn't Turing complete, because it will always terminate, but you can make the execution time (number of execution steps) arbitrary large exponential in respect to the number of source lines.

There are a few libraries that implement that.

https://github.com/rofl0r/chaos-pp: Quite high level implementation, that supports arbitrary precision decimal base arithmetic.

https://github.com/camel-cdr/boline: Mine implements 8/16/32/64 bit arithmetic, and low level control flow.

You can very often get away with using unary numbers and/or constant expressions to work around the limitations without needing a library.

Got any problem in mind? I've got some time on my hands to problem solve.

Post reply on HN