> Using the stack or the heap means your variables aren't always at the same memory address

Where do you place the variables then? as global variables? and how do you detect if a memory cell has gone bad?

your programs have a data segment. its not the heap nor the stack... and it can be (depending on loader/linker) a source of reliable object->address mappings as its not dynamically populated.

▲

repelsteeltje 2 days ago | parent [-]

That sounds like your answer is: "Yes, global variables".

That may be a perfectly good solution in many embedded environments, but in most other context's global variables are considered bad design or very limiting and impractical.

▲

2 days ago | parent | next [-]

[deleted]

▲

TuxSH 2 days ago | parent | prev | next [-]

> global variables are considered bad design

Global mutable variables, and they usually tend to be grouped into singletons (solving initialization issues, and fewer people bat an eye)

	▲	RealityVoid 2 days ago \| parent [-]
		Even global mutable variables are a problem only because they lend to spaghetti code and messy state handling if you use them in multiple places. But you could just... make a global variable and then handle it like you would a variable init with malloc. No functional issue there.

▲

izacus 2 days ago | parent | prev [-]

They're considered impractical mostly because language tooling doesn't support them appropriately.

▲

repelsteeltje 2 days ago | parent [-]

Can you elaborate?

For instance, how would better tooling help with storing a TCP buffer in global memory?

▲

tatjam 2 days ago | parent | next [-]

As a quick example, compare doing embedded work with a C static uint8_t[MAX_BUFFER_SIZE] alongside a FreeRTOS semaphore and counter for the number of bytes written, vs using Rust's heapless::Vec<u8, MAX_BUFFER_SIZE>, behind a embassy Mutex.

The first will be a real pain, as you now have 3 global variables, and the second will look pretty much like multi-threaded Rust running on a normal OS, but with some extra logic to handle the buffer growing too big.

You can probably squeeze more performance out of the C code, specially if you know your system in-depth, but (from experience) it's very easy to lose track of the program's state and end up shooting your foot.

	▲	repelsteeltje 2 days ago \| parent [-]
		Okay, fair enough. So it's mostly about the absence of abstraction, in the C example? C++ would offer the same convenience (with std::mutex and std::array globals), but in C it's more of a hassle. Gotcha. One more question because I'm curious - where would you anticipate C would be able to squeeze out more performance in above example?

▲

2 days ago | parent | prev [-]

[deleted]