Timeline for Problems returning char array from function, value gets messed up
Current License: CC BY-SA 3.0
5 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jun 29, 2016 at 17:45 | vote | accept | Michael Kleinhenz | ||
| Jun 29, 2016 at 16:41 | comment | added | JRobert | ... Coming to embedded systems from other environments, one will have seen all manner of "solutions" to doing this, including returning a local buffer and having gotten away with it (before the system ships!). An embedded system is expected to be able to run 24/7. "Fatal error: out of memory!" is not a option. Neither is stopping or any of the host of failures due to corrupted data. It has to "just work", and option 3 is the least likely to break. | |
| Jun 29, 2016 at 16:35 | comment | added | JRobert | +1 for option 3. It avoids the bugs of global and disorderly access in option 1; the risks of over-writing of option 2; and the memory fragmentation of option 4. If the caller needs a larger return value than a single value, it provides the memory space for it. Of course if the caller isn't the end-user of the return, but has to return to its caller, the same conditions apply: caller's caller provides the memory, and so on up to the final consumer. Then it up to that consumer function('s author) how to allocate the memory buffer, but that is the one and only place that choice should be made. | |
| Jun 29, 2016 at 14:41 | history | edited | John Burger | CC BY-SA 3.0 |
Clarified variable names
|
| Jun 29, 2016 at 14:32 | history | answered | John Burger | CC BY-SA 3.0 |