[perl #45737] [PATCH] [NEW] Change interface to all configuration step runstep() methods

[James Keenan via RT]

No complaints; no smoke failures; resolving ticket.

[perl #46253] [PATCH] Remove reverse inull in imcc/instructions.c (Coverity CID 130)

[via RT]

# New Ticket Created by  Paul Cochrane 
# Please include the string:  [perl #46253]
# in the subject line of all future correspondence about this issue. 
# http://rt.perl.org/rt3/Ticket/Display.html?id=46253 >


Hi,

Coverity Prevent tells us in CID 130 that the 'next' variable is
checked for nullness *after* it is dereferenced.  The offending code
is:

Instruction * const next = unit->instructions;

unit->instructions = tmp;
tmp->next = next;
next->prev = tmp;   --> if 'next' is NULL here (or
on following line),
tmp->line = next->line;...  kaboom
if (!next)--> check if 'next' is NULL
unit->last_ins = tmp;

The annotations are my reading of the potential problem with the code.
 Attached is a patch which (I hope) fixes the problem.  'make test'
passes so things are mostly ok with the change I've made.  The patch
definitely needs review as the code isn't very easy to disentangle
('next' updates 'tmp', which later updates 'next', which later updates
'next'...) and so I hope the patch contains the correct logic.  If
noone complains I'll commit the patch in about 3 days, if it is
approved before then, I'll apply it as soon as I can.

Thanks!  :-)

Paul


imcc_instructions_c.patch
Description: Binary data

[perl #46249] [PATCH] Add missing macro parenthesis in pobj.h

[via RT]

# New Ticket Created by  Paul Cochrane 
# Please include the string:  [perl #46249]
# in the subject line of all future correspondence about this issue. 
# http://rt.perl.org/rt3/Ticket/Display.html?id=46249 >


Hi,

in the process of tracking down another issue I noticed (with the help
of vim's sytnax highlighting) an unmatched parenthesis in a macro in
include/parrot/pobj.h.  This patch corrects the issue, and I *think*
I've put the missing parenthesis in the right place, but I thought it
best to get some other opinions first before I commit this.  If noone
complains, I'll commit the patch in about 3 days, if it is approved,
as soon as I am able.

Paul


pobj_h.patch
Description: Binary data

Re: wrapping up the OO implementation

[Allison Randal]

Bob Rogers wrote:


I could only find a few find_type hits in t/**/*.t; these are now fixed.
(I assume this is because I'm late to the party.)


Great contributions all around. Thanks everybody!


   All of the rest (besides the implementation of the op itself) seems
to be in documentation.  Attatched are a few that ought to be changed
(diff against the pdd15oo branch) -- but perhaps you are planning a
wholesale rewrite of these sections?


Patch looks great, go ahead and apply. For the most part, the new object 
 model acts as a drop-in replacement for the old one, so a few fixes 
like this one are good for now.


You might submit a cage cleaner task for a deeper review of the OO 
documentation. (I've been cleaning up the docs embedded in the code as I 
work on the code, but the external docs will need sprucing up with some 
of the new features.)


Allison

Re: [perl #46223] [PATCH] Remove dead code in src/pmc/pair.pmc (Coverity CID 5)

[Leopold Toetsch]

Am Montag, 8. Oktober 2007 19:05 schrieb Paul Cochrane:
> So, the patch is right (however, for my wrong reasoning)?  Is everyone
> happy if I apply it then?

$ svn ann src/pmc/pair.pmc
  8374leo A Pair PMC represents one key => value mapping like a one 
element hash.

I actually can't remember the reason for writing this one. But I think it was 
pugs/perl6 related some time ago, for some value of "time ago".

As this obvious bug never came up, this pmc looks likes very undertested or 
more precisely unused to me.

I'd check the overall usage of this pmc and estimate the harm of removing it 
alltogether.

leo

Re: Indirect objects, adverbial arguments and whitespace

[Dr.Ruud]

Markus Laker schreef:

> If I've got this right:
> 
> mangle $foo :a;# mangle($foo, a => 1);
> mangle $foo: a;# $foo.mangle(a());
> 
> So these --
> 
> mangle $foo:a;
> mangle $foo : a;
> 
> are ambiguous and, as far as I can tell from the synopses, undefined.
> So what's the rule: that indirect-object colon needs whitespace after
> but not before, and adverbial colon needs whitespace before but not
> after? 
> 
> The reason I ask is that I'm knocking up an intro to Perl 6 for C and
> C++ programmers.  I expect some of Perl 6's whitespace rules to trip
> up people used to C++ (as they have me, in my clumsy attempts with
> Pugs), and I'd like to summarise all the whitespace dwimmery in one
> place. 

We were making fun of this:
    

-- 
Affijn, Ruud

"Gewoon is een tijger."

Re: [perl #46223] [PATCH] Remove dead code in src/pmc/pair.pmc (Coverity CID 5)

[Paul Cochrane]

On 08/10/2007, Joshua Juran <[EMAIL PROTECTED]> wrote:
> On Oct 8, 2007, at 4:36 AM, Paul Cochrane wrote:
>
> > On 08/10/2007, Joshua Juran <[EMAIL PROTECTED]> wrote:
> >> On Oct 7, 2007, at 12:43 PM, Paul Cochrane (via RT) wrote:
> >>
> >>> # New Ticket Created by  Paul Cochrane
> >>> # Please include the string:  [perl #46223]
> >>> # in the subject line of all future correspondence about this issue.
> >>> # http://rt.perl.org/rt3/Ticket/Display.html?id=46223 >
> >>>
> >>>
> >>> Coverity Prevent mentions that the code after the C
> >>> comparison in src/pmc/pair.pmc can never be executed.  Here is the
> >>> offending chunk of code (the comments are mine):
> >>>
> >>>  p1 = PMC_pmc_val(SELF);
> >>>  p2 = PMC_pmc_val(value);
> >>>
> >>>  if (!p1 && !p2)
> >>> return 1;  /* when p1 = p2 = null, or p1 = p2 = non-null */
> >>>
> >>>  if (p1 || p2)
> >>> return 0; /* when p1 = null, p2 = non-null, or p1 = non-null,
> >>> p2 = null */
> >>>
> >>> /* which handles all permutations of p1 and p2 */
> >>>
> >>> /* hence, the following code can never be executed */
> >>>  if (!mmd_dispatch_i_pp(INTERP, p1, p2, MMD_EQ))
> >>> return 0;
> >>>
> >>>  return 1;
> >>>
> >>> The attached patch removes the dead code, and 'make test'
> >>> passes.  If
> >>> there are no complaints, I'll apply this patch in about 3 days;
> >>> if it
> >>> is approved, as soon as I am able.
> >>
> >> The "when ..." comments don't match the code.  Depending on which is
> >> correct I'd write either
> >>
> >> return p1 == null  &&  p2 == null;
> >>
> >> or
> >>
> >> return (p1 == null) == (p2 == null);
> >
> > Another good reason why I submitted a patch instead of just committing
> > the change :-)  On looking at this again I think my reading of the
> > code was incorrect.  Here's another go:
> >
> > This path will be taken only if p1 *and* p2 are null.
> > if (!p1 && !p2)
> > return 1;
> >
> > This path will be taken if either p1 is non-null or p2 is non-null
> > if (p1 || p2)
> >  return 0;
> >
> > So the only case left is p1 is non-null *and* p2 is non-null, which
> > means this code *is* executed (at some stage)
>
> False.  "Either or" in logic indicates exclusive union, but in
> general English does not.  Regardless, the test (p1 || p2) includes
> the case of both p1 and p2 being non-null, so whatever the state of
> p1 and p2, one of those two tests will catch it and return.

You're right.  I'm obviously in the middle of a brain-fade of some
description...  I even checked my thoughts on paper, rather than doing
the logic in my head.  Oh well, good I posted this to the list

> > The question now becomes: what is Coverity Prevent trying to tell us?
> > Is it getting mixed up somehow?
>
> Nope.  Coverity is right on the money.

So, the patch is right (however, for my wrong reasoning)?  Is everyone
happy if I apply it then?

Paul

Re: [perl #46099] [TODO] Check for existing parent classes in add_parent()

[Klaas-Jan Stol]

On 10/8/07, Klaas-Jan Stol <[EMAIL PROTECTED]> wrote:
>
>
>
> On 10/8/07, Allison Randal <[EMAIL PROTECTED]> wrote:
> >
> > Klaas-Jan Stol wrote:
> > > I think it should be something like this:
> > >
> > >   /* RT46099 Check we don't already have this parent. */
> > >
> > >  /* If we have already added a method with this name... */
> > > if (VTABLE_exists_keyed_str(interp, _class->all_parents,
> > > VTABLE_name(interp, parent))) {
> > > real_exception(interp, NULL, E_NotImplementedError,
> > > "This class already has this parent.");
> > > }
> >
> > Great start. Change "method" to "parent" in the comment. You'll want to
> > check the immediate parents of the class, not all inherited parents, so
> > you need to be looking at _class->parents, instead of
> > _class->all_parents. And, unlike methods, parents are stored as an array
> > of class objects, not a hash keyed by class name, so you'll need to loop
> > over the parents array and check 'VTABLE_is_same' on each.
> >
> > Also, it'd be good to add more information to the real_exception
> > message, like:
> >
> >  real_exception(interp, NULL, E_NotImplementedError,
> >  "The class '%S' already has a parent class '%S'. "
> >  "It may have been supplied by a role.",
> >  VTABLE_get_string(interp, SELF),
> >  VTABLE_get_string(interp, parent));
>
>
> thanks for your pointers.
>
> > can't test this, parrot does not build in pdd15 branch.
> > > it should be more or less like this, based on impl of add_attribute.
> > >
> > > the headerfile classobject.h is missing in the branch, while it is
> > there in
> > > trunk. Is this right?
> >
> > The pdd15oo branch does build (since Saturday), and passes most of its
> > tests. Try 'make realclean', as some files have moved ( classobject.h,
> > for example, is now include/parrot/oo_private.h).
>
>
> thanks, works!
>
> Attached a patch  that should do the trick. I could not get VTABLE_is_same
> working, some error about parrot_string_t not having a member 'vtable' or
> something like that. Instead I  looked around and found some other
> comparison function.
>
> > btw, the type of exception should be changed, also for other methods.
> >
> > Agreed.
>
>
> but not sure which type yet. for now I didn't change it, they can be all
> reviewed in one go I think.
>

whoops, I meant I did change it, to INVALID_OPERATION, but I think that's
not really descriptive too. Let's change them all at once, later.

kjs
>
>

Re: [perl #46099] [TODO] Check for existing parent classes in add_parent()

[Klaas-Jan Stol]

On 10/8/07, Allison Randal <[EMAIL PROTECTED]> wrote:
>
> Klaas-Jan Stol wrote:
> > I think it should be something like this:
> >
> >   /* RT46099 Check we don't already have this parent. */
> >
> >  /* If we have already added a method with this name... */
> > if (VTABLE_exists_keyed_str(interp, _class->all_parents,
> > VTABLE_name(interp, parent))) {
> > real_exception(interp, NULL, E_NotImplementedError,
> > "This class already has this parent.");
> > }
>
> Great start. Change "method" to "parent" in the comment. You'll want to
> check the immediate parents of the class, not all inherited parents, so
> you need to be looking at _class->parents, instead of
> _class->all_parents. And, unlike methods, parents are stored as an array
> of class objects, not a hash keyed by class name, so you'll need to loop
> over the parents array and check 'VTABLE_is_same' on each.
>
> Also, it'd be good to add more information to the real_exception
> message, like:
>
>  real_exception(interp, NULL, E_NotImplementedError,
>  "The class '%S' already has a parent class '%S'. "
>  "It may have been supplied by a role.",
>  VTABLE_get_string(interp, SELF),
>  VTABLE_get_string(interp, parent));


thanks for your pointers.

> can't test this, parrot does not build in pdd15 branch.
> > it should be more or less like this, based on impl of add_attribute.
> >
> > the headerfile classobject.h is missing in the branch, while it is there
> in
> > trunk. Is this right?
>
> The pdd15oo branch does build (since Saturday), and passes most of its
> tests. Try 'make realclean', as some files have moved (classobject.h,
> for example, is now include/parrot/oo_private.h).


thanks, works!

Attached a patch  that should do the trick. I could not get VTABLE_is_same
working, some error about parrot_string_t not having a member 'vtable' or
something like that. Instead I  looked around and found some other
comparison function.

> btw, the type of exception should be changed, also for other methods.
>
> Agreed.


but not sure which type yet. for now I didn't change it, they can be all
reviewed in one go I think.

kjs


add_parent_check.patch
Description: Binary data

Re: Some questions about using NaN and Inf

[brian d foy]

In article <[EMAIL PROTECTED]>, TSa
<[EMAIL PROTECTED]> wrote:

> The only operator that can be used to investigate these values should
> be ~~ and the given/when statement that uses it. 

Why should that be true? What's wrong with treating it as an object
like anything else? 

The trick is limiting the number of special cases and exceptions to the
rule so beginners can form the right conceptual model of everything.

Parrot Bug Summary

[Parrot Bug Summary]

Parrot Bug Summary

http://rt.perl.org/rt3/NoAuth/parrot/Overview.html
Generated at Mon Oct 8 13:00:02 2007 GMT
---

  * Numbers
  * New Issues
  * Overview of Open Issues
  * Ticket Status By Version
  * Requestors with most open tickets

---

Numbers

Ticket Counts: 104 new + 572 open = 676
Created this week: 89
Closed this week: 3

---

New Issues

New issues that have not been responded to yet

1 - 2 weeks old
45857 [IMCC][RFC] #line vs .line
45787 parallel make failures
2 - 3 weeks old
45659 Tcl - [string is double .1] returns wrong value
45629 [Scheme] Reenable skipped tests, adapt to current calling conventions
45593 [CAGE] clean up headerizer warnings
45565 Random failures in t/perl/Parrot_Docs.t
45503 one test in 't/op/string.t' is failling for jit runcore
3 - 4 weeks old
45479 [CAGE] config/gen/PodText.pm: Find better location
45367 [TODO] Limit the required interface for PMCs
45365 [TODO] Update parrot.el to remove return argument parenthesis requirement
45357 [TODO] Which exception should be thrown with register overflow?
4 - 5 weeks old
45267 [TODO] Option '--trace' of the parrot executable
5 - 6 weeks old
45055 [TODO] JIT segs are currently not built
6 - 7 weeks old
44979 [BUG] TGE reports an error, but won't say which line it's on.
44945 [CAGE] Add Documentation to Undef PMC
44861 [TODO]: remove compiler warnings note from README
44851 Update step 2.f in release_manager_guide.pod
7 - 8 weeks old
44765 [PATCH] Don't reuse interpreter argument on stack
8 - 9 weeks old
44487 Exporter docs rely on t/pmc/exporter.t for examples
44471 [PATCH] :vtable is ignored when :anon
9 - 10 weeks old
44307 PIR tutorial
10 - 11 weeks old
44139 opcodes, warnings, and exceptions
11 - 12 weeks old
12 - 13 weeks old
13 - 14 weeks old
14 - 15 weeks old
15 - 16 weeks old
16 - 17 weeks old
17 - 18 weeks old
18 - 19 weeks old
19 - 20 weeks old
20 - 21 weeks old
---

Overview of Open Issues

PlatformSeverity  Tag  Lang
aix0abandoned 0   5005threads   0  Amber0
All3fatal 3   bounce0  BASIC0
bsdos  0High  0   Bug  61  bc   0
cygwin 7low   1   compiler  1  befunge  0
cygwin_nt  0medium0   configure 0  bf   0
darwin 5none  0   core  0  cola 0
dec_osf0Normal1   dailybuild0  forth0
dgux   0unknown   0   docs  1  jako 0
dos0Wishlist  3   duplicate 0  Lisp 2
dynixptx   0 install   1  m4   0
freebsd8  library   0  ook  0
generic0  notabug   0  perl61
gnu0  notok 0  plot 0
HPUX   2  ok0  punie0
irix   0  Patch47  pynie2
irix64 0  regex 0  python   0
Linux  3  sendToCPAN0  ruby 0
lynxos 0  Todo370  scheme   0
mac0  unknown   0  tcl 72
machten0  utilities 0  urm  0
macos  0  wontfix   0  Zcode0
MacOS X2
mswin320
netbsd 1
next   0
openbsd2
os20
os390  0
other  0
powerux0
qnx0
riscos 0
sco0
Solaris5
sunos  1
svr4   0
svr5   0
sysv   0
unicos 0
unicosmk   0
unix   0
unknown0
uts0
vms0
VOS0
Win32 10
---

Ticket Status By Version

New or OpenResolved

---

Requestors with most open tickets

Paul Cochrane 231
James Keenan   61
Will Coleda44
Jerry Gay  40
chromatic  26
jerry gay  25
Matt Diephouse 22
Chip Salzenberg15
Klaas-Jan Stol 15
Bernhard Schmalhofer   15

---

  * Total Issues
  * New Issues
  * Overview of Open Issues
  * Ticket Status By Version
  * Requestors with most open tickets

---

Re: Some questions about using NaN and Inf

[Doug McNutt]

At 11:52 +0200 10/8/07, TSa wrote:
>HaloO,
>
>My understanding is that values like NaN or Inf are exceptional. That
>means you can understand them as unthrown or in-band exceptions. Like
>undef they might contain interesting information about their
>origination. That being said I think these exceptional values should
>not be re-inserted into the regular flow of computation by simple
>comparison. In other words $x == NaN and the like should be undef.
>That means that these values behave viral in the sense that more and
>
>The only operator that can be used to investigate these values should
>be ~~ and the given/when statement that uses it. This means we need
>a standard set of e.g. NaN cases. Does someone know what IEEE defines
>in that area? Here's a little code example illustrating my point:
>
>  if $x ~~ NaN
>  {
>  given $x
>  {
>  when DIV_ZERO {...}
>  when UNDERFLOW {...}
>  when OVERFLOW {...}
>  }
>  }
>
>Also handling Inf is a difficult thing to do. In general Inf == Inf will
>hardly hold. The first thing I would expect is Inf to be properly typed.
>That is Inf[Num] is different from Inf[Complex] and for finite types any
>number outside the valid range could represent Inf.

>From this engineer/physicist's point of view the most valuable part of the NaN 
>concept is that NaNs can be passed to formulas and functions in a way that 
>avoids error checking altogether.

$B = Inf ( as the result of a previous calculation)
$result = $A / (1.0 + 1.0 /$B);

need not return an error because one of its arguments is an error. The result, 
to the expected precision of floating numerics, is exactly $A.  Such formulas, 
usually much more complicated, do crop up regularly and it's a pain to have to 
pre-check for out-of-range values in a tight loop. It's best not to trap that 
kind of error but to let the calculation proceed to a result which might, or 
might not, be out of range.

Vectors and complex numbers, which can be thought of as 2-D vectors with 
different rules, don't really exhibit the NaN concept. A component can be a NaN 
but nobody has defined what a whole vector as a NaN means. Asking whether one 
complex number is bigger than another results in an answer that depends on the 
user's intentions and is probably not something that should be frozen into a 
compiler. Let the programmer do an OR on each of the components as desired. He 
might really want to compare lengths of the vectors.

Remember that there are some 2**22 possible NaNs in the bit pattern of a 32 bit 
float. Only a few are defined by the IEEE. It's possible to use others as 
results of a specialized subroutine. "The series didn't converge" for instance.

= Inf - Inf;  # should not return zero! Those two Inf's are not equal except in 
some special circumstances that will not be known. They might be calculated 
from the same series that didn't converge but that's a problem for the likes of 
Maple or Mathematica. Nobody should expect perl to worry about that kind of 
thing.  Inf == Inf returning true would make this curious if $A = Inf and $B = 
Inf.

$Y = (A$ == B$) ? 0 : A$ - B$;

Wikipedia for IEEE 754 
 is accurate. Actual 
IEEE standards have to be purchased and they are not cheap. Even as a member I 
don't get to see them for free and if I sound upset, I intend to. GNU forever.

 Discusses "signaling" and "quiet" NaN's. It 
might be possible for perl6 to trap errors for the signaling variety and not 
for the quiet ones but that's not a complete answer.

For a Practical Extraction and Reporting Language perl6 should probably adopt 
Wikipedia as an authority and, as far as possible, avoid making new definitions.
-- 

-->  Halloween  == Oct 31 == Dec 25 == Christmas  <--

Re: [perl #46223] [PATCH] Remove dead code in src/pmc/pair.pmc (Coverity CID 5)

[Joshua Juran]

On Oct 8, 2007, at 4:36 AM, Paul Cochrane wrote:


On 08/10/2007, Joshua Juran <[EMAIL PROTECTED]> wrote:

On Oct 7, 2007, at 12:43 PM, Paul Cochrane (via RT) wrote:


# New Ticket Created by  Paul Cochrane
# Please include the string:  [perl #46223]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=46223 >


Coverity Prevent mentions that the code after the C
comparison in src/pmc/pair.pmc can never be executed.  Here is the
offending chunk of code (the comments are mine):

 p1 = PMC_pmc_val(SELF);
 p2 = PMC_pmc_val(value);

 if (!p1 && !p2)
return 1;  /* when p1 = p2 = null, or p1 = p2 = non-null */

 if (p1 || p2)
return 0; /* when p1 = null, p2 = non-null, or p1 = non-null,
p2 = null */

/* which handles all permutations of p1 and p2 */

/* hence, the following code can never be executed */
 if (!mmd_dispatch_i_pp(INTERP, p1, p2, MMD_EQ))
return 0;

 return 1;

The attached patch removes the dead code, and 'make test'  
passes.  If
there are no complaints, I'll apply this patch in about 3 days;  
if it

is approved, as soon as I am able.


The "when ..." comments don't match the code.  Depending on which is
correct I'd write either

return p1 == null  &&  p2 == null;

or

return (p1 == null) == (p2 == null);


Another good reason why I submitted a patch instead of just committing
the change :-)  On looking at this again I think my reading of the
code was incorrect.  Here's another go:

This path will be taken only if p1 *and* p2 are null.
if (!p1 && !p2)
return 1;

This path will be taken if either p1 is non-null or p2 is non-null
if (p1 || p2)
 return 0;

So the only case left is p1 is non-null *and* p2 is non-null, which
means this code *is* executed (at some stage)


False.  "Either or" in logic indicates exclusive union, but in  
general English does not.  Regardless, the test (p1 || p2) includes  
the case of both p1 and p2 being non-null, so whatever the state of  
p1 and p2, one of those two tests will catch it and return.



The question now becomes: what is Coverity Prevent trying to tell us?
Is it getting mixed up somehow?


Nope.  Coverity is right on the money.

Josh

Re: [perl #46223] [PATCH] Remove dead code in src/pmc/pair.pmc (Coverity CID 5)

[Paul Cochrane]

On 08/10/2007, Joshua Juran <[EMAIL PROTECTED]> wrote:
> On Oct 7, 2007, at 12:43 PM, Paul Cochrane (via RT) wrote:
>
> > # New Ticket Created by  Paul Cochrane
> > # Please include the string:  [perl #46223]
> > # in the subject line of all future correspondence about this issue.
> > # http://rt.perl.org/rt3/Ticket/Display.html?id=46223 >
> >
> >
> > Coverity Prevent mentions that the code after the C
> > comparison in src/pmc/pair.pmc can never be executed.  Here is the
> > offending chunk of code (the comments are mine):
> >
> >  p1 = PMC_pmc_val(SELF);
> >  p2 = PMC_pmc_val(value);
> >
> >  if (!p1 && !p2)
> > return 1;  /* when p1 = p2 = null, or p1 = p2 = non-null */
> >
> >  if (p1 || p2)
> > return 0; /* when p1 = null, p2 = non-null, or p1 = non-null,
> > p2 = null */
> >
> > /* which handles all permutations of p1 and p2 */
> >
> > /* hence, the following code can never be executed */
> >  if (!mmd_dispatch_i_pp(INTERP, p1, p2, MMD_EQ))
> > return 0;
> >
> >  return 1;
> >
> > The attached patch removes the dead code, and 'make test' passes.  If
> > there are no complaints, I'll apply this patch in about 3 days; if it
> > is approved, as soon as I am able.
>
> The "when ..." comments don't match the code.  Depending on which is
> correct I'd write either
>
> return p1 == null  &&  p2 == null;
>
> or
>
> return (p1 == null) == (p2 == null);

Another good reason why I submitted a patch instead of just committing
the change :-)  On looking at this again I think my reading of the
code was incorrect.  Here's another go:

This path will be taken only if p1 *and* p2 are null.
if (!p1 && !p2)
return 1;

This path will be taken if either p1 is non-null or p2 is non-null
if (p1 || p2)
 return 0;

So the only case left is p1 is non-null *and* p2 is non-null, which
means this code *is* executed (at some stage)

if (!mmd_dispatch_i_pp(INTERP, p1, p2, MMD_EQ))
return 0;

and it's also potentially the case that !mmd_dispatch_i_pp(INTERP, p1,
p2, MMD_EQ) evaluates to false, hence the final return of the function
could be executed.

The question now becomes: what is Coverity Prevent trying to tell us?
Is it getting mixed up somehow?

Any help would be greatly appreciated!

Paul

Re: Some questions about using NaN and Inf

[TSa]

HaloO,

brian d foy wrote:

So, then, back to the question. People don't care how it's implemented
(and it would be great if we didn't have to explain it). What's the
idiom for the comparison going to be?


My understanding is that values like NaN or Inf are exceptional. That
means you can understand them as unthrown or in-band exceptions. Like
undef they might contain interesting information about their
origination. That being said I think these exceptional values should
not be re-inserted into the regular flow of computation by simple
comparison. In other words $x == NaN and the like should be undef.
That means that these values behave viral in the sense that more and
more of the values handled in a program become undef.

The only operator that can be used to investigate these values should
be ~~ and the given/when statement that uses it. This means we need
a standard set of e.g. NaN cases. Does someone know what IEEE defines
in that area? Here's a little code example illustrating my point:

  if $x ~~ NaN
  {
  given $x
  {
  when DIV_ZERO {...}
  when UNDERFLOW {...}
  when OVERFLOW {...}
  }
  }

Also handling Inf is a difficult thing to do. In general Inf == Inf will
hardly hold. The first thing I would expect is Inf to be properly typed.
That is Inf[Num] is different from Inf[Complex] and for finite types any
number outside the valid range could represent Inf.

Regards TSa.
--

You know, it would be sufficient to really understand the electron.
  --- Albert Einstein

Re: [perl #46223] [PATCH] Remove dead code in src/pmc/pair.pmc (Coverity CID 5)

[Joshua Juran]

On Oct 7, 2007, at 12:43 PM, Paul Cochrane (via RT) wrote:


# New Ticket Created by  Paul Cochrane
# Please include the string:  [perl #46223]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=46223 >


Coverity Prevent mentions that the code after the C
comparison in src/pmc/pair.pmc can never be executed.  Here is the
offending chunk of code (the comments are mine):

 p1 = PMC_pmc_val(SELF);
 p2 = PMC_pmc_val(value);

 if (!p1 && !p2)
return 1;  /* when p1 = p2 = null, or p1 = p2 = non-null */

 if (p1 || p2)
return 0; /* when p1 = null, p2 = non-null, or p1 = non-null,  
p2 = null */


/* which handles all permutations of p1 and p2 */

/* hence, the following code can never be executed */
 if (!mmd_dispatch_i_pp(INTERP, p1, p2, MMD_EQ))
return 0;

 return 1;

The attached patch removes the dead code, and 'make test' passes.  If
there are no complaints, I'll apply this patch in about 3 days; if it
is approved, as soon as I am able.


The "when ..." comments don't match the code.  Depending on which is  
correct I'd write either


return p1 == null  &&  p2 == null;

or

return (p1 == null) == (p2 == null);

Josh