[postgis-devel] lwgeom parser robustness and niceness

[strk]

Carl, you were right, it was the error function ....
I've fixed it. Now you get ERRORs instead of traps.

Also, I've unleashed the parser to accept miXeD case.

A rimaning issue is about wheter to accept (MULTI)POINT(),
(MULTI)LINESTRING(), (MULTI)POLYGON(), GEOMETRYCOLLECTION()
as empty geometries... I think that would be nice, are there
comments ?

--strk;

On Mon, Jun 07, 2004 at 03:14:52PM +0200, strk wrote:
> On Mon, Jun 07, 2004 at 09:03:40AM -0400, Carl Anderson wrote:
> > strk wrote:
> > >I've been testing lwgeom stuff.
> > >I've found it fault on every 'unexpected' format.
> > >
> > >All these queries kill the backend:
> > >
> > >        -- EMPTY geoms
> > >        SELECT 'POINT()'::lwgeom;
> > >        SELECT 'MULTIPOINT()'::lwgeom;
> > >        SELECT 'LINESTRING()'::lwgeom;
> > >        SELECT 'MULTILINESTRING()'::lwgeom;
> > >        SELECT 'POLYGON()'::lwgeom;
> > >        SELECT 'MULTIPOLYGON()'::lwgeom;
> > >        SELECT 'GEOMETRYCOLLECTION()'::lwgeom;
> > >
> > >        -- NON geoms (a check for first letter is performed)
> > >        SELECT 'P()'::lwgeom
> > >        SELECT 'L()'::lwgeom
> > >        SELECT 'M()'::lwgeom
> > >        SELECT 'G()'::lwgeom
> > >
> > >        -- INVALID geoms
> > >        SELECT 'POINT(0 0 0 0 0)'::lwgeom;
> > >        SELECT 'LINESTRING(0 0)'::lwgeom;
> > >        SELECT 'POLYGON((0 0, 1 1))'::lwgeom;
> > >        SELECT 'POLYGON(0 0)'::lwgeom;
> > >        ... try your own ...
> > >
> > >        -- MIXED dimension geoms
> > >        SELECT 'MULTIPOINT(0 0 0, 0 0)'::lwgeom;
> > >        SELECT 'LINESTRING(0 0 0 0, 0 0 0)'::lwgeom;
> > >        ... try your own ...
> > >
> > >Also, I don't like this error message:
> > >
> > >	SELECT 'point(0 0)'::lwgeom;
> > >	ERROR:  couldnt determine if input lwgeom is WKB or WKT
> > >
> > >I think 1) it's clearly a WKT and 2) we could accept lower or mixed case
> > >lwgeoms, wouldn't it be acceptable in speed ?
> > >
> > >--strk;
> > 
> > If you edit the bison/lex files to include rules that cover the above 
> > cases the abends stop.  Not that this is the corrent fix just evidence 
> > that it is in bison/flex
> > 
> > such as in wktparse.y
> > from
> > a_point: point_2d | point_3d | point_4d;
> > 
> > to include a rule for POINT()
> > a_point: empty | point_2d | point_3d | point_4d;
> > 
> > 
> > 
> > I am not very good with bison/flex but
> > I suspect that the parser code is emitting a warning that is tripping
> > Postgres.  I have poked at the passed in error function But I think I 
> > would need to RTFM first.
> 
> I suspect unallocated memory access actually... 
> 
> Ralph, could you produce a simple test app parsing WKT from stdin
> and dumping WKT to stdout ?
> 
> > 
> > 
> > btw
> > moving Makefile to
> > 
> > 	$(YACC) -vd -b wktparse -p lwg_parse_yy wktparse.y
> > 
> > causes it to produce wktparse..tab.c and wktparse.tab.h directly
> 
> Before adding switches $(YACC) compatibilities should be checked.
> I belive postgresql guys to be aware of this, and they rename
> the output...
> 
> --strk;
> 
> > 
> > 
> > _______________________________________________
> > postgis-devel mailing list
> > postgis-devel at postgis.refractions.net
> > http://postgis.refractions.net/mailman/listinfo/postgis-devel
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel