[prev in list] [next in list] [prev in thread] [next in thread] 

List:       asterisk-dev
Subject:    Re: [asterisk-dev] cdr_odbc.c is broken in trunk
From:       Tilghman Lesher <tilghman () mail ! jeffandtilghman ! com>
Date:       2008-01-10 16:12:35
Message-ID: 200801101012.35349.tilghman () mail ! jeffandtilghman ! com
[Download RAW message or body]

On Thursday 10 January 2008 09:38:56 Nick Gorham wrote:
> Tilghman Lesher wrote:
> >On Thursday 10 January 2008 08:06:20 Nick Gorham wrote:
> >>Michiel van Baak wrote:
> >>>On 11:18, Thu 10 Jan 08, Nick Gorham wrote:
> >>>>Hi,
> >>>>
> >>>>The change to use prepare_cb() in odbc_log became broken in r88182.
> >>>>
> >>>>The code calls SQLBindParameter on a local variable (timestr) but as it
> >>>>now doesn't call SQLExecute in the same function when it finally gets
> >>>> to SQLExecute that variable is out of scope.
> >
> >Out of scope, perhaps, but not out of memory.  It's stored on the local
> > stack, which is not deallocated until after the function returns.  The
> > address thus remains valid.
>
> Of course its valid, but whats to stop it being used (and its contents
> changed) as the stack in any function called between the
> SQLBindParameter call and the SQLExecute. Do you know the stack depth
> used by every function (including the std library)?

Uh, no, the stack doesn't work that way.  The entire contents of timestr[]
remain valid and unchanged until the stack frame is popped.  Which will not
happen until odbc_log() exits.  The only reason this location would be
overwritten is if there's a stack overflow error (not impossible, but we've
been fairly diligent in finding those issues).

> >>>Can you post this to http://bugs.digium.com with a unified
> >>>diff as the patch ?
> >>>Thank you.
> >>
> >>Err, no as it happens, I don't see why I should provide anyone my
> >>address and phone number to submit a bug fix to what I believed was a
> >>GPL project!!!
> >
> >It's a dual licensed project, and we ask for an explicit license, along
> > with the proviso that we actually check to ensure that you are legally
> > entitled to license your changes (that the changes aren't actually owned
> > by your company, for example).
>
> Fair enough, I guess I should keep going to see how negative I can get
> my karma to be while still trying to be helpfull.

The karma system is there to remind us how unhelpful people can be while
they're "trying to be helpfull".

> Why not change to GPL3 to avoid the problem?

Because that does not solve the licensing issues.  In fact, GPLv3 only serves
to further complicate licensing.

-- 
Tilghman

_______________________________________________
--Bandwidth and Colocation Provided by http://www.api-digital.com--

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev
[prev in list] [next in list] [prev in thread] [next in thread]