Creating a const char* from another const char*

Question

i am working on an embedded medical device and have a little problem. I have 2 seperated "application groups", which menas that both of them a strictly separated but nevertheless need to communicate. Group A is the safe area and Group B the unsafe Group which cant do anything in the group A. Now my problem:

In Group A i created a array of struct which holds some informations about syringes.

struct SyringeData{
    int cylinderFloorArea;
    int innerDiameter;
    int outerDiameter;
    int zeroPoint;
    const char* syringename;
    int volume;
    bool activate;
    bool selectSize;
};

In Group B i need the const char* syringename. The communication between both groups is realized about a shared memory area. Group B has a method to build an menu using a framework called LVGL. There i need the following:

static const char* map[] __attribute__((section(".guiMem_data"))) = {"xxx", "\n", "yyy","\n", "zzz", "\n", "xyz", ""};

After filtering the array of struct from the shared memory area i maybe just need a few of them to put them into the map array i listed above. How can i get some of the shared array of struct syringenames to the map, because both are const char* and i can't modify them after init. If i am right i have to initialize const char* at the beginning This map array has to be changed during runtime again and again

Thank you

If you need to modify the pointers (or what they point at) after initialisation, then they should not be `const` qualified. You either need to remove the `const` qualifier or create a struct with the same members that are not `const` qualified and copy as needed to/from that. — Peter, Jun 22 '22 at 05:55
*i can't modify them after init* What is *them*? With the declarations you have at the moment you cannot modify the **characters** but you can modify the **pointer** (e.g. assign a new pointer which will point at some new characters). The difference seems important. — john, Jun 22 '22 at 06:12
Why aren't you using MISRA C if this is a medical application? Is it a completely non-critical system? It doesn't sound like it at all, so this smells like big time quackery. — Lundin, Jun 22 '22 at 06:25
Anyway the answer is very different in C and C++, so you need to know which programming language you are coding in, please clarify. — Lundin, Jun 22 '22 at 06:28
Especially in the medical field you cant afford errors. So then why are you doing memory management by hand? `syringename` should be a `std::string` and if you want to share it then `std::shared_ptr`. Or do you have a global table of syringe names that will be baked into flash? If so that's what should be shared. — Goswin von Brederlow, Jun 22 '22 at 07:18
@GoswinvonBrederlow Err, no. PC programming with the heap is outlawed by any safety standard out there. As is, for the most part, the dangerous C++ language. Regarding why the heap should never be used, you can study it here: [Why should I not use dynamic memory allocation in embedded systems?](https://electrical.codidact.com/posts/286121) — Lundin, Jun 22 '22 at 08:34
@GoswinvonBrederlow i have a global table with all the geomatry data of the syringes and the name. The problem is the ui framework lvgl. I have to use a const char* for this — DaveR, Jun 22 '22 at 08:35
@Lundin the part i write is in c++ but the lvgl function i use to create the button matrix to show a Menu controlled by a jogdial is in c. I can use both. C and C++. — DaveR, Jun 22 '22 at 08:38
@DaveR So you are using C++ and compiling with a C++ compiler. How come you don't have to follow safety/medical standards though? Is it some sort of school project? — Lundin, Jun 22 '22 at 08:52
@Lundin no its a serious project but its just to display something in the non-critical section. And where i dont follow the safety/medical standards? — DaveR, Jun 22 '22 at 09:09
This is using so-called "sloppy typing" where one just lazily hack down the default types of C without much care. You are using signed types for things that should never be allowed to be negative, which needlessly opens up a lot of bug potential for overflows, bitwise arithmetic bugs and so on. You aren't using `stdint.h` like any semi-professional embedded systems project would - it is also recommended by a MISRA-C directive. There doesn't seem to exist any good reasons why these aren't all declared as `uint32_t`. — Lundin, Jun 22 '22 at 09:17
Also, "sentinel" terminated arrays of strings is questionable practice. A deterministic system would rather declare `map[n]` then `_Static_assert(sizeof map/sizeof *map == n, ...`. — Lundin, Jun 22 '22 at 09:20
@Lundin Thank you. I am always grateful for constructive criticism / tips. I am still very inexperienced in embedded development. But how can I solve my problem now — DaveR, Jun 22 '22 at 09:25
@DaveR I posted an answer. Though if you are inexperienced in embedded development, then mission/safety-critical software is probably not the best place for learning, unless you have an experienced lead engineer to show you the ropes (and do all the big picture program design). — Lundin, Jun 22 '22 at 09:30
@DaveR Then why aren't you using MISRA C (or MISRA C++)? Surely you need to take this through some manner of functional safety standard like IEC 61508 or some med tech equivalent. That ain't gonna happen unless the software is written against a safe subset. I don't know if C++ is allowed nowadays, it used to explicitly be a non-suitable language even after MISRA C++ was invented. — Lundin, Jun 22 '22 at 09:42
@Lundin because it wasnt my decision to use C++. But i'll ask it the next time. But first i have to fuix my problem here — DaveR, Jun 22 '22 at 09:56
Let us [continue this discussion in chat](https://chat.stackoverflow.com/rooms/245812/discussion-between-daver-and-lundin). — DaveR, Jun 22 '22 at 10:01

score 0 · Answer 1 · answered Jun 22 '22 at 08:56

static const char* map[] creates a read/writable array of pointers to read-only memory (strings). It will get allocated in RAM on all mainstream systems. You can modify it at any time like any other array.

Simply do: map[i] = something;, where something is a string allocated elsewhere. If you don't store a pointer to what map[i] previously pointed at, that data is now lost.

Creating a const char* from another const char*

1 Answers1