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

Linux eliminates the strncpy API after six years of work, 360 patches

phoronix.com

Post reply on HN
Print view View original

301–310 of 340 posts

Re: Linux eliminates the strncpy API after six years of work, 360 patches

#301

Post by Gibbon1 »

imtringued wrote: post #269
Gibbon1 wrote: post #129

Earlier quoted context omitted.

Problems with unaligned pointers are basically a hardware defect. Signed overflow is an issue because academics are unhappy computers only can do finite math. Issue with types and C is while the compiler knows about them the standards committees don't want you to be able to. If C had first class types more people would abandon C++ and that can't be allowed to happen.

The concept of alignment isn't a hardware defect, maybe limitation, but the reason why alignment is a thing has to do with the fact that in chip interconnects transfer blocks. You cannot perform misaligned memory accesses against RAM. A similar limitation exists when peforming accesses against the cache, but at a much finer granularity. For bytes, the alignment restriction obviously exists in the 8 bit level. You hav…

With modern CPU's unaligned accesses only matter when it straddles a cache line address not a register address.

Re: Linux eliminates the strncpy API after six years of work, 360 patches

#302

Post by atherton94027 »

imtringued wrote: post #262
atherton94027 wrote: post #123

Earlier quoted context omitted.

How are you going to build sum types in a way where you can interact with assembly or machine code? The CPU doesn't know about that stuff

Sum types map down to reading a tag and doing a comparison against fixed values. I don't know what to tell you, but you're clearly not cut out to be a software developer in either machine code, assembly or C or any other language if you don't understand something this basic.

Please check your tone down, I'm arguing politely with you but apparently you're so wrapped up in this that you're resorting to ad hominems.

Sum types aren't the be all end all to all issues, for example you can not representer pointer values efficiently with sum types. Even rust does not wrap up pointers with sum types. Now try to go back 37 years to C89 and ask yourself if they were going to require compilers to have stringent checks like the rust compiler does.

Re: Linux eliminates the strncpy API after six years of work, 360 patches

#303

Post by Gibbon1 »

AlotOfReading wrote: post #231
Gibbon1 wrote: post #129

Earlier quoted context omitted.

Problems with unaligned pointers are basically a hardware defect. Signed overflow is an issue because academics are unhappy computers only can do finite math. Issue with types and C is while the compiler knows about them the standards committees don't want you to be able to. If C had first class types more people would abandon C++ and that can't be allowed to happen.

Unaligned pointers are undefined behavior even when the hardware fully supports unaligned access, because you're violating the type's rules. To be honest, I've never seen much indication that the C and C++ committees are particularly fond of each other. They sometimes coordinate, but they're mostly content letting each other evolve in different directions. C is the way it is only after a long process of evolution awa…

Undefined behavior according to WG14 but perfectly fine on most architectures. Even on architectures that don't support it (what the fuck ARM cortex) the compilers do support it.

Re: Linux eliminates the strncpy API after six years of work, 360 patches

#304

Post by pdimitar »

atherton94027 wrote: post #302
imtringued wrote: post #262

Earlier quoted context omitted.

Sum types map down to reading a tag and doing a comparison against fixed values. I don't know what to tell you, but you're clearly not cut out to be a software developer in either machine code, assembly or C or any other language if you don't understand something this basic.

Please check your tone down, I'm arguing politely with you but apparently you're so wrapped up in this that you're resorting to ad hominems. Sum types aren't the be all end all to all issues, for example you can not representer pointer values efficiently with sum types. Even rust does not wrap up pointers with sum types. Now try to go back 37 years to C89 and ask yourself if they were going to require compilers to ha…

Nobody claimed that "sum types are be all end all". I originally responded to "how would you handle cases where a value is unset without NULL" with "sum types" which are trivially presentable with bit masks if memory usage is of big concern (and nowadays in 99.9999% of the cases it genuinely is not).

And, tagged unions are a thing and were a thing for a long time.

Of course it's too late to change all this today; it would have been too late even 20 years ago. But outside of f.ex. Linux kernel and some other super hardcore C libraries, a lot can be done for the world to migrate to safer constructs and away from sentinel values. And that's what languages like Rust do.

Super memory constrained environments have not been the mainstream programming work for decades and now remain limited to embedded / IoT. Not sure what the reservation against sum types is these days.

Re: Linux eliminates the strncpy API after six years of work, 360 patches

#305

Post by pdimitar »

bigstrat2003 wrote: post #290
imtringued wrote: post #262

Earlier quoted context omitted.

Sum types map down to reading a tag and doing a comparison against fixed values. I don't know what to tell you, but you're clearly not cut out to be a software developer in either machine code, assembly or C or any other language if you don't understand something this basic.

That's unnecessarily rude, and untrue in any case. Everyone has to learn stuff sometime, and most people won't naturally run into the implementation details of how higher level languages get translated into machine code.

I agree his tone was not productive but the comment he responded to seemed like a disingenuous argument as well. "The CPU doesn't know about that stuff" is not true -- or it's arguing in bad faith. I mean, hello, tagged unions, all of us with some experience can write a C program that works with those. It's 100% false to say what he said.

Re: Linux eliminates the strncpy API after six years of work, 360 patches

#306

Post by AlotOfReading »

Gibbon1 wrote: post #303
AlotOfReading wrote: post #231

Earlier quoted context omitted.

Unaligned pointers are undefined behavior even when the hardware fully supports unaligned access, because you're violating the type's rules. To be honest, I've never seen much indication that the C and C++ committees are particularly fond of each other. They sometimes coordinate, but they're mostly content letting each other evolve in different directions. C is the way it is only after a long process of evolution awa…

Undefined behavior according to WG14 but perfectly fine on most architectures. Even on architectures that don't support it (what the fuck ARM cortex) the compilers do support it.

Yes, that's exactly the point I've been making. It's undefined today because C has a type system and that type system has this arbitrary rule, not because there are implementation constraints necessitating it (where it could just be implementation defined instead).

Re: Linux eliminates the strncpy API after six years of work, 360 patches

#307

Post by pjmlp »

jll29 wrote: post #200
pjmlp wrote: post #186

Earlier quoted context omitted.

Successful systems languages trace back all the way to JOVIAL in 1958. You missed quite a few between JOVIAL, and C being adopted outside Bell Labs. Modula-2 was as widely available as C was outside UNIX and universities with access to UNIX source code. It took a while for proper C to actually be "used for everything else", until the early 1990s actually, and by then anyone sensible would be much better with Typescri…

> Typescript for C You mean "C with Classes", later to be replaced by "C++" (Stroustrup pick this as favorite from a list of candidate names he crowdsourced) as implemented by Cfront.

Of course, although Typescript for C++ is a more modern way to put it for younger generations.

Re: Linux eliminates the strncpy API after six years of work, 360 patches

#308

Post by pjmlp »

rswail wrote: post #210
jll29 wrote: post #200

Earlier quoted context omitted.

> Typescript for C You mean "C with Classes", later to be replaced by "C++" (Stroustrup pick this as favorite from a list of candidate names he crowdsourced) as implemented by Cfront.

I preferred "P" because of the BCPL ancestor. If BCPL begat "B" and "B" begat "C", then "C" should have begatten "P". Not sure if begatten is a word :)

BCPL is short of Bootstrap CPL, given its initial purpose, the fact it took off on its own was not planned.

Re: Linux eliminates the strncpy API after six years of work, 360 patches

#309

Post by atherton94027 »

pdimitar wrote: post #304
atherton94027 wrote: post #302

Earlier quoted context omitted.

Please check your tone down, I'm arguing politely with you but apparently you're so wrapped up in this that you're resorting to ad hominems. Sum types aren't the be all end all to all issues, for example you can not representer pointer values efficiently with sum types. Even rust does not wrap up pointers with sum types. Now try to go back 37 years to C89 and ask yourself if they were going to require compilers to ha…

Nobody claimed that "sum types are be all end all". I originally responded to "how would you handle cases where a value is unset without NULL" with "sum types" which are trivially presentable with bit masks if memory usage is of big concern (and nowadays in 99.9999% of the cases it genuinely is not). And, tagged unions are a thing and were a thing for a long time. Of course it's too late to change all this today; it…

Yeah and I was trying to explain that sum types don't work for pointers, without a significant performance hit.

No one here is saying C is a great design, but in the context of 60 years ago, it worked out pretty well, and all the language which had additional runtime complexity (Pascal of course, but also Ada and FORTH) struggled because they didn't dial the right level of complexity

Re: Linux eliminates the strncpy API after six years of work, 360 patches

#310

Post by pjmlp »

rswail wrote: post #205
pjmlp wrote: post #186

Earlier quoted context omitted.

Successful systems languages trace back all the way to JOVIAL in 1958. You missed quite a few between JOVIAL, and C being adopted outside Bell Labs. Modula-2 was as widely available as C was outside UNIX and universities with access to UNIX source code. It took a while for proper C to actually be "used for everything else", until the early 1990s actually, and by then anyone sensible would be much better with Typescri…

I dunno, I was starting my career around 1980-81, and the choices were 6502/6509/Z80/8088 asm, C, UCSD-Pascal, and BASIC at the micro level, C/asm was the rule for RT-11/RSX-11 and then the VAX OSs at the "minicomputer" level. I had a friend that tried to get everyone using Modula-2 but the "ecosystem" wasn't as great around the uni/ex-uni environments where I was. C was pretty entrenched by the end of the 1980s, alt…

Alone the fact that you mention RT-11/RSX-11 and VAX OSs shows we were not on the same bubble.

Anyway on VMS most folks would be found using the VMS BASIC compiler, VMS Pascal or Bliss, until Open VMS made it yet another UNIX clone.

My first C compiler used the RatC dialect, let alone having access to a proper K&R C compiler.

By 1992, I already had access to a proper C++ compiler on MS-DOS, and C was history to me, other than scenarios were work was expected to be done in C like some university assignments, even here we were blessed with a plethora of languages between Lisp, Prolog, Smalltalk, ML, C, C++,....

Post reply on HN