"Experience. In over 30 years of embedded development I have never needed to link to a single standard C library function in an embedded system"

Presumably that's because you've chosen to use your own implementations instead? What I was really trying to understand was why you see the 'C' library as a liability.

Incidentally, it looks as though your experience pre-dates 'C'.

"First let me reiterate I said 8051 embedded systems not embedded systems in general."

I realsise that, which is why I qualified it in my response.

"Given that I would cite malloc, calloc, realloc and free as examples of functions of no relevance to a system with very limited RAM."

I agree to the extent that there are few situations where dynamic allocation makes sense, but 'no relevance' is overstating the case. Bear in mind that not all 8051 designs have 'very limited RAM', unless you see 64k as very limited, and also bear in mind the fact that dynamic allocation can be useful when the total (non-simultaneous) RAM requirement exceeds that available. I have never used dynamic allocation in an 8051 project but I wouldn't rule it out if the application were appropriate.

"That's why they are in a library :-)"

Ah, so you've only reinvented it once?

"As I said I don't want to start a C vs ASM war - these are just my opinions."

I totally agree - I have nothing against assembler. It still has its place in time critical stuff.