Re: C and C++, promotion, stabilization, migrationFor embedded

On 2024-08-20 12:36:43 +0000, chrisq said:

For work here, all functions that return data have a parameter that limits the byte count. Usually pass a pointer to a buffer, with the size parameter equal to or less than the buffer size. Some C library
functions are just not safe to use in that respect.
 Local spun string copy and other functions use the same sort of size limiting.

That, or preferably not transferring the data at all.
Whether that happens with page table modifications, or shared buffers.
Parts of OpenVMS are just chock full of buffer copies. (q.v. previous discussions of the buffer overhead incurred with faster network connections. From discussions here most of a decade ago: https://lwn.net/Articles/629155/ )
And OpenVMS and apps have not-particularly-reentrant and not-particularly-performant code that calls some system service to first size the data and then allocate the buffer and then calls again to return the data. (Which is more glue code, as compared with returning an object containing the data, too. OpenVMS itself doesn't particularly have that concept, however.)
OpenVMS has ~no concept of languages, either. Yeah, the C abd C++ I18N giblets, Java and its own little world, maybe using the existing and older ICU or maybe you ported a newer ICU, and the deprecated Terminal Fallback Facility (TFF) and National (Replacement)  Character Set (NCS) giblets, sure. All of which make things more interesting for apps that want or need to deal with the UTF-8 and post-ASCII world.
--
Pure Personal Opinion | HoffmanLabs LLC