Way before QNX went shared/open source, they were as they are now. But they had just released Neutrino a major update which basically took their QNX4 microkernel and mated it with a POSIX/GNU/UNIX-like userland. And it was for a while, free as in beer, for R&D type use.
So that all sounded great and we tried it, this was around 20 years ago. It was a disaster.
The same kind of shoddy work, race-condition, type bugs all over the place.
- malloc broken under heavy multi-threaded load. Replaced with dl-malloc.
- serial driver (16550) broke under heavy load. Wrote our own replacement.
- ethernet driver broke under heavy load. Had to replace intel cards with 3-com (or vice-versa) to use a different driver.
- had to write/rewrite several other drivers. Interestingly the only think I liked about QNX is that user mode drivers are very nice and easy to write.
- compiler, QNX bespoke port of GCC, crashed and broke on large codebases (could be because of malloc). Had to re-port GCC (which was easy) and build our own toolchains.
When we got done trying it our adamant report was GARBAGE NEVER USE. Got overrode by management. because we succeeded in making it work. Sigh. Started using it for products, so we bought commercial not-free license AND support. Reported all of the above bugs and 20 more, with reproducible test cases. QNX "promised to fix them in the next release". This was 20 years ago. Finally after many years we completed excising QNX from our products.
We never had a problem with ps, but it was probably broken. This company was producing garbage in the late nineties and didn't care. They produce garbage now. They didn't have enough or experienced enough developers to be trying to pull together a whole OS, so it was about how you'd expect a university or hobby project.
The only place this author got it wrong is that on QNX, if you assume the OS or compiler is at fault, you are probably right.
Fortran compiler (f77 maybe?) on a Sun system had reserved filenames. In Finland, back in the late 90's first-year chemistry students were still exposed to Fortran as their entry to programming.
I was helping another student debug their programming assignment, which blew up the compiler. Over the shoulder I couldn't figure out what it supposedly wrong, so we copied it (via /scratch) to my home directory. I just shortened the name a bit. Tried to compile on my account, it worked. No errors. Confirmed it was the same compiler being invoked.
So we copied the file to a new name on the other student's account and tried. Worked.
Same file content, two different file names. One compiles fine, another hits internal compiler error paths. Introduction to programming indeed.
No idea, but I do know there was a gcc port to NCR UNIX bootstrapping off their own compiler that stalled for a while until one of the developers worked out that it unrolled switch statements to if+goto ... and used the label 'dflt:' for the default case of the switch.
Sucked to be you if you decided to name one of your own labels that.
Honestly, I'm not sure. In hindsight, I think that there must have been a race condition somewhere else in my code (school project) that this was somehow exposing. Removing the comment reliably resulted in an executable that always did the wrong behavior, and leaving the comment in, the program always worked.
printf() is an old-school fuzzer, so to speak. It may be just a line, but underneath, the call to it brings in a ton of branching and memory alloc and access.
So quite often any latent memory leaks or code issues could lead to such odd behavior. Sometimes it's the opposite - "works" with printf(), but segfaults in some odd place or infiniloops without it.
At times like this, -Wall, valgrind, and critical thinking are the ways to "cherchez le 'bug'"... Multithreaded it is? Good luck!
You don't know what the compiler is doing behind the scenes before it figures out that is a comment. For instance, it might parse the entire function body for printf() and if it finds it then loads some library, only then getting around to actually parsing the function line by line. Think of Javascript hoisting - only dumber.
There was a case, which I cannot find now, where the compiler decided whether the function is small enough to inline based on its source code size, including comments.
So that all sounded great and we tried it, this was around 20 years ago. It was a disaster.
The same kind of shoddy work, race-condition, type bugs all over the place.
- malloc broken under heavy multi-threaded load. Replaced with dl-malloc.
- serial driver (16550) broke under heavy load. Wrote our own replacement.
- ethernet driver broke under heavy load. Had to replace intel cards with 3-com (or vice-versa) to use a different driver.
- had to write/rewrite several other drivers. Interestingly the only think I liked about QNX is that user mode drivers are very nice and easy to write.
- compiler, QNX bespoke port of GCC, crashed and broke on large codebases (could be because of malloc). Had to re-port GCC (which was easy) and build our own toolchains.
When we got done trying it our adamant report was GARBAGE NEVER USE. Got overrode by management. because we succeeded in making it work. Sigh. Started using it for products, so we bought commercial not-free license AND support. Reported all of the above bugs and 20 more, with reproducible test cases. QNX "promised to fix them in the next release". This was 20 years ago. Finally after many years we completed excising QNX from our products.
We never had a problem with ps, but it was probably broken. This company was producing garbage in the late nineties and didn't care. They produce garbage now. They didn't have enough or experienced enough developers to be trying to pull together a whole OS, so it was about how you'd expect a university or hobby project.
The only place this author got it wrong is that on QNX, if you assume the OS or compiler is at fault, you are probably right.