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

Some Were Meant for C: The Endurance of an Unmanageable Language [pdf]

cl.cam.ac.uk

Post reply on HN
Print view View original

241–250 of 253 posts

Re: Some Were Meant for C: The Endurance of an Unmanageable Language [pdf]

#241

Post by pjmlp »

speedplane wrote: post #239
pjmlp wrote: post #237

Earlier quoted context omitted.

Turbo Pascal did not die, it was reborn as Delphi and only decreased its market share because many key developers ended up going to Microsoft, while Borland management decided enterprise customers were more important than indies.

What year did Borland make that call? I remember my HS programming class in the late 1990s used a Borland compiler and development environment. I don't recall it being "enterprisey" at the time. That being said I was in HS, and likely associated the word "enterprise" with starships more than big companies.

When they re-braded themselves as Inprise, 1996.

https://en.wikipedia.org/wiki/Borland

Re: Some Were Meant for C: The Endurance of an Unmanageable Language [pdf]

#242

Post by [deleted] »

Koshkin wrote: post #122
marktangotango wrote: post #87

Earlier quoted context omitted.

The idea you can have a safe c compiler or runtime seems totally absurd to me. Why is any of this even considered seriously?

Indeed. Even the "obvious" example of the compiler inserting bound checks in the generated code does not work with the well-known method of marking the beginning of a variable-length memory block at the end of a struct using an array of some fixed size, say, 1 (or even 0).

[deleted]

Re: Some Were Meant for C: The Endurance of an Unmanageable Language [pdf]

#243

Post by pjmlp »

rurban wrote: post #221
ktRolster wrote: post #125

Earlier quoted context omitted.

That particular problem (strlen/strcpy/memcpy) comes from the problems of the standard library string functions. It can be solved by creating your own string library. Then string manipulation is easy.

This problem was actually solved, but almost nobody uses it. Safe variants of most of those string, memory, io, wchar, stdlib and misc functions are defined in the C11 standard Annex K (finally after 9 years), but nobody is using it, and rather propose to keep using known unsafe variants like the truncating versions with an n. Like snprintf and not the safe variant sprintf_s. glibc, bsd, darwin, musl, newlib: nobody…

Annex K is not safe, just pretends to be.

By tracking the pointer and sizes as separate function arguments, the possibility of mixing parameters, leading to memory corruption is still there.

This is the major motivation why almost nobody uses it and it was made into an optional annex.

Re: Some Were Meant for C: The Endurance of an Unmanageable Language [pdf]

#244

Post by Const-me »

pjmlp wrote: post #236
Const-me wrote: post #169

Earlier quoted context omitted.

> move further away from the hardware in exchange for some language comforts & quality of life improvements C# has descent native interop, i.e. [DllImport]. On Linux it imports from .so dynamic libraries. When you want to be closer to the hardware, because SIMD, or system calls not exposed to .NET, or integration with third-party C code, it usually works OK.

C# has some SIMD support since version 6.

Very limited support. On x86-64, the only languages that have good SIMD support are C (С++ gets that for free, ‘coz compatibility) and Fortran.

Re: Some Were Meant for C: The Endurance of an Unmanageable Language [pdf]

#245

Post by bsder »

pjmlp wrote: post #234
bsder wrote: post #225

Earlier quoted context omitted.

And, with the exception of Ada and Pascal, most of those language have been dead for at least 20 years--for various good reasons. And, please do remember that Apple switched away from Pascal when writing its operating systems in spite of an enormous code base. That's pretty damning--apparently C's "undefined behavior" didn't seem to matter. So, we're back to: the only alternative to C is Ada. > Though there are certa…

Apple switched away from Pascal due to UNIX market pressure. http://basalgangster.macgui.com/RetroMacComputing/The_Long_V... http://basalgangster.macgui.com/RetroMacComputing/The_Long_V... And it was mostly to C++, not C. Pascal is used daily for embedded system work by MikroElektronika customers using mikroPascal. https://www.mikroe.com/mikropascal/ Any embedded application using Ada's Ravenscar profile, is an OS. h…

So, C, Pascal, and Ada with a smidge of effectively dead languages.

Okay, sad to know I'm not missing anything.

Re: Some Were Meant for C: The Endurance of an Unmanageable Language [pdf]

#246

Post by pjmlp »

Const-me wrote: post #244
pjmlp wrote: post #236

Earlier quoted context omitted.

C# has some SIMD support since version 6.

Very limited support. On x86-64, the only languages that have good SIMD support are C (С++ gets that for free, ‘coz compatibility) and Fortran.

There is also D and Object Pascal, unless you won't consider inline Assembly as having support.

Oh and Fortran of course.

But yeah, I also find it sad having to go down to Assembly to make use of them.

Re: Some Were Meant for C: The Endurance of an Unmanageable Language [pdf]

#247

Post by [deleted] »

bsder wrote: post #245
pjmlp wrote: post #234

Earlier quoted context omitted.

Apple switched away from Pascal due to UNIX market pressure. http://basalgangster.macgui.com/RetroMacComputing/The_Long_V... http://basalgangster.macgui.com/RetroMacComputing/The_Long_V... And it was mostly to C++, not C. Pascal is used daily for embedded system work by MikroElektronika customers using mikroPascal. https://www.mikroe.com/mikropascal/ Any embedded application using Ada's Ravenscar profile, is an OS. h…

So, C, Pascal, and Ada with a smidge of effectively dead languages. Okay, sad to know I'm not missing anything.

[deleted]

Re: Some Were Meant for C: The Endurance of an Unmanageable Language [pdf]

#248

Post by carlmr »

camgunz wrote: post #145
WalterBright wrote: post #109

Earlier quoted context omitted.

> mental ease I'm a long time C programmer, and I was struck by how clumsy and error-prone any manipulation of C strings turns into. It's really hard to look at a mass of strlen/strcpy/memcpy/etc. and see just what is happening. Contrast that with, say, BASIC or Javascript, where string manipulation is easy, natural, and bug-free. I'm going to disagree about the mental ease of programming in C, and a large part of th…

I think the mental model isn't the issue, it's that the C Standard Library is very anemic. When writing a C application either you're using a big library like APR or GLib or you're rolling your own, and since rolling your own is a pretty big, complicated, and fraught proposition it's no surprise bugs creep in. Furthermore you can't really interop with other libraries if they also rolled their own data structures beca…

Completely agree. It's like when people say programming Python is fast. No it just has almost everything pre built and you glue it together.

C's standard library is just sad.

Re: Some Were Meant for C: The Endurance of an Unmanageable Language [pdf]

#249

Post by rurban »

pjmlp wrote: post #243
rurban wrote: post #221

Earlier quoted context omitted.

This problem was actually solved, but almost nobody uses it. Safe variants of most of those string, memory, io, wchar, stdlib and misc functions are defined in the C11 standard Annex K (finally after 9 years), but nobody is using it, and rather propose to keep using known unsafe variants like the truncating versions with an n. Like snprintf and not the safe variant sprintf_s. glibc, bsd, darwin, musl, newlib: nobody…

Annex K is not safe, just pretends to be. By tracking the pointer and sizes as separate function arguments, the possibility of mixing parameters, leading to memory corruption is still there. This is the major motivation why almost nobody uses it and it was made into an optional annex.

No. The major motivation not to use it was _FORTIFY_SOURCE with it's compile checks for compile-time known buffer sizes and it's accompanying _chk functions. This leaves out all dynamic buffers.

You cannot mix PTR + LONG args without serious compile-time errors

Re: Some Were Meant for C: The Endurance of an Unmanageable Language [pdf]

#250

Post by pjmlp »

rurban wrote: post #249
pjmlp wrote: post #243

Earlier quoted context omitted.

Annex K is not safe, just pretends to be. By tracking the pointer and sizes as separate function arguments, the possibility of mixing parameters, leading to memory corruption is still there. This is the major motivation why almost nobody uses it and it was made into an optional annex.

No. The major motivation not to use it was _FORTIFY_SOURCE with it's compile checks for compile-time known buffer sizes and it's accompanying _chk functions. This leaves out all dynamic buffers. You cannot mix PTR + LONG args without serious compile-time errors

I don't have any idea how _FORTIFY_SOURCE works, other than it is GCC specific and as such no place in ANSI C.

What I know is that having something like strcpy_s() does not provide any actual safety, because with the prototype "strcpy_s(char * restrict s1, rsize_t s1max, const char * restrict s2)" there is no guarantee that s1max is a valid size for s1.

Post reply on HN