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. Cheers, -- ----------------------------------------------------------------- | ,''`. Stephen Gran | | : :' : [EMAIL PROTECTED] | | `. `' Debian user, admin, and developer | | `- http://www.debian.org | -----------------------------------------------------------------
signature.asc
Description: Digital signature
