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]