| |||||||||||||
Re: non C based environments can have problemsRe: non C based environments can have problemsPosted Jan 24, 2007 1:24 UTC (Wed) by ldo (subscriber, #40946)In reply to: Re: non C based environments can have problems by pvaneynd Parent article: LCA: How to improve Debian security
...when errno was changed from an integer variable to a macro we had to handle that with some difficulty. I think having a global errno is such a dumb idea. Why can't system and library calls directly return an error code? ...but with the register-starved x86 architecture nobody seems to want to dedicate a register... I guess the extra registers in x86-64 must come as a relief, then. :)
(Log in to post comments)
Re: non C based environments can have problems Posted Jan 24, 2007 21:13 UTC (Wed) by dododge (subscriber, #2870) [Link] I think having a global errno is such a dumb idea. Why can't system and library calls directly return an error code? Tradition. Within the kernel, these sorts of functions typically do return
error codes directly. But the userspace API is so ingrained that
changing existing functions would break too much. As mentioned, even
just changing errno from being a global New APIs can of course use more sensible error reporting than errno if they want to. It could also be worse, though; for example the glibc obstack API by default aborts the program instead of returning an error, and while you can change that behavior you still have to rely on a global callback that at best uses something like setjmp/longjmp while running the risk of some library code changing the callback to something else. Yuck.
|
|||||||||||||