[Gdal-dev] Methods in the bindings that can easily create a segfault

Tamas Szekeres szekerest at gmail.com
Sun Apr 29 13:47:06 EDT 2007


I'm wondering why some of the functions of the C API have no proper
checks of the valid domains of the parameters. But, indeed the C API
is the right place to treat these problems at all.

Do we have a common policy how to make these checks or we should
consider the proper handling of the problematic functions one by one?

This issue is candidate to have a ticket so as to track the changes
that have been made and will be done in the future.

Best regards,

Tamas



2007/4/29, Frank Warmerdam <warmerdam at pobox.com>:
> Ari Jolma wrote:
> > I've previously added a bunch of tests into the bindings. I wonder if I
> > should do the same with these, or should I try to create typemaps that
> > catch NULL parameters.
> >
> > I consider these serious problems since I believe Perl code should never
> > cause a segfault. I have an graphical application, where any user can
> > type in any Perl code. It is just not acceptable that such application
> > segfaults.
>
> Ari,
>
> I'd be happy to have NULL checking, but I think the swig bindings is the
> wrong place for it. I believe it should be done in the C API functions
> instead.  My preference would be for you to backout any changes you have
> made like:
>
>    http://trac.osgeo.org/gdal/changeset/11367
>
> And we instead do this comprehensively in the C API.  I'd be willing to
> queue this up as a job for Matuesz in trunk (not 1.4 branch).
>
> Best regards,
> --
> ---------------------------------------+--------------------------------------
> I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
> light and sound - activate the windows | http://pobox.com/~warmerdam
> and watch the world go round - Rush    | President OSGeo, http://osgeo.org
>
> _______________________________________________
> Gdal-dev mailing list
> Gdal-dev at lists.maptools.org
> http://lists.maptools.org/mailman/listinfo/gdal-dev
>



More information about the Gdal-dev mailing list