Hi
On 01/26/2016 10:32 PM, Nyall Dawson wrote:
> On 27 January 2016 at 03:31, Sandro Santilli wrote:
>> On Tue, Jan 26, 2016 at 05:24:37PM +0100, Marco Hugentobler wrote:
>> That's a good news, thanks.
>> It would help to have a protocol defined to more easily tag
>> and
On Wed, Jan 27, 2016 at 09:49:48AM +0100, Matthias Kuhn wrote:
> Hi
>
> On 01/26/2016 10:32 PM, Nyall Dawson wrote:
> > On 27 January 2016 at 03:31, Sandro Santilli wrote:
> >> On Tue, Jan 26, 2016 at 05:24:37PM +0100, Marco Hugentobler wrote:
> >> That's a good news, thanks.
>
I've been watching memory corruptions happening during WKB parsing [1]
and found the internal QgsAbstractGeometryV2::fromWkb method not
taking a size parameter to allow preventing such memory errors from
occurring. This needs be changed before it spreads too much !
The current method is virtual:
I think as long as you can make it optional then it doesn't break any of
the APIs and should be fine.
That is just my thoughts. Maybe see what others think first before doing
it.
On Tue, Jan 26, 2016 at 9:22 PM, Sandro Santilli wrote:
> I've been watching memory corruptions
On Tue, Jan 26, 2016 at 01:52:41PM +0100, Matthias Kuhn wrote:
> I would add a second method with size param and deprecate the current one.
> This way we can prepare our own code and remove the dangerous method in 3.0
Consider that QgsGeometry::fromWkb() already takes a size parameter:
On 01/26/2016 04:45 PM, Sandro Santilli wrote:
> On Tue, Jan 26, 2016 at 01:52:41PM +0100, Matthias Kuhn wrote:
>> I would add a second method with size param and deprecate the current one.
>> This way we can prepare our own code and remove the dangerous method in 3.0
> Consider that
On Tue, Jan 26, 2016 at 04:53:20PM +0100, Matthias Kuhn wrote:
>
>
> On 01/26/2016 04:45 PM, Sandro Santilli wrote:
> > On Tue, Jan 26, 2016 at 01:52:41PM +0100, Matthias Kuhn wrote:
> >> I would add a second method with size param and deprecate the current one.
> >> This way we can prepare our
Another thing to consider is whether the API methods should
be ensured to be found in the library (vs. just implemented
as inlined proxies).
In other words, do we also need to retain ABI ?
--strk;
On Tue, Jan 26, 2016 at 05:12:24PM +0100, Sandro Santilli wrote:
> On Tue, Jan 26, 2016 at
Hi
I remember we agreed that the geometryV2 classes are not part of the
stable API (or was that only for 2.10?). So there should be no problem
in adding the parameter I guess.
Regards,
Marco
On 26.01.2016 16:45, Sandro Santilli wrote:
On Tue, Jan 26, 2016 at 01:52:41PM +0100, Matthias Kuhn
On Tue, Jan 26, 2016 at 05:24:37PM +0100, Marco Hugentobler wrote:
> Hi
>
> I remember we agreed that the geometryV2 classes are not part of the
> stable API (or was that only for 2.10?). So there should be no
> problem in adding the parameter I guess.
That's a good news, thanks.
It would help
Hi
On 01/26/2016 05:24 PM, Marco Hugentobler wrote:
> Hi
>
> I remember we agreed that the geometryV2 classes are not part of the
> stable API (or was that only for 2.10?). So there should be no problem
> in adding the parameter I guess.
The subclasses state
added in QGIS 2.10
this API
On 27 January 2016 at 03:31, Sandro Santilli wrote:
> On Tue, Jan 26, 2016 at 05:24:37PM +0100, Marco Hugentobler wrote:
>> Hi
>>
>> I remember we agreed that the geometryV2 classes are not part of the
>> stable API (or was that only for 2.10?). So there should be no
>> problem
I would add a second method with size param and deprecate the current one.
This way we can prepare our own code and remove the dangerous method in 3.0
Matthias
On 01/26/2016 01:00 PM, Nathan Woodrow wrote:
> I think as long as you can make it optional then it doesn't break any
> of the APIs and
13 matches
Mail list logo