incorrect errno/perror with IO::socket->new
in [Perl]
|
Prev: Close function blocks forever when reading from piped output
Next: Perldoc error: "Could not create temp file"
From: xhoster on 17 Jan 2008 11:48 brandon <brandon.mayfield(a)att.net> wrote: > > > > After a successful system call, $! contains whatever it contained > > *before* that system call. =A0Looking in $! is meaningful only after > > an unsuccessful system call. > > > > Yes, and note from the code I did test it before and set it to '0'. Sure, but that doesn't matter. IO::Socket does not guarantee that only a single system call is made during it's new operation. Some of those system calls may fail without the whole operation having failed. Those will set errno, and hence $!, but not in a meaningful manner. IO::Socket tries to abstract away many things behind the scenes. It usually does a good job, but not always. If you want to micromanage the socket creation process the way you would in C, and thus have no hidden complexities that can set $! in unintuitive ways, then don't use IO::Socket, use the low-level socket functions instead. It would be great to figure out why IO::Socket isn't setting $@ appropriately, but I can't really help much with that because I don't have access to the OSes you report problems with. Xho -- -------------------- http://NewsReader.Com/ -------------------- The costs of publication of this article were defrayed in part by the payment of page charges. This article must therefore be hereby marked advertisement in accordance with 18 U.S.C. Section 1734 solely to indicate this fact.
From: xhoster on 17 Jan 2008 12:06 brandon <brandon.mayfield(a)att.net> wrote: > > So that is the behavior I think is inconsistent. Why would passing > Timout result in EINVAL on AIX and HP boxes when an error is > encountered in connect? In a similar situation in the past, I made a IO::Socket::INET copy and replaced the contents of _error with something that does a Carp::confess instead. That way you can get a back-trace of what is going on. Xho -- -------------------- http://NewsReader.Com/ -------------------- The costs of publication of this article were defrayed in part by the payment of page charges. This article must therefore be hereby marked advertisement in accordance with 18 U.S.C. Section 1734 solely to indicate this fact.
From: brandon on 17 Jan 2008 12:34 On Jan 17, 10:06 am, xhos...(a)gmail.com wrote: > brandon <brandon.mayfi...(a)att.net> wrote: > > > So that is the behavior I think is inconsistent. Why would passing > > Timout result in EINVAL on AIX and HP boxes when an error is > > encountered in connect? > > In a similar situation in the past, I made a IO::Socket::INET copy and > replaced the contents of _error with something that does a Carp::confess > instead. That way you can get a back-trace of what is going on. > > Xho > Sounds good. I think I'm going to see if I can find out if RH is changeing anything in IO::Socket, IO::Select, etc., when they build their perl distribution too. Always a possibility that they are making some changes that AIX for example is not. If I find anything interesting I'll let ya'll know. > -- > --------------------http://NewsReader.Com/-------------------- > The costs of publication of this article were defrayed in part by the > payment of page charges. This article must therefore be hereby marked > advertisement in accordance with 18 U.S.C. Section 1734 solely to indicate > this fact.
From: Ilya Zakharevich on 17 Jan 2008 21:01 [A complimentary Cc of this posting was sent to brandon <brandon.mayfield(a)att.net>], who wrote in article <d3b7320c-30dc-4ac4-a552-7d7049a10d9d(a)1g2000hsl.googlegroups.com>: > I have been having fits getting meaningful errno/perror values out of > Perl from Socket->new() and I am hoping someone here might know what > is going on. I wonder why nobody told this yet: proof of a pudding is in a truss. Hope this helps, Ilya
From: Dr.Ruud on 20 Jan 2008 07:17
Uri Guttman schreef: > if the call to IO::Socket->new doesn't > return undef, there is NO point in checking out $! or $@. they will be > meaningless and may be set to some irrelevant value. i have never had > to clear those before making any lib or system calls. i only check > them if there is an indicator of an error. checking them directly is > wrong in almost every case. they could be changed due to some > internal call that is redone or worked around and yet your call will > still have succeeded. Idem with eval { ...; 1; } or do { ... }; v.s. eval { ...; }; if ($@) { ... }; -- Affijn, Ruud "Gewoon is een tijger." |