On Tue Sep 04 11:40:30 2007, rblasch wrote:
>
> The key here is the "model." While Coverity's model captures the
> C quite correctly, I don't think it recognizes the pointer update
> in the double linked list, which is done in C, as important.
>
> Coverity probably sees something like the follow
I've had another look at this. Here's what I think is going on.
The relevant output is:
Event use_after_free: Using freed pointer "(ins)->next"
Also see events: [alias][freed_arg]
493 for (ins = unit->instructions; ins; ins = ins->next) {
Event alias: aliasing "(ins)->next" with "ins2"
Also s
On 01/09/07, Ron Blaschke <[EMAIL PROTECTED]> wrote:
> Paul Cochrane wrote:
>
> I've had a chance to look at this and the implementation looks quite
> good to me.
>
> There's one thing that still bothers me. The snipped output is:
>
> > Event alias: aliasing "(ins)->next" with "ins2"
> > Also see
Paul Cochrane wrote:
I've had a chance to look at this and the implementation looks quite
good to me.
There's one thing that still bothers me. The snipped output is:
> Event alias: aliasing "(ins)->next" with "ins2"
> Also see events: [freed_arg][use_after_free]
> At conditional (1): "ins2 != 0
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.
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
On 26/08/07, Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> Am Sonntag, 26. August 2007 20:14 schrieb Paul Cochrane:
> > 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?
>
> Why shouldn't you be able t
Am Sonntag, 26. August 2007 20:14 schrieb Paul Cochrane:
> 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?
Why shouldn't you be able to assign a new value to a freed mem location? Your
proposed chang
# New Ticket Created by Paul Cochrane
# Please include the string: [perl #44967]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=44967 >
While having a look through some of the static analysis output
provided by Coverity Pre
13 matches
Mail list logo
