Since the article was written, the maintainers fixed the issues I pointed out. No need for many of those workarounds now. Versions 3.4.0 and 3.4.1 are substantial.
I see CMSIS definitions for the RP2040 at https://github.com/raspberrypi/CMSIS-RP2xxx-DFP but none for RP2350. Maybe they'll eventually appear in that repo, given its name is RP2xxx? I thought vendors are legally obligated to provide CMSIS definitions when they license an ARM core.
I have a hard-copy of this book, and it seems like the PDF isn't the final version, judging by the hand drawn illustrations at least.
The book does dive into some old and arcane object file formats, but that's interesting in its own way. Nice to get a comparison of how different systems did things.
After reading that book and other sources, I examined how people typically create libraries in the UNIX/Linux world. Some of the common practices seem to be lacking, so I wrote an article about how they might be improved: https://begriffs.com/posts/2021-07-04-shared-libraries.html
Edit: That covers the dynamic linking side of things at least.
Interesting, maybe it depends on the reader. I tried a channel just now in newsboat and it wasn't smart enough to find the feed, even though I see the page contains
I still follow many RSS feeds (about 250). Sometimes it's hard to find the feed on a site, because the feeds aren't always advertised and their URLs can be tricky. Based on the URLs I've seen, I created a simple script to check if a site has a feed:
As I got more into C programming, I started looking for data structure libraries. Found a few [0]. Also evaluated sc, but it had too much pre-processor magic for my taste. It also bundles random "stuff" like a URI parser, a thread abstraction, etc.
Eventually I rolled my own [1] more focused library. It's basic and portable.
However, I tried your suggestion from another terminal, and gdb appears to shield the program somehow. What ended up working is running "signal SIGABRT" from within gdb.
One thing that's still lacking is gcore's ability to take a snapshot of the core without killing the program. "Unlike after a crash, after gcore finishes its job the program remains running without any change."
https://www.man7.org/linux/man-pages/man1/gcore.1.html
By this, are you referring to the behavior: "By default, this memory image is written to a file named programname.core in the working directory, provided the terminated process had write permission in the directory[...]" (from
https://man.openbsd.org/core.5) ?
Also, do you know if there's a way to obtain a core file from a running process on OpenBSD? I don't see a port of gcore, and (e)gdb on OpenBSD doesn't support the generate-core-file command (it says, "Can't create a corefile").
> Look at your program's CPU usage. If the sum of your threads is <100% of one core, then there is no reason whatsoever for you to use threads.
Attacking a CPU-bound problem with parallelism is only one reason for using threads. Concurrency (even on one processor) has benefits.
> The shame is in believing ourselves super-human, and reaching for a tool that we don't need, in full knowledge that we're likely to shoot ourselves in the foot with it.
Although synchronization primitives require care, they're not that hard. You don't need super-human powers.
I took some time to understand pthreads and apply them to example programs. For a careful and balanced overview, see my article:
As you mention, the fundamental integer types have guaranteed minimum sizes (or pedantically a range that matches the following sizes if twos' complement is used):
* >=8 bits: char (CHAR_BIT is exactly 8 in POSIX)
* >=16 bits: short and int
* >=32 bits: long
* >=64 bits: long long
The C99 typedefs like uint16_t have to be chosen internally to be one of the underlying types. For those sizes that have no matching underlying type, the implementation will omit typedefs.
However don't forget the more flexible C99 typedefs int_leastN_t and int_fastN_t. They both will give you a type of at least N bits, where the "fast" one chooses whichever type is most convenient for the processor, and the "least" version picks whichever is smallest. (For instance int_least16_t is probably short, and int_fast16_t is probably int.)
Has there been a survey to determine what percentage of known compilers support each C version, like C89, C99, C11? I've been sticking to C99 because I assumed later versions won't be widely adopted for a long time to come. Is this accurate?
https://github.com/begriffs/findrss
The combinations came from what I observed in the big list of blogs I follow. The script works pretty well for most sites.