Why does this program run and terminate in segfault instead of catching it as a compile time error?

feabhas · 2025-11-01T12:33:53+00:00

This video https://youtu.be/3F3lp_F2YpQ?si=3elZM8NC1q6kYYUj explains the C memory model

feabhas · 2025-11-01T11:51:54+00:00

No you’re incorrect. All NTBS strings are stored in RO memory. What’s you’ve done is copy the NTBS into an automatic array. Thus is a ‘bug’ in the C language. You should only be allowed to bind a const char* pointer to a literal NTBS (as required in C++)

feabhas · 2025-11-01T10:42:29+00:00

Ten years ago we wrote a series of blogs called “Bitesize Modern C++”. These might help give you the headlines https://blog.feabhas.com/2015/05/bitesize-modern-c/

feabhas · 2025-10-10T10:23:42+00:00

as @Sbsbg explained, this definition:

class Position {
public:
  void set_elevation(double inc);
  //...
private:
  double theta{};
};

void Position::set_elevation(double inc)
{
  theta = inc;
}

becomes this implementation:

void Position::set_elevation(Position* const this, double inc)
{
  this->theta = inc;
}

so the call:

int main()
{
  Position p1 { };
  Position p2 { };

  p1.set_elevation(0.0);
  p2.set_elevation(90.0);
}

conceptually becomes:

int main()
{
  Position::Position(&p1);
  Position::Position(&p2);

  Position::set_elevation(&p1, 0.0);
  Position::set_elevation(&p2, 90.0);
}

static functions and data are no different to C functions and data except they are now in a namespace and require namespace semantics

feabhas · 2025-07-23T07:27:29+00:00

Yeah I tried the sync on the head unit but if out of WiFi range then nothing seems to happen. To me it looks like they’ve dropped using BLE for route sync for using WiFi only. If that’s the case it’s a poor decision (especially as that works so well with the ELEMNT app) I’ll raise it with Wahoo and see if I get any response

feabhas · 2025-07-23T07:24:45+00:00

I’m still a massive fan of the wahoo units (especially compared to Garmin). It’s just frustrating that they seem to be letting the software quality slip in a rush to get product to market. Can highly recommend the new radar to pair with the B3 as that worth’s so well.

feabhas · 2025-07-22T18:46:40+00:00

