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

C meeting is over. C23 added:

twitter.com

Post reply on HN
Print view View original

161–170 of 363 posts

Re: C meeting is over. C23 added:

#161

Post by pjmlp »

KnobbleMcKnees wrote: post #76
sgt wrote: post #17

Earlier quoted context omitted.

Sounds like you're not really in touch with the real word. C has many benefits and it is super practical. Yes, you can write unsafe code, but safety isn't always your #1 priority. There are also tools you can use to identify issues, which will mitigate risks.

I'm really starting to believe that there's a cohort of modern programmers that only see programming languages in terms of the high level syntactical features they provide. The logic of it is something like: I write the code, I run a command written using similar code, scenes deleted, my program runs and my IDE tells me if there are problems in my code. This is sometimes defined as the difference between developers a…

It was already irrelevant when using MS-DOS with Turbo Pascal/Modula-2/Basic compilers, or Mac OS (originally written in Object Pascal/Assembly).

It was UNIX industry adoption, followed by GNU Manifesto that made to more relevant than it should ever have been.

Re: C meeting is over. C23 added:

#162

Post by pjmlp »

rwmj wrote: post #52
diegocg wrote: post #46

Earlier quoted context omitted.

> developers who gets stuff done are constantly writing new code in C all the time. The amount of new C projects being created is falling at a fast rate. C isn't going anywhere, but it's certainly losing rapidly its prominence in the systems programming area.

[citation needed]

You can start by C compilers nowadays written in C++, Arduino, AUTOSAR security standard, CUDA, DirectX, Metal, GoDot, Vulkan helper libs, SYSCL, ...

Re: C meeting is over. C23 added:

#163

Post by dragonwriter »

sys_64738 wrote: post #128

It used to be that every new language starts off with a translator to C. Not sure if that’s the case nowadays.

> It used to be that every new language starts off with a translator to C.

No, it really never was that way, though there were some languages (especially ones that started as C plus some additional features, like C++ and Obj-C) that did that.

Re: C meeting is over. C23 added:

#164

Post by edflsafoiewq »

saagarjha wrote: post #30
reassembled wrote: post #20

Earlier quoted context omitted.

I feel like there’s actually a growing subculture of C programmers of late, seemingly spawned by Casey Muratori’s Handmade Hero series, Zed Shaw’s “Learn C The Hard” way and other more recent popularizations of C and low level programming ideas. There’s a whole “Handmade” software scene growing up, seemingly as a reaction against the bloat and over engineering of more recent software trends like Electron and web apps…

> seemingly spawned by Casey Muratori’s Handmade Hero series, Zed Shaw’s “Learn C The Hard” way It's kind of unfortunately, really, because both authors have very skewed viewpoints of C that are arguably quite incorrect.

What viewpoints are those, for those of us unfamiliar?

Re: C meeting is over. C23 added:

#165

Post by pjmlp »

pkrumins wrote: post #98
uncomputation wrote: post #31

Earlier quoted context omitted.

Huh? What do you think defines “regular C code that works”? Standards. Every compiler you have used operates at a bare minimum on the C standard. That’s why they are often advertised (if not GCC/Clang which are assumed to be up to date) as “C(89|99|11|17) compliant.” “Code that works” is code which is operates under constraints and guarantees specified by a standard, anything else is undefined or unportable.

Only the standards people care about standards. We (programmers) want to just get things done. We don't care about the standards. No one reads the standards. Also no one cares about portability. All computers have been the same for the last 20 years.

Right, then comes the day another OS or CPU needs to be supported and some clever developers learn their lesson about language standards during a couple of late nights tracking down production issues.

Re: C meeting is over. C23 added:

#166

Post by Someone »

hfsrgbcfuknbft wrote: post #149
Someone wrote: post #130

Earlier quoted context omitted.

I doubt it, and wouldn’t want it. It would break all kinds of optimizations. For example, with wrapping for(int i = 0; i Wouldn’t terminate if m = INT_MAX . That means compilers either have to special-case that value, or can’t use the loop instructions of some CPUs (M68000 has “decrement and branch if larger than zero”, for example) Also, with wrapping, a[i] and a[i+1] aren’t guaranteed to be adjacent. That can make…

Those things are very subtle and complex, so I'm not 100% sure, but I think your first example is not great: For example, with wrapping for(int i = 0; i This is undefined behavior in the current standard when m = INT_MAX. The condition i <= m is always true and i will overflow. So it could result in an infinite loop (or worse). AFAICT, with wrapping signed ints, it would infinite loop but at least not yield UB?

Yes, for m = INT_MAX and wrapping signed int, it is undefined behavior.

Because of that, the compiler is allowed to assume m ≠ INT_MAX, and that can mean it can generate more efficient and/or smaller code.

Assuming m ≠ INT_MAX isn’t (considered to be [1]) a big loss because chances are the programmer who wrote that didn’t intend to write an infinite loop.

[1] of course, is an opinion, but it’s the opinion the standards writers have had for decades.

Re: C meeting is over. C23 added:

#167

Post by pjmlp »

nec4b wrote: post #148
pjmlp wrote: post #136

Earlier quoted context omitted.

C's abstract machine is leaky and full of surprises when UB comes into play for one. Second when people talk about C being portable Assembly, they mistakenly assume to know what comes out of the compiler's backend. Third, unless we are speaking about PDP-11 like CPUs, modern CPUs have tons of capabilities not exposed to ISO C. Finally, since 1958 there are portable alternatives to Assembly in systems programming with…

You haven't answered the question? Maybe because is there is no concernable difference between abstract machine models of both languages? You can't do anything more about instruction reordering or cache invalidation at the CPU level with assembly than you can with C.

You surely can, better read those CPU manuals about line bus controllers.

Re: C meeting is over. C23 added:

#168

Post by saagarjha »

Didah wrote: post #62
saagarjha wrote: post #30

Earlier quoted context omitted.

> seemingly spawned by Casey Muratori’s Handmade Hero series, Zed Shaw’s “Learn C The Hard” way It's kind of unfortunately, really, because both authors have very skewed viewpoints of C that are arguably quite incorrect.

Out of curiosity: why do you consider Casey's viewpoint incorrect?

Casey doesn't really understand how optimizing compilers work, so he likes to talk about how they keep breaking his code and that they should just run the optimizations that won't do that.

Re: C meeting is over. C23 added:

#169

Post by moralestapia »

drran wrote: post #108
pkrumins wrote: post #99

C is the only sane language left. It never changes and it lets us write code that just works. We can focus on getting things done and shipping rather than learning new features and Googling compiler errors. Learn once, ship forever.

Majority of CVE's are because of C memory model, which is fixed in modern languages. C memory model is the constant source of vulnerabilities, thus it better to write new code in a memory safe language, like Rust.

>Majority of CVE's are because of C memory model

I haven't checked that but I believe you. My only nitpick is that I wouldn't put the whole blame for that on C, as there are proper ways to produce "safer"[1] code. What other languages did was lower the entry barrier to write better code, but that doesn't mean one language is inherently better that another.

1: No code is ever safe, not even formally verified code.

Post reply on HN