Am Montag, 27. August 2007 22:27 schrieb Paul Cochrane:
> Mehmet and Joshua,
>
> I can't believe I missed the comment! How embarassing! Thanks
> heaps to you both for pointing that out for me :-)
Just in case:
http://en.wikipedia.org/wiki/Halt_and_Catch_Fire
Have fun,
leo
On 27/08/07, Joshua Isom <[EMAIL PROTECTED]> wrote:
>
> On Aug 27, 2007, at 11:13 AM, Paul Cochrane (via RT) wrote:
>
> > # New Ticket Created by Paul Cochrane
> > # Please include the string: [perl #44995]
> > # in the subject line of all future correspondence about this issue.
> > # http://rt.p
On Aug 27, 2007, at 11:13 AM, Paul Cochrane (via RT) wrote:
# New Ticket Created by Paul Cochrane
# Please include the string: [perl #44995]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=44995 >
Hi everyone,
Another iss
I don't think that the code is safe, but it does what it means :)
=item B
Halt and Catch Fire. Tries to crash parrot.
=cut
op hcf() {
int *a, i;
a = NULL;
i = *a;
goto OFFSET(i) ; /* in case your runtime is very forgiving. */
}
--
Mehmet
# New Ticket Created by Paul Cochrane
# Please include the string: [perl #44995]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=44995 >
Hi everyone,
Another issue raised by Coverity Prevent[1] is that of a NULL pointer
bei
# New Ticket Created by Paul Cochrane
# Please include the string: [perl #44993]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=44993 >
Hi all,
In looking through some of the warnings that Coverity Prevent has
thrown up on
Parrot Bug Summary
http://rt.perl.org/rt3/NoAuth/parrot/Overview.html
Generated at Mon Aug 27 13:00:02 2007 GMT
---
* Numbers
* New Issues
* Overview of Open Issues
* Ticket Status By Version
* Requestors with m
On 27/08/07, Ron Blaschke <[EMAIL PROTECTED]> wrote:
> Paul Cochrane wrote:
> > On 27/08/07, Ron Blaschke <[EMAIL PROTECTED]> wrote:
> >> Paul Cochrane wrote:
> >>> On 26/08/07, chromatic <[EMAIL PROTECTED]> wrote:
> On Sun, Aug 26, 2007 at 11:14:11AM -0700, Paul Cochrane wrote:
>
> >>> Ok, I'
Paul Cochrane wrote:
> On 27/08/07, Ron Blaschke <[EMAIL PROTECTED]> wrote:
>> Paul Cochrane wrote:
>>> On 26/08/07, chromatic <[EMAIL PROTECTED]> wrote:
On Sun, Aug 26, 2007 at 11:14:11AM -0700, Paul Cochrane wrote:
>>> Ok, I'll just tell the Coverity thing to ignore that particular warning.
# New Ticket Created by Colin Kuskie
# Please include the string: [perl #44979]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=44979 >
While developing a return statement for NQP, I came across
this error from TGE:
Nonline
On 27/08/07, Ron Blaschke <[EMAIL PROTECTED]> wrote:
> Paul Cochrane wrote:
> > On 26/08/07, chromatic <[EMAIL PROTECTED]> wrote:
> >> On Sun, Aug 26, 2007 at 11:14:11AM -0700, Paul Cochrane wrote:
> >>
> >>> The variable ins2 is freed by the call to subst_ins() but is then
> >>> later assigned to
Paul Cochrane wrote:
> On 26/08/07, chromatic <[EMAIL PROTECTED]> wrote:
>> On Sun, Aug 26, 2007 at 11:14:11AM -0700, Paul Cochrane wrote:
>>
>>> The variable ins2 is freed by the call to subst_ins() but is then
>>> later assigned to later in the if-block. Um, this isn't a good idea
>>> is it? Th
On 26/08/07, chromatic <[EMAIL PROTECTED]> wrote:
> On Sun, Aug 26, 2007 at 11:14:11AM -0700, Paul Cochrane wrote:
>
> > The variable ins2 is freed by the call to subst_ins() but is then
> > later assigned to later in the if-block. Um, this isn't a good idea
> > is it? The variable shouldn't be f
On Sun, Aug 26, 2007 at 11:14:11AM -0700, Paul Cochrane wrote:
> The variable ins2 is freed by the call to subst_ins() but is then
> later assigned to later in the if-block. Um, this isn't a good idea
> is it? The variable shouldn't be freed in subst_ins() I don't think,
> so shouldn't we inste
14 matches
Mail list logo
