Re: "A diagram of C23 basic types"

On 03/04/2025 17:52, bart wrote:

On 03/04/2025 16:26, Scott Lurndal wrote:

bart <bc@freeuk.com> writes:

On 03/04/2025 14:44, Michael S wrote:

>

Overhead is a smaller concern. Name clashes are bigger concern.

>
Examples? Somebody would be foolhardy to use names like 'printf' or
'exit' for their own, unrelated functions. (Compilers will anyway warn
about that.)

>
I've written my own printf and exit implementations in the
past.   Not all C code has a runtime that provides those name.

 Then you have to specify, somehow, that you don't want those automatically included.
 

It is not unusual in embedded systems to provide your own versions of standard library functions.  For example, I have regularly implemented my own "exit" as something like :
_Noreturn void exit(int status) {
(void) status;
while (true) ;
}
I do that because in my embedded systems, the program never ends - but the C startup code typically calls exit() after main() returns.  This pulls in exit() from the library, which pulls in everything for handling at_exit() functions, which pulls in malloc(), and so on - for small microcontrollers, you can sometimes end up with a significant fraction of your flash used by library code you never want to use.
Similarly, sometimes you might want to replace standard library IO functions with something appropriate for the small devices.
This is all undefined behaviour in the C standards (mostly UB because it is not discussed or defined), but the way linkers work and the way most C standard libraries are arranged means it works fine.
However, it's a bit more questionable if you are making your own functions with names that coincide with standard library function names but have different signatures.