This is the mail archive of the newlib@sourceware.org mailing list for the newlib project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: newlib: fputs aborts on ARM


Shaun Jackman wrote:

2. Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end.
-- The Ten Commandments for C Programmers
http://www.lysator.liu.se/c/ten-commandments.html

Passing a NULL pointer to a C library function is no different than
dereferncing that same NULL pointer yourself. C library functions do
not check their arguments for a NULL pointer, just as the C language
does not check that an array index is within the bounds of the array.
This work is left up to the programmer so that it is her decision when
and where to do this work.

Consider a putc in an inner loop. The programmer would likely want to
check if the FILE* is NULL only once outside of the loop. If putc
checked itself, this would be done over and over inside the loop
unnecessarily.

This case is just one of those burdens the C programmer has to bear.



No, I disagree: why sprinkle an addtional 1k of avoidance when you can put a few bytes of prevention? I don't think so. I've got 128K of Flash memory space in the one device, it is more to my advantage to recover gracefully than to fail miserably.

The issue not that the behavoir of newlib is "wrong", but if it is problematic, why keep it? Why not correct it was my original question. Your position seems to be that crashing the system is the better solution?


TomW



-- Tom Walsh - WN3L - Embedded Systems Consultant http://openhardware.net, http://cyberiansoftware.com "Windows? No thanks, I have work to do..." ----------------------------------------------------



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]