OSDev.org

My personal pragmatic solution is to return an error on every fopen() call instead of dealing with ungetting. (Which actually is a 100% standards compliant solution )

In other words: Before you implement a function, read the spec for it. (Though it's amazing how often you get away with some rather bad approximation of the real function for quite a while until it breaks down...)

Combuster wrote:My personal pragmatic solution is to return an error on every fopen() call.

That's worse than useless. Don't even bother implementing fopen if you're not going to have it. That'll break software at compile time instead of at runtime.

Kevin wrote:In other words: Before you implement a function, read the spec for it. (Though it's amazing how often you get away with some rather bad approximation of the real function for quite a while until it breaks down...)

Indeed. stdio is hard to fully comprehend if you just read the specs for the individual functions, you want to read the ISO C and POSIX sections that give an overview. Do note how ISO C makes some stdio behaviour undefined that POSIX defines. I think you mean terrifying instead of amazing.

sortie wrote:That's worse than useless. Don't even bother implementing fopen if you're not going to have it. That'll break software at compile time instead of at runtime.

Failing at runtime can be useful. Perhaps not for fopen(), that's just too basic, but often programs work quite well with dummy implementations of some functions (that's what I meant by my previous posting). In tyndur, config.h has a #define CONFIG_LIBC_NO_STUBS, so if you're looking for unimplemented functions that a program uses, you disable the stubs, and if you want it to run as good as currently possible, you enable stubs.

I think you mean terrifying instead of amazing.

If that terrifies you, OS development is probably not for you.

Kevin wrote:If that terrifies you, OS development is probably not for you.

On the contrary. I explicitly desire to be terrified by that which is terrifying and then do something about it. It's too easy to ignore the terror and do nothing. Examples like openssl and bash immediately come to mind as terrifying code no-one wanted to read and everyone assumed someone else could maintain well. In my porting duties, I regularly come across terrifyingly bad code that make me question whether I even want to port this software in the first place. You'll often find me in #osdev yelling at code that offends me.