RE: [BUG] test_must_fail: does not correctly detect failures - Was Git 2.16.0-rc2 Test Summary on NonStop

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On January 15, 2018 10:01 PM, brian m. Carlson wrote:
> On Mon, Jan 15, 2018 at 09:25:37AM -0500, Randall S. Becker wrote:
> > On January 15, 2018 2:06 AM, Johannes Sixt wrote:
> > > I take "die exits with non-zero" as a piece of information for the
> > > *users* so that they can write "if perl foo.pl; then something; fi"
> > > in shell scripts. I do *not* interpret it as leeway for implementers
> > > of perl to choose any random value as exit code. Choosing 162 just
> > > to be funky would be short-sighted. [I'm saying all this without knowing
> how perl specifies 'die'
> > > beyond the paragraph you cited. Perhaps there's more about 'die'
> > > that justifies exit code 162.] I'd say that the perl port is broken.
> >
> > I agree that 162 is wrong. Its interpretation is 128+signal, which
> > clearly does not happen in this case. On the platform, if the perl
> > script is via stdin, 162 or 169 are returned. If via file (perl
> > file.pl), 255 comes back. The port has issues. I have an opened a bug
> > report with the platform developers. Usual non-Open Source timeframes
> > to fix apply. ☹
> 
> I believe the standard behavior for Perl with die is the following:
> 
> exit $! if $!;
> exit $? >> 8 if $? >> 8;
> exit 255; # otherwise
> 
> Is there an errno value on your port that matches 162?  Maybe EBADF?
> 
> On Linux, I get the following:
> 
> genre ok % printf die | perl -; echo $?
> Died at - line 1.
> 9

Nah. Worse. Assume a perl script that is simply 'die "hello world"'. If it's in a file, perl reports 255. If from stdin, perl reports 162/169. Doh. That's supposed to be 128+signum, and max sig is 31 (SIGABEND) on the platform. The difficulty at this point is that if I fix wait_or_whine to map either code to 255 or 1, then many more other tests fail, so I'm stuck with either 6 reasonably acceptable breaks or about 60 unacceptable ones, based on assumptions in test_must_fail or other fail detections in the git suite. I'd rather not mess with git code if the test breaks themselves are explainable.

Sign.

Randall

-- Brief whoami:
  NonStop developer since approximately NonStop(211288444200000000)
  UNIX developer since approximately 421664400
-- In my real life, I talk too much.






[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux