Personal computing discussed

Moderators: SecretSquirrel, just brew it!

 
just brew it!
Gold subscriber
Administrator
Topic Author
Posts: 51967
Joined: Tue Aug 20, 2002 10:51 pm
Location: Somewhere, having a beer

C Code Perfect Storm of Stupid

Thu Jan 18, 2018 12:16 pm

...or Another Day in the Trenches Debugging Someone Else's Code

Symptom:

Process occasionally dies with segfaults and other random crashes. It's seemingly non-deterministic... completely random.

Analysis:

The ctime() library function (which produces a formatted string from a UNIX time and date value) isn't thread safe -- it uses a static buffer every time it is called. Internally, the ctime() library function pre-initializes its buffer to empty, by writing a null byte at the beginning every time it is called. This byte is there for only a few nanoseconds, since it is then immediately overwritten by the formatted string. But this brief instant where the string is left empty turned out to be the gasoline that some clueless developer set a match to.

The code in question was calling ctime(), taking the strlen() of the result, and copying that many characters minus 1 to another buffer (allocated on the heap), using strncpy(). The "-1" part was to remove the trailing newline that ctime() appends to the string. But this application is multi-threaded! So once in a while, thread 1 would be taking the strlen() of the result of ctime(), just as thread 2 was starting another ctime() conversion... so thread 1 gets a string length of 0, which it then subtracts 1 from, and consequently passes -1 as the length argument to strncpy().

Well, the length argument to strncpy() is unsigned, so -1 wraps around to the largest positive integer. Also, the strncpy() library function null-pads the destination string out to the specified length. Net effect of this bit of stupidity is to zero out all memory from the destination buffer to the end of the heap arena it was allocated from.

Upon hitting the end of the heap arena, thread 1 gets a segfault, causing the process to die. Or maybe it steps on a data pointer which is just about to be used by another thread, causing that thread to segfault first instead. Or maybe some other thread is trying to allocate or deallocate heap memory while this is going on, causing malloc() or free() to throw an assert.

Conclusion:

I hate amateur night multi-threaded C code...
Nostalgia isn't what it used to be.
 
Buub
Maximum Gerbil
Posts: 4801
Joined: Sat Nov 09, 2002 11:59 pm
Location: Seattle, WA
Contact:

Re: C Code Perfect Storm of Stupid

Thu Jan 18, 2018 1:17 pm

Amateur night and multi-threaded are phrases that shouldn't go together in the same sentence.
 
Buub
Maximum Gerbil
Posts: 4801
Joined: Sat Nov 09, 2002 11:59 pm
Location: Seattle, WA
Contact:

Re: C Code Perfect Storm of Stupid

Thu Jan 18, 2018 1:21 pm

I once (like 15 years ago) was using an extensive Python test suite that we used to debug some complex software we were developing. This test software was used by everyone in our office, as well as many people in the parent office in France.

The test suite kept crashing on me randomly, and I'm wondering how anyone can be using this stuff. So I start digging in. Someone had needlessly made the test suite multi-threaded (in Python!!). But it still worked for everyone except me and my team. Turns out, we were the only ones who had a multi-core server to run it on.

I quickly un-threaded the code, since it was crash-prone and completely unnecessary (especially on single-core boxes, which is what almost everyone else was running).
 
UberGerbil
Grand Admiral Gerbil
Posts: 10336
Joined: Thu Jun 19, 2003 3:11 pm

Re: C Code Perfect Storm of Stupid

Thu Jan 18, 2018 2:08 pm

So out of curiosity, what was your chosen solution -- a thread-safe replacement for ctime, or locks around the call? (Of course that's just a question of who is doing the locking, unless you have some MT-aware ctime that does per-caller allocations using eg thread local storage)
Buub wrote:
Amateur night and multi-threaded are phrases that shouldn't go together in the same sentence.
Word
 
just brew it!
Gold subscriber
Administrator
Topic Author
Posts: 51967
Joined: Tue Aug 20, 2002 10:51 pm
Location: Somewhere, having a beer

Re: C Code Perfect Storm of Stupid

Thu Jan 18, 2018 2:19 pm

UberGerbil wrote:
So out of curiosity, what was your chosen solution -- a thread-safe replacement for ctime, or locks around the call?

The runtime library already has a thread-safe version of ctime() -- ctime_r(). So that part was easy. In an extra bit of paranoia defensive coding, the code also now checks that the length of the returned string is non-zero before attempting to trim the trailing newline.

Figuring out what happened from the core dump file was interesting, given that the explosion (in the "run off the end of the heap" segfault case) ultimately occurred in a hand-optimized SSE assembly code version of the strncpy() library function, and the length argument to strncpy() was "optimized out" according to gdb (which I assume means it was passed directly from/in a CPU register instead of a memory-based variable). So I had to familiarize myself with a subset of x86-64 assembly language to figure out WTF was going on. Adding even further to the confusion, by the time the segfault actually occurred, the contents of the ctime() buffer contained a valid (non-zero length) time string...

I did a lot of x86 assembly coding back in the 16-bit days, but haven't touched it much since before the release of the original Pentium. "WTF are all these extra registers about, anyway?"
Nostalgia isn't what it used to be.
 
Waco
Gold subscriber
Minister of Gerbil Affairs
Posts: 2585
Joined: Tue Jan 20, 2009 4:14 pm
Location: Los Alamos, NM

Re: C Code Perfect Storm of Stupid

Thu Jan 18, 2018 2:49 pm

Once upon a time I had faith that all developers at least gave their application a cursory run through helgrind prior to deploying anything.

I've since lost all that faith and have some active malice towards uncareful programmers. :P

EDIT: It's now my first path to fixing things multithreaded.
Desktop: Z170A Gaming Pro Carbon | 6700K @ 4.4 | 16 GB | GTX Titan Xm | XSPC RX360 | Heatkiller R3 | Samsung 4K 40" | 2048 + 240 + LSI 9207-8i (128x8) SSD
NAS: 1950X | Designare EX | 32 GB ECC | 7x8 TB RAIDZ2 | 8x2 TB RAID10 | FreeNAS | ZFS | LSI SAS
 
just brew it!
Gold subscriber
Administrator
Topic Author
Posts: 51967
Joined: Tue Aug 20, 2002 10:51 pm
Location: Somewhere, having a beer

Re: C Code Perfect Storm of Stupid

Thu Jan 18, 2018 2:58 pm

Waco wrote:
Once upon a time I had faith that all developers at least gave their application a cursory run through helgrind prior to deploying anything.

Working in the industry for 30+ years will convince you beyond a shadow of a doubt that at least 50% of software developers don't have a f*cking clue what they are doing.
Nostalgia isn't what it used to be.
 
Waco
Gold subscriber
Minister of Gerbil Affairs
Posts: 2585
Joined: Tue Jan 20, 2009 4:14 pm
Location: Los Alamos, NM

Re: C Code Perfect Storm of Stupid

Thu Jan 18, 2018 3:02 pm

just brew it! wrote:
Waco wrote:
Once upon a time I had faith that all developers at least gave their application a cursory run through helgrind prior to deploying anything.

Working in the industry for 30+ years will convince you beyond a shadow of a doubt that at least 50% of software developers don't have a f*cking clue what they are doing.

I've been in it for just over a decade now...and I'm pretty sure it's closer to 95%. :lol:

On one hand, finding C developers these days is difficult. On the other, they tend to be self motivated and good at what they do (since it's no longer taught in many many CompSci programs). Memory and thread management is a foreign concept to all too many "developers".
Desktop: Z170A Gaming Pro Carbon | 6700K @ 4.4 | 16 GB | GTX Titan Xm | XSPC RX360 | Heatkiller R3 | Samsung 4K 40" | 2048 + 240 + LSI 9207-8i (128x8) SSD
NAS: 1950X | Designare EX | 32 GB ECC | 7x8 TB RAIDZ2 | 8x2 TB RAID10 | FreeNAS | ZFS | LSI SAS
 
just brew it!
Gold subscriber
Administrator
Topic Author
Posts: 51967
Joined: Tue Aug 20, 2002 10:51 pm
Location: Somewhere, having a beer

Re: C Code Perfect Storm of Stupid

Thu Jan 18, 2018 3:14 pm

Waco wrote:
just brew it! wrote:
Working in the industry for 30+ years will convince you beyond a shadow of a doubt that at least 50% of software developers don't have a f*cking clue what they are doing.

I've been in it for just over a decade now...and I'm pretty sure it's closer to 95%. :lol:

It varies somewhat by industry and company size. I think truly clueless people tend not to survive long at smaller companies (your individual contribution, or lack thereof, is more visible), or in development organizations that must produce high-quality code out of necessity (e.g. systems which can affect physical safety, like avionics).

Waco wrote:
On one hand, finding C developers these days is difficult. On the other, they tend to be self motivated and good at what they do (since it's no longer taught in many many CompSci programs).

A lot of them tend to be older too. I think there will be a pretty severe shortage a few years down the road as more of my cohort starts hitting retirement age.

Waco wrote:
Memory and thread management is a foreign concept to all too many "developers".

While being blissfully unaware of what's going on under the hood is fine in many cases, and can free the developer up to focus on high-level algorithms, I do think we've gone too far in that direction with our CompSci programs. Devs need to be at least somewhat aware of the implications (CPU cycles, memory usage, I/O load...) of doing something a certain way, or using a certain language. E.g., if you try to write a real-time system in Java, you're gonna get burned when the GC comes around and causes everything to hiccup.
Nostalgia isn't what it used to be.
 
Waco
Gold subscriber
Minister of Gerbil Affairs
Posts: 2585
Joined: Tue Jan 20, 2009 4:14 pm
Location: Los Alamos, NM

Re: C Code Perfect Storm of Stupid

Thu Jan 18, 2018 3:48 pm

just brew it! wrote:
...if you try to write a real-time system in Java

:lol: Thanks for making me nearly spit coffee at my monitor.
Desktop: Z170A Gaming Pro Carbon | 6700K @ 4.4 | 16 GB | GTX Titan Xm | XSPC RX360 | Heatkiller R3 | Samsung 4K 40" | 2048 + 240 + LSI 9207-8i (128x8) SSD
NAS: 1950X | Designare EX | 32 GB ECC | 7x8 TB RAIDZ2 | 8x2 TB RAID10 | FreeNAS | ZFS | LSI SAS
 
DragonDaddyBear
Gerbil Elite
Posts: 789
Joined: Fri Jan 30, 2009 8:01 am

Re: C Code Perfect Storm of Stupid

Thu Jan 18, 2018 4:17 pm

This thread makes me appreciate you C-types even more. I wanted to get into programming and I didn't because every degree program I could find wanted 1) lots of calculus and 2) Java or some other higher-level language focus. I wanted to actually get into a program where I learned the CPU, assembly, etc. To be fair, I didn't look all that hard. But, while i was OK at math back in the day, I don't feel like relearning a bunch to do calc just to have a piece of paper that says I can write code.
 
chuckula
Gold subscriber
Gerbil Jedi
Posts: 1890
Joined: Wed Jan 23, 2008 9:18 pm
Location: Probably where I don't belong.

Re: C Code Perfect Storm of Stupid

Thu Jan 18, 2018 4:49 pm

In the developer's defense, it would be nice if the C API didn't require you to select different functions to perform the same operation based solely on thread safety or lack thereof.

The glibc documentation only refers to the thread-safety difference between the two functions in a flag: https://www.gnu.org/software/libc/manual/pdf/libc.pdf

Did this guy know he was writing multi-threaded code from the outset and blindly ignore thread safety or was this some old code that got copied in without being rewritten?
4770K @ 4.7 GHz; 32GB DDR3-2133; GTX-1080 sold and back to hipster IGP!; 512GB 840 Pro (2x); Fractal Define XL-R2; NZXT Kraken-X60
--Many thanks to the TR Forum for advice in getting it built.
 
just brew it!
Gold subscriber
Administrator
Topic Author
Posts: 51967
Joined: Tue Aug 20, 2002 10:51 pm
Location: Somewhere, having a beer

Re: C Code Perfect Storm of Stupid

Thu Jan 18, 2018 5:13 pm

Waco wrote:
just brew it! wrote:
...if you try to write a real-time system in Java

:lol: Thanks for making me nearly spit coffee at my monitor.

I've seen it. People are doing it. No joke. At least we were talking "soft" real-time, where the worst that happens when things go south is people get annoyed because the system hiccuped. No planes falling out of the sky or anything drastic like that.

People tend to use the language they know, even if it isn't the best fit. It's the old "If all you have is a hammer, everything looks like a nail" thing.

chuckula wrote:
In the developer's defense, it would be nice if the C API didn't require you to select different functions to perform the same operation based solely on thread safety or lack thereof.

The glibc documentation only refers to the thread-safety difference between the two functions in a flag: https://www.gnu.org/software/libc/manual/pdf/libc.pdf

The ctime() function really ought to be deprecated. It dates back to the Dark Ages, before multiple cores and multi-threading were a thing, and there's absolutely no justification for using it any more (other than maybe if you're running on a low-end microcontroller with very limited RAM, and allocating another 25 byte buffer puts you over the edge). The Linux man page for it is more explicit about the thread (un)safety issue:
The four functions asctime(), ctime(), gmtime() and localtime() return a pointer to static data and hence are not thread-safe. Thread-safe versions asctime_r(), ctime_r(), gmtime_r() and localtime_r() are specified by SUSv2, and available since libc 5.2.5.

chuckula wrote:
Did this guy know he was writing multi-threaded code from the outset and blindly ignore thread safety or was this some old code that got copied in without being rewritten?

Pretty sure the application was multi-threaded from the get-go, and it was a simple case of not knowing any better. There was also code in the same module which was attempting to clear a buffer (the address of which had been passed in as a pointer) by doing a "memset(buffer, 0, sizeof(buffer));"... anyone whose done much C programming knows that sizeof(buffer) in this case would be the size of the pointer, not the size of the thing it points to. IOW, this is just going to clear the first 8 bytes of the buffer (on a 64-bit CPU).
Nostalgia isn't what it used to be.
 
Waco
Gold subscriber
Minister of Gerbil Affairs
Posts: 2585
Joined: Tue Jan 20, 2009 4:14 pm
Location: Los Alamos, NM

Re: C Code Perfect Storm of Stupid

Thu Jan 18, 2018 5:31 pm

just brew it! wrote:
There was also code in the same module which was attempting to clear a buffer (the address of which had been passed in as a pointer) by doing a "memset(buffer, 0, sizeof(buffer));"... anyone whose done much C programming knows that sizeof(buffer) in this case would be the size of the pointer, not the size of the thing it points to. IOW, this is just going to clear the first 8 bytes of the buffer (on a 64-bit CPU).

Which would have a happy side effect of reporting strlen(buffer) == 0, which is probably why he missed it. :lol:
Desktop: Z170A Gaming Pro Carbon | 6700K @ 4.4 | 16 GB | GTX Titan Xm | XSPC RX360 | Heatkiller R3 | Samsung 4K 40" | 2048 + 240 + LSI 9207-8i (128x8) SSD
NAS: 1950X | Designare EX | 32 GB ECC | 7x8 TB RAIDZ2 | 8x2 TB RAID10 | FreeNAS | ZFS | LSI SAS
 
SecretSquirrel
Minister of Gerbil Affairs
Posts: 2481
Joined: Tue Jan 01, 2002 7:00 pm
Location: North DFW suburb...
Contact:

Re: C Code Perfect Storm of Stupid

Thu Jan 18, 2018 8:21 pm

just brew it! wrote:
Waco wrote:
On one hand, finding C developers these days is difficult. On the other, they tend to be self motivated and good at what they do (since it's no longer taught in many many CompSci programs).

A lot of them tend to be older too. I think there will be a pretty severe shortage a few years down the road as more of my cohort starts hitting retirement age.


I'm kinda looking forward to it, being one of them there "C" programmers. Should nicely fund my "retirement". :lol:
 
SecretSquirrel
Minister of Gerbil Affairs
Posts: 2481
Joined: Tue Jan 01, 2002 7:00 pm
Location: North DFW suburb...
Contact:

Re: C Code Perfect Storm of Stupid

Thu Jan 18, 2018 8:23 pm

DragonDaddyBear wrote:
This thread makes me appreciate you C-types even more. I wanted to get into programming and I didn't because every degree program I could find wanted 1) lots of calculus and 2) Java or some other higher-level language focus. I wanted to actually get into a program where I learned the CPU, assembly, etc. To be fair, I didn't look all that hard. But, while i was OK at math back in the day, I don't feel like relearning a bunch to do calc just to have a piece of paper that says I can write code.


Look for a Computer Engineering program, if you can find one. It won't get you out of the Calculus, but they tend to focus more on the low levels of computers. The trick is to find one that isn't just a renamed CompSci program or a renamed EE program.

--SS
 
Waco
Gold subscriber
Minister of Gerbil Affairs
Posts: 2585
Joined: Tue Jan 20, 2009 4:14 pm
Location: Los Alamos, NM

Re: C Code Perfect Storm of Stupid

Thu Jan 18, 2018 8:41 pm

SecretSquirrel wrote:
DragonDaddyBear wrote:
This thread makes me appreciate you C-types even more. I wanted to get into programming and I didn't because every degree program I could find wanted 1) lots of calculus and 2) Java or some other higher-level language focus. I wanted to actually get into a program where I learned the CPU, assembly, etc. To be fair, I didn't look all that hard. But, while i was OK at math back in the day, I don't feel like relearning a bunch to do calc just to have a piece of paper that says I can write code.


Look for a Computer Engineering program, if you can find one. It won't get you out of the Calculus, but they tend to focus more on the low levels of computers. The trick is to find one that isn't just a renamed CompSci program or a renamed EE program.

--SS

I can vouch for Clemson's CompE program. It's not short on the math (and lots of it) but you'll walk away with a skillset that few can boast right out of school.
Desktop: Z170A Gaming Pro Carbon | 6700K @ 4.4 | 16 GB | GTX Titan Xm | XSPC RX360 | Heatkiller R3 | Samsung 4K 40" | 2048 + 240 + LSI 9207-8i (128x8) SSD
NAS: 1950X | Designare EX | 32 GB ECC | 7x8 TB RAIDZ2 | 8x2 TB RAID10 | FreeNAS | ZFS | LSI SAS
 
DragonDaddyBear
Gerbil Elite
Posts: 789
Joined: Fri Jan 30, 2009 8:01 am

Re: C Code Perfect Storm of Stupid

Thu Jan 18, 2018 9:52 pm

Thanks for the advice. Unfortunately it's a rather difficult time for me to make a career change. Maybe in 10 years when my oldest is ready to start college. Maybe she'll do a computer engineering program with me!
 
FlamingSpaceJunk
Gerbil
Posts: 40
Joined: Thu Nov 09, 2017 4:21 pm

Re: C Code Perfect Storm of Stupid

Thu Jan 18, 2018 10:43 pm

SecretSquirrel wrote:
Look for a Computer Engineering program, if you can find one. It won't get you out of the Calculus, but they tend to focus more on the low levels of computers. The trick is to find one that isn't just a renamed CompSci program or a renamed EE program.


I usually tell people to get an EE if they want to get into the guts of electronics. There are EE jobs all over the place out there.

SecretSquirrel wrote:
I'm kinda looking forward to it, being one of them there "C" programmers. Should nicely fund my "retirement". :lol:


I had the same thought about Cobol.
 
just brew it!
Gold subscriber
Administrator
Topic Author
Posts: 51967
Joined: Tue Aug 20, 2002 10:51 pm
Location: Somewhere, having a beer

Re: C Code Perfect Storm of Stupid

Fri Jan 19, 2018 8:28 am

FlamingSpaceJunk wrote:
SecretSquirrel wrote:
Look for a Computer Engineering program, if you can find one. It won't get you out of the Calculus, but they tend to focus more on the low levels of computers. The trick is to find one that isn't just a renamed CompSci program or a renamed EE program.

I usually tell people to get an EE if they want to get into the guts of electronics. There are EE jobs all over the place out there.

When I went to school I couldn't decide between CS, CE, or EE. I chose what was perhaps the least optimal solution, namely: Major in CS, but take some EE courses too. The EE courses were a bitch, made even worse by the fact that I had taken the CS department's "equivalents" of the prerequisites, not the actual EE prerequisites. If I had to do it again, I'd probably just major in CE.

FlamingSpaceJunk wrote:
SecretSquirrel wrote:
I'm kinda looking forward to it, being one of them there "C" programmers. Should nicely fund my "retirement". :lol:

I had the same thought about Cobol.

There's still demand in some industries. Some CS programs still teach it too.

TBH I was a little surprised at C's longevity, but nothing viable has come along to replace it yet for low-level systems work.
Nostalgia isn't what it used to be.
 
DragonDaddyBear
Gerbil Elite
Posts: 789
Joined: Fri Jan 30, 2009 8:01 am

Re: C Code Perfect Storm of Stupid

Fri Jan 19, 2018 8:39 am

Is the Linux kernel not written in C? That would be one reason it's still around. Lots of active development going on there.
 
notfred
Maximum Gerbil
Posts: 4527
Joined: Tue Aug 10, 2004 10:10 am
Location: Ottawa, Canada

Re: C Code Perfect Storm of Stupid

Fri Jan 19, 2018 8:41 am

Not just the Linux kernel, most kernels are in C.
 
just brew it!
Gold subscriber
Administrator
Topic Author
Posts: 51967
Joined: Tue Aug 20, 2002 10:51 pm
Location: Somewhere, having a beer

Re: C Code Perfect Storm of Stupid

Fri Jan 19, 2018 9:14 am

CPUs have gotten fast enough, and compilers good enough, that there is rarely a need to do anything in assembly language any more. C is used pretty much everywhere that assembly language would've been used "back in the day" -- OS kernels, device drivers, embedded systems, real-time.

The rare exceptions where assembly is still used are things like the optimized strncpy() I mentioned a few posts back. A frequently used library function like that can have a big effect on application performance, so it is worthwhile to provide code paths which are hand-optimized for specific instruction sets.

In hindsight, the secret to its continued success is the fact that it provides enough abstraction to be portable across architectures (if you code carefully), but still allows direct access to the hardware. In effect, it is almost a "high level assembly language". :wink:
Nostalgia isn't what it used to be.
 
chuckula
Gold subscriber
Gerbil Jedi
Posts: 1890
Joined: Wed Jan 23, 2008 9:18 pm
Location: Probably where I don't belong.

Re: C Code Perfect Storm of Stupid

Fri Jan 19, 2018 9:37 am

just brew it! wrote:
CPUs have gotten fast enough, and compilers good enough, that there is rarely a need to do anything in assembly language any more. C is used pretty much everywhere that assembly language would've been used "back in the day" -- OS kernels, device drivers, embedded systems, real-time.

The rare exceptions where assembly is still used are things like the optimized strncpy() I mentioned a few posts back. A frequently used library function like that can have a big effect on application performance, so it is worthwhile to provide code paths which are hand-optimized for specific instruction sets.

In hindsight, the secret to its continued success is the fact that it provides enough abstraction to be portable across architectures (if you code carefully), but still allows direct access to the hardware. In effect, it is almost a "high level assembly language". :wink:


In fact, hand-optimized assembly can be good for a while, but then might not perform as well over time as the CPU architectures change.
Case in point: recent optimization work in glibc that improves performance noticeably by moving away from old hand-optimized assembly that was good on old CPUs but doesn't translate to modern (and by "modern" I mean Sandy Bridge even) processors: https://www.phoronix.com/scan.php?page= ... -POWF-LOGF
4770K @ 4.7 GHz; 32GB DDR3-2133; GTX-1080 sold and back to hipster IGP!; 512GB 840 Pro (2x); Fractal Define XL-R2; NZXT Kraken-X60
--Many thanks to the TR Forum for advice in getting it built.
 
just brew it!
Gold subscriber
Administrator
Topic Author
Posts: 51967
Joined: Tue Aug 20, 2002 10:51 pm
Location: Somewhere, having a beer

Re: C Code Perfect Storm of Stupid

Fri Jan 19, 2018 9:52 am

chuckula wrote:
In fact, hand-optimized assembly can be good for a while, but then might not perform as well over time as the CPU architectures change.
Case in point: recent optimization work in glibc that improves performance noticeably by moving away from old hand-optimized assembly that was good on old CPUs but doesn't translate to modern (and by "modern" I mean Sandy Bridge even) processors: https://www.phoronix.com/scan.php?page= ... -POWF-LOGF

Yeah, that's not surprising, especially in the area of floating point computation. Sophistication of the FPUs has increased many-fold since the early x86 days. A hypothetical (extreme) example: performance of hand-optimized x87 assembly code would likely be blown away by a compiled (from C or other high-level language) version of the same calculation that is allowed to leverage modern FPU implementations.
Nostalgia isn't what it used to be.
 
Buub
Maximum Gerbil
Posts: 4801
Joined: Sat Nov 09, 2002 11:59 pm
Location: Seattle, WA
Contact:

Re: C Code Perfect Storm of Stupid

Fri Jan 19, 2018 11:39 am

chuckula wrote:
In the developer's defense, it would be nice if the C API didn't require you to select different functions to perform the same operation based solely on thread safety or lack thereof.

The C community is loathe to change the way things have always been.

The APIs, IMHO, are much more sane in C++, at least from this perspective. I'm not sure anyone willingly gets into templates, but at least they're logically consistent and can largely be approached from a consumption-only basis unless you're writing APIs or libraries.
 
Buub
Maximum Gerbil
Posts: 4801
Joined: Sat Nov 09, 2002 11:59 pm
Location: Seattle, WA
Contact:

Re: C Code Perfect Storm of Stupid

Fri Jan 19, 2018 11:42 am

notfred wrote:
Not just the Linux kernel, most kernels are in C.

For what it's worth, the Windows kernel is actively moving to C++. But yes, most kernels are still C.
 
Buub
Maximum Gerbil
Posts: 4801
Joined: Sat Nov 09, 2002 11:59 pm
Location: Seattle, WA
Contact:

Re: C Code Perfect Storm of Stupid

Fri Jan 19, 2018 11:45 am

chuckula wrote:
just brew it! wrote:
CPUs have gotten fast enough, and compilers good enough, that there is rarely a need to do anything in assembly language any more. C is used pretty much everywhere that assembly language would've been used "back in the day" -- OS kernels, device drivers, embedded systems, real-time.

The rare exceptions where assembly is still used are things like the optimized strncpy() I mentioned a few posts back. A frequently used library function like that can have a big effect on application performance, so it is worthwhile to provide code paths which are hand-optimized for specific instruction sets.

If you want to see just how insanely good optimizers have become in modern compilers, watch this video:
https://channel9.msdn.com/Events/GoingN ... n-2017/005
 
just brew it!
Gold subscriber
Administrator
Topic Author
Posts: 51967
Joined: Tue Aug 20, 2002 10:51 pm
Location: Somewhere, having a beer

Re: C Code Perfect Storm of Stupid

Fri Jan 19, 2018 12:11 pm

Buub wrote:
chuckula wrote:
In the developer's defense, it would be nice if the C API didn't require you to select different functions to perform the same operation based solely on thread safety or lack thereof.

The C community is loathe to change the way things have always been.

The APIs, IMHO, are much more sane in C++, at least from this perspective. I'm not sure anyone willingly gets into templates, but at least they're logically consistent and can largely be approached from a consumption-only basis unless you're writing APIs or libraries.

The Boost library and C++11 (and later) rely very heavily on templates for the newer language features. It's really powerful stuff (and I'm still trying to wrap my head around it). C++11 code that takes full advantage of the new language features doesn't even look like "classic" C++ code any more; it is effectively a new language which just happens to be backward-compatible.
Nostalgia isn't what it used to be.
 
chuckula
Gold subscriber
Gerbil Jedi
Posts: 1890
Joined: Wed Jan 23, 2008 9:18 pm
Location: Probably where I don't belong.

Re: C Code Perfect Storm of Stupid

Fri Jan 19, 2018 12:19 pm

just brew it! wrote:
Buub wrote:
chuckula wrote:
In the developer's defense, it would be nice if the C API didn't require you to select different functions to perform the same operation based solely on thread safety or lack thereof.

The C community is loathe to change the way things have always been.

The APIs, IMHO, are much more sane in C++, at least from this perspective. I'm not sure anyone willingly gets into templates, but at least they're logically consistent and can largely be approached from a consumption-only basis unless you're writing APIs or libraries.

The Boost library and C++11 (and later) rely very heavily on templates for the newer language features. It's really powerful stuff (and I'm still trying to wrap my head around it). C++11 code that takes full advantage of the new language features doesn't even look like "classic" C++ code any more; it is effectively a new language which just happens to be backward-compatible.


With the way C++ handles types, you really need templates to re-use any sort of generic data containers or other APIs that aren't directly tied to inputting and outputting very specific data structures. Of course the STL and Boost are big examples of APIs that provide containers & services to a wide range of program that will be using different data types where templates are a must in C++. Having said that, C++ gurus could tell me what the state of "generics" in C++ is since I know the basics but I don't keep up with all the newest features of the newest language revisions.
4770K @ 4.7 GHz; 32GB DDR3-2133; GTX-1080 sold and back to hipster IGP!; 512GB 840 Pro (2x); Fractal Define XL-R2; NZXT Kraken-X60
--Many thanks to the TR Forum for advice in getting it built.

Who is online

Users browsing this forum: No registered users and 1 guest