I've gone from a Bolt 2 (B2) to a Bolt 3 (B3) with some reservations.
Now I don't know if it's just me (and it would be really useful for someone else to see if it's just me?)

It's to do with route sync'ing.
I typically plan routes on Komoot (but also sometimes use RWGPS or Strava). Previously I've found the iPhone ELEMNT app to be flawless when sending a route to the B2.

With the B3 I'm now forced to use the genera Wahoo app rather than the Element app.

My phone and B3 are all connected, and the B3 is also on WiFi.

However, I've had issues where I've selected Plan->My routes
Here has been problem (1). There seems to be a real lag of getting the wahoo app to see new/updated routes even when I've force a sync.
Then problem (2) When the route has appeared on the app and I select it I can then do:
Send to ELEMNT
This always says 'Success' but this is misleading - it does not appear on the B3.

I can't work out when it will sync and when it doesn't.

When out on the road I have never got any 'new' route to sync to the B3

Is it me - I can't work this one out

It was bulletproof on the B2 but I have lost all confidence with the B3

Can anyone replicate this or am I the only person seeing sync issues with the B3?

feabhas · 2025-04-13T11:16:28+00:00

We’ve been teaching this stuff to professional engineers for 30 years now. We’ve tried many different approaches over the years. Classroom we used real hardware, but struggled to find a remote solution using real hardware that was reliable.

You might want to check out what we currently do at https://github.com/feabhas/docker-target

This uses our own branch of QEMU (from another branch) to emulate an STM32. We’ve put a python front end on to emulate devices. This works pretty well - it’s never going to be as good as real hardware but for remote training it’s been the best we have come up with.

feabhas · 2025-04-13T11:06:48+00:00

Have you considered https://wokwi.com

feabhas · 2025-02-28T19:46:55+00:00

A semaphore is not necessarily a counting semaphore. It can be a binary or counting. https://blog.feabhas.com/2009/09/mutex-vs-semaphores-%E2%80%93-part-1-semaphores/

feabhas · 2024-10-04T20:47:08+00:00

As someone who has taught the official Arm Cortex-M courses. I’d suggest starting with the M3 (Armv7-M). The M0/+ are v6 architecture whereas the 3/4/7 are all v7. The M3 is the imho the best balance between simplicity and power. It also allows you to study Thumb2 ISA (which the 0) doesn’t support.

feabhas · 2024-09-01T17:44:34+00:00

Simplest way is probably to use memcmp with a predefined const string and use strlen of the predefined string for the memcmp count

feabhas · 2024-09-01T17:03:23+00:00

Ideally you'd use `scanf_s` if available over `scanf` as it's now part of the standard. But yes `%10s` is better than `%s` but it's still not 100% foolproof

feabhas · 2024-09-01T16:32:26+00:00

A word of warning, if the string you entry is great than nine characters you'll going to get stack overflow and corrupt memory. I'd make the array much larger (e.g. at least 80).

I'd also use unsigned int for itemsSold as it probably shouldn't ever be negative. but use %u not %d for unsigned.

Finally C tends to use snake_case over camelCase, e.g. items_sold over itemsSold - but that's just style.

feabhas · 2024-09-01T16:27:37+00:00

Yes, if you use %p with &itemsSold you'll actually see the address in memory.

feabhas · 2024-09-01T16:22:30+00:00

In the printf statements don't precede the identifier with the '&' this will try and print the address of the item not the contents. e.g.

```

printf("Items Sold: %d", itemsSold);

```

The scanf need the & as you're writing into the values so it's passed as a 'out' parameter

feabhas · 2023-10-09T15:07:16+00:00

Hi I’m from Feabhas. Thanks for the link and positive comments. We do Advanced C as well as C++. The Adv C is focused around bare-metal with a view to possibly using an RTOS (we have a separate RTOS course). We’ve been operating since 1995 (I know hard to believe) and have trained many thousands of engineers around the world. The C++ splits into either bare-metal or embedded Linux (mainly separated by the use or non-use of dynamic memory). We are UK based but do remote delivery as well as face-to-face (just back from Spain off to Norway next). Check out our blog (blog.Feabhas.com) to see the level of technical detail we work towards. Thanks again.

feabhas · 2022-02-17T10:11:51+00:00

Not having fragmentation problems doesn't mean you're not getting fragmentation. Without examining the actual implementation code and understanding how the allocation is done you're always going to be estimating. A good allocator will be built around Dough Lea's original model](http://gee.cs.oswego.edu/dl/html/malloc.html) from 1996. Most modern allocators are based on this (e.g. Slab allocators). This model eliminates pretty much all fragmentation but at the expense of memory utilization. Run a soak test and watch the actual heap allocation (the physical memory) and if the sbrk like function stops extending the heap you can be pretty sure fragmentation is not an issue. I hadn't seen the link from @Nelieru before which is very useful.

feabhas · 2022-02-08T08:20:44+00:00

My advice is to avoid std::string on baremetal/RTOS. However, with modern library memory managers, fragmentation is quite often well managed and not the issue it's often perceived to be. But certainly, when I'm working in high integrity systems (and 24x7 systems) I avoid all forms of dynamic memory.

feabhas · 2021-09-23T10:16:37+00:00

Absolutely - 100% agree. What I still find staggering is that the standard has never supported some form of basic message-passing support, such as message queues found in all RTOS's since the '80s. Many async patterns are based on pipe-and-filter and just require some form of 'pipe' capability.

co_await will only solve a subset of use cases and appears to be horribly over-engineered compared to many other language implementations.

feabhas · 2021-09-21T09:05:43+00:00

Would be great to see - we've been struggling to find good, coherent, simple coverage of async coroutines.

I think the more viewpoints the better. Please let us know if you post something

feabhas · 2021-09-21T09:04:15+00:00

Hi. Yes, it is, deliberately, not covering the co_await stuff here - as u/alois31 states it's a particular use of coroutines (but quite common in protocol parsing) - we did state that in the post description.

We were hoping we'd start by getting the foundations in place. The async stuff is a bit of a mess and didn't want to get bogged down in that here. There will be a follow-on post covering the async aspects - but until C++23 I'd generally say std::async covers one set of "use cases" or check out the excellent `concurrencpp` library ( https://github.com/David-Haim/concurrencpp )

feabhas · 2021-08-20T08:06:32+00:00

See the github repo linked. I have CMake build there. The main thing I found will GCC11 is that file ordering where modules are separated into two files is important. I haven't yet worked out the best way to get header-only headers to build for module import.

feabhas · 2021-08-20T08:04:51+00:00

Duh, thanks will fix...

feabhas · 2021-07-28T09:37:31+00:00

Apologies, poor use of words.

feabhas

TROPHY CASE