On Mon, Jun 02, 2008 at 01:29:15AM +0100, Stephen Gran wrote: > This one time, at band camp, Brendan O'Dea said: > > On Mon, Jun 2, 2008 at 8:20 AM, Stephen Gran <[email protected]> wrote: > > > perl should clear errno before going into a function where the API > > > depends on checking it afterwards. Yes, I am aware there are other ways > > > to determine that the setegid call failed. The problem is that the > > > documentation tells me that the correct way to evaluate failure is to > > > check errno after calls, and the call fails to initialize errno > > > correctly. Either the docs or the function are wrong. > > > > Normal POSIX behaviour is for errno only to be set on error, never > > cleared. See errno(3): "[...] errno is never set to zero by any > > library function." I would be surprised if Perl changed this > > behaviour. > > Yes, of course. The bug isn't only about perl not resetting errno, it's > that either the docs or the function are wrong. Since the docs tells me > that the way to tell if the call failed is to evaluate errno, then the > doc is wrong (as it is now). I would additionally expect the perl DWIM > thing to mean that $! is only ever set if the last call failed, but doing > that would just be a bonus - that's not the main point of this report. > Even a pointer somewhere that perl will not clear errno, and that every > time you call a function that relies on passing back information in $!, > you must explicitly clear it afterwards would be an improvement. > > > Suggest that you explicitly initialise $! to 0. > > Yes, I had already discovered that undef $! works just fine to work > around this behavior, but it is surprising behavior, given the lengths > perl goes to in other places, and given the documentation.
Does the change in <http://perl5.git.perl.org/perl.git/commitdiff/a73bef7?hp=7f8d58fb0a9806bbceb2f22543b4599f3d791699> address your concerns? Thanks, Dominic. -- Dominic Hargreaves | http://www.larted.org.uk/~dom/ PGP key 5178E2A5 from the.earth.li (keyserver,web,email) -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
