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

Into the Depths of C: Elaborating the De Facto Standards [pdf]

cl.cam.ac.uk

Post reply on HN
Print view View original

31–39 of 39 posts

Re: Into the Depths of C: Elaborating the De Facto Standards [pdf]

#31

Post by pjmlp »

anexprogrammer wrote: post #28
pjmlp wrote: post #26

Earlier quoted context omitted.

On MS-DOS, Acorn, Amiga and Atari it was just yet another one. On Mac OS (after the C transition), Windows and OS/2, they might had C as main implementation, but most of us that couldn't carry on using Turbo/Quick/HiSoft Pascal, Modula-2 or Basic compilers, moved to C++ instead. We could still make us of improved safety and stronger type checking features, while being compatible with the C toolchains. EDIT: Also IBM…

On Amiga it was the only one of significance, as the API language. Having Lattice helped of course. Pretty much everything else was a toy in the early years. Most significant DOS development seemed to be C.

On Amiga, on my part of the globe we only cared about Assembly, AMOS and GFA Basic. The OS was a mix of Assembly, BCPL and C.

On MS-DOS, on my part of the globe we only cared about Assembly, Turbo Pascal, Turbo Basic, Turbo C, Turbo C++ and Clipper.

C was hardly the only choice on MS-DOS.

All our stuff on demoscene related activities and game programming attempts were in Assembly and Turbo Pascal.

Re: Into the Depths of C: Elaborating the De Facto Standards [pdf]

#32

Post by pcwalton »

gpderetta wrote: post #29
pcwalton wrote: post #10

Earlier quoted context omitted.

Undefined behavior in the form of memory safety issues is a problem in day-to-day work.

UB and memory safety are a big issue exactly because they are not a problem in day to day work. I literally can't remember the last time I had spent any significant time investigating one of these issues. In my experience when that a crash happen (usually in a unit test or the first time you start the app) because of these issues, the backtrace points you to the exact problem. The pain start when the program and test…

> What I'm trying to say is that I don't want memory safety because it would improve my daily programming experience (in fact possibly the reverse would be true)

I think you underestimate how much time is saved by not having to deal with these issues. Programming in C or C++ is frequently an exercise in writing the code, seeing a crash due to a memory safety problem, debugging it, and then repeating until you see anything resembling a working program. Writing in a memory-safe language lets you skip all that startup friction and go straight to "something resembling a working program".

Re: Into the Depths of C: Elaborating the De Facto Standards [pdf]

#33

Post by anexprogrammer »

pjmlp wrote: post #31
anexprogrammer wrote: post #28

Earlier quoted context omitted.

On Amiga it was the only one of significance, as the API language. Having Lattice helped of course. Pretty much everything else was a toy in the early years. Most significant DOS development seemed to be C.

On Amiga, on my part of the globe we only cared about Assembly, AMOS and GFA Basic. The OS was a mix of Assembly, BCPL and C. On MS-DOS, on my part of the globe we only cared about Assembly, Turbo Pascal, Turbo Basic, Turbo C, Turbo C++ and Clipper. C was hardly the only choice on MS-DOS. All our stuff on demoscene related activities and game programming attempts were in Assembly and Turbo Pascal.

Intuition was all C, only DOS was BCPL, which made it a pain to do anything with. AMOS was one of the toys I mention - mainly popular for hobbyists and some bad released games (it never interfaced with the OS, being ST derived. That led to its many compatibilty issues). Most games from the houses I knew, or knew people at, were either a mix of C + 680x0 or pure assembly. In commercial software (GUI based) C was the vast majority.

On MSDOS I never said it was the only choice - there were many choices, but most commercial development seemed focussed on C. DB work often ended up on Foxbase or Clipper. Turbo Pascal and C were hugely successful but didn't catch MS C. Somewhat surprising given how slow early MS compilers were.

Of course if you were doing DOS TSRs or games you'd be much more likely to use assembly in the mix.

Re: Into the Depths of C: Elaborating the De Facto Standards [pdf]

#34

Post by pjmlp »

anexprogrammer wrote: post #33
pjmlp wrote: post #31

Earlier quoted context omitted.

On Amiga, on my part of the globe we only cared about Assembly, AMOS and GFA Basic. The OS was a mix of Assembly, BCPL and C. On MS-DOS, on my part of the globe we only cared about Assembly, Turbo Pascal, Turbo Basic, Turbo C, Turbo C++ and Clipper. C was hardly the only choice on MS-DOS. All our stuff on demoscene related activities and game programming attempts were in Assembly and Turbo Pascal.

Intuition was all C, only DOS was BCPL, which made it a pain to do anything with. AMOS was one of the toys I mention - mainly popular for hobbyists and some bad released games (it never interfaced with the OS, being ST derived. That led to its many compatibilty issues). Most games from the houses I knew, or knew people at, were either a mix of C + 680x0 or pure assembly. In commercial software (GUI based) C was the v…

MS C compilers not only were worse than Borland ones, although they were the platform owner, their C compiler was the last MS-DOS C compiler to get a C++ cousin.

Sadly the way Borland managed the company, let to us having to move to VC++ with MFC, instead of BC++ with OWL or C++Builder and VCL.

Only now VC++ is catching up with C++ Builder for UWP apps.

On MS-DOS besides the DB stuff, everyone I knew was either using Assembly, or a mix of Turbo Pascal with inline Assembly.

C and C++ only came into play on last high school year, just before getting into the university, but the majority of us already had almost a decade of coding experience by then.

Re: Into the Depths of C: Elaborating the De Facto Standards [pdf]

#35

Post by anexprogrammer »

pjmlp wrote: post #34
anexprogrammer wrote: post #33

Earlier quoted context omitted.

Intuition was all C, only DOS was BCPL, which made it a pain to do anything with. AMOS was one of the toys I mention - mainly popular for hobbyists and some bad released games (it never interfaced with the OS, being ST derived. That led to its many compatibilty issues). Most games from the houses I knew, or knew people at, were either a mix of C + 680x0 or pure assembly. In commercial software (GUI based) C was the v…

MS C compilers not only were worse than Borland ones, although they were the platform owner, their C compiler was the last MS-DOS C compiler to get a C++ cousin. Sadly the way Borland managed the company, let to us having to move to VC++ with MFC, instead of BC++ with OWL or C++Builder and VCL. Only now VC++ is catching up with C++ Builder for UWP apps. On MS-DOS besides the DB stuff, everyone I knew was either using…

The really sad part is MS licensed Lattice for the first couple of versions of MS C, yet Lattice itself was markedly faster. If I remember right it didn't even come with any debugger though Lattice did (not sure about v1).

I took a real dislike to Windows and MFC and moved back to the Unix side of things, so my Win programming was pleaingly brief. :)

Your experience is almost the inverse of mine - we had a few juniors comng on with Pascal as they'd learnt that in uni, but they were easy to convert to C. Just about everyone I knew in those days were C/nix or C/DOS, with just a few hanging on still trying to make a living on the Amiga - mainly games devs.

Re: Into the Depths of C: Elaborating the De Facto Standards [pdf]

#36

Post by gpderetta »

pcwalton wrote: post #32
gpderetta wrote: post #29

Earlier quoted context omitted.

UB and memory safety are a big issue exactly because they are not a problem in day to day work. I literally can't remember the last time I had spent any significant time investigating one of these issues. In my experience when that a crash happen (usually in a unit test or the first time you start the app) because of these issues, the backtrace points you to the exact problem. The pain start when the program and test…

> What I'm trying to say is that I don't want memory safety because it would improve my daily programming experience (in fact possibly the reverse would be true) I think you underestimate how much time is saved by not having to deal with these issues. Programming in C or C++ is frequently an exercise in writing the code, seeing a crash due to a memory safety problem, debugging it, and then repeating until you see any…

I don't know, I don't think I spend even a couple of hours per month inside a debugger. I doubt my colleagues do either. Usually I write code for 1-2 weeks, then spend one day trying to get it to compile then one or two days debugging it, but most of my debugging sessions is trailing logs and trying to figure out what went wrong with in complex state machines (i.e. the business logic, not the language/infrastructure 'overhead').

Also, many of the data structures I deal with are highly intrusive (as in an object belonging at the same time in multiple containers) and short of full GC I doubt it would be easy to guarantee MS.

Then again, possibly I'm not representative of the typical C++ programmer.

Re: Into the Depths of C: Elaborating the De Facto Standards [pdf]

#37

Post by paxcoder »

pm215 wrote: post #6
paxcoder wrote: post #4

To write portable code, I wouldn't study de-facto definitions of de-jure undefined behavior, except to see if I could cover every possible one and only if all alternatives were inferior.

Indeed not, but enquiring into what the in-the-wild de-facto beliefs about behaviour are might help in deciding what the de-jure rules should be changed to, or what a compiler implementation ought to do if it cares about what it does on the vast mass of code out there that does commit undefined behaviour, wittingly or otherwise...

Undefined behavior has a purpose: Not specifying implementation details makes it easier to write new implementations and for a wider variety of platforms. "De facto standards" take away this freedom, so ideally you'd want to reject reliance on UD, but I see your (second) point about that not always being practical. I guess "be conservative in what you do, be liberal in what you accept from others". Just make sure that your foundations are strong (pun) or the whole house will be an EcmaScript.

Re: Into the Depths of C: Elaborating the De Facto Standards [pdf]

#38

Post by pjmlp »

anexprogrammer wrote: post #35
pjmlp wrote: post #34

Earlier quoted context omitted.

MS C compilers not only were worse than Borland ones, although they were the platform owner, their C compiler was the last MS-DOS C compiler to get a C++ cousin. Sadly the way Borland managed the company, let to us having to move to VC++ with MFC, instead of BC++ with OWL or C++Builder and VCL. Only now VC++ is catching up with C++ Builder for UWP apps. On MS-DOS besides the DB stuff, everyone I knew was either using…

The really sad part is MS licensed Lattice for the first couple of versions of MS C, yet Lattice itself was markedly faster. If I remember right it didn't even come with any debugger though Lattice did (not sure about v1). I took a real dislike to Windows and MFC and moved back to the Unix side of things, so my Win programming was pleaingly brief. :) Your experience is almost the inverse of mine - we had a few junior…

I wasn't aware of the Lattice story, interesting.

Yeah, I guess in the old days before the Internet and with expensive BBS connections, the technology had more silos than nowadays, because it was harder to move masses for any given technology.

Re: Into the Depths of C: Elaborating the De Facto Standards [pdf]

#39

Post by _0ffh »

pcwalton wrote: post #19
Gibbon1 wrote: post #17

Earlier quoted context omitted.

If the compiler writers union decides that the spec allows for 'format hard drive off on signed overflow' we can always change the spec to 'don't format hard drive on signed overflow'

It's not that simple. The compiler writers have caused security issues before in the Linux kernel. And the compiler writers are right : the undefined behavior that they exploit exists for important performance-related reasons.

"...the undefined behavior that they exploit exists for important performance-related reasons..."

That's a good point, but arguably incomplete. It was there, to give the compiler writer leeway to implement the semantic in the way which is natural for the platform. It was not intended to play sophistic tricks on the programmer, in order to gain a few per cent of performance in some benchmark.

Post reply on HN