For what it's worth, this looks like an area of the code that has been
substantially reworked since the tg-cs fork was created.
Regards,
Curt.
On Tue, Oct 12, 2010 at 12:02 PM, Geoff McLane wrote:
> Hi,
>
> In priorities.cxx, the function is written as -
>
> static area_type_descriptor& get_area_descriptor( AreaType area ) {
> if ( 0<=area || area < area_types.size() ) {
> return area_types[area];
> } else {
> SG_LOG(SG_GENERAL, SG_ALERT, "unknown area code = " << (int)area);
> exit(-1);
> }
> }
>
> But this 'OR' (||) does NOT seem right! Should it not be an
> 'AND' (&&), thus correctly range checking the value passed?
>
> If yes, which I am sure it must be, then of course other changes
> follow. In running fgfs-construct, in clipper.cxx, there is,
> in the TGClipper::merge_sliver function :-
>
> for ( area = 0; area < TG_MAX_AREA_TYPES && !done; ++area ) {
> if ( is_hole_area( area ) ) {
>
> and similarly in TGClipper::clip_all, with -
> for ( i = 0; i < TG_MAX_AREA_TYPES; i++ ) {
> if ( is_landmass_area( i ) && !m_ignore_landmass ) {
>
> and in some other places, and the functions like -
>
> bool is_hole_area( AreaType area ) {
> return get_area_descriptor( area ).kind==Hole;
> }
> bool is_landmass_area( AreaType area ) {
> const AreaKind kind = get_area_descriptor( area ).kind;
> return (kind==Landmass);
> }
>
> That means potentially the area value can range from 0 to 127,
> while not 'done', which will put the value beyond the 'size'
> of the vector area_types, which is filled from the contents
> of the parsing of -
> --priorities=priorities.txt
> file the user provided, or the default if none... which puts
> the area_types vector at only about 61, or so elements...
>
> SOMEHOW, the unix std vector implementation seems to let
> the out-of-range vector value continue without a problem,
> although I am sure what is returned is 'undefined', but
> not necessarily a NULL...
>
> That is, the returned 'undefined', in is_hole_area(area),
> for example -
> return get_area_descriptor( area ).kind==Hole
> does _NOT_ generate a segfault (SIGSEGV), as I think it
> should, but it will if you try to access the string part
> of such a non-existing out-of-range vector...
>
> Of course in Win32, it will generate an abort dialog
> if an out-of-range value is attempted to be extracted on
> a std vector, which I think is what should happen...
>
> My 'fix' for this was to return the 'Unknown' descriptor
> when 'area' was out of vector range, which works, but I
> do not know if this is the 'right' solution...
>
> There are other solutions, like even when the priorities
> text file is completed, the area_types vector is filled
> out with 'Unknown' repeated, until it has a size of
> TG_MAX_AREA_TYPES, which is 128 in the current build.
>
> Or this use of a fixed (defined) TG_MAX_AREA_TYPES is
> abandoned, and the loops are maximized to the
> area_types.size()... priorities.cxx could provide a
> function to return this vector 'size'...
>
> Below is the set of data I ran into this on, the
> priorities file, and the full command used...
>
> Seek help from other who may know the code better, to
> fix this out-of-vector-range problem in the tg-cs
> git repo...
>
> Regards,
>
> Geoff.
>
> The data set used on this test was (1184511 bytes) :-
> http://geoffair.org/tmp/work.tar.gz
> The priorities text file used :-
> http://geoffair.org/tmp/priorities.txt
> The full command used, in the /work folder :-
> fgfs-construct --priorities=priorities.txt \
> --output-dir=Terrain --work-dir=. --tile-id=2892641
> SRTM-30 Beach GrassCover MixedCropPastureCover Stream \
> DeciduousBroadCover Lake MudFlat ShrubCover Town \
> DryCropPastureCover Landmass Road Verge
>
> in both XP Win32, and Ubuntu 64-bit...
>
> PS: Fred, I also tested with your fgfs-construct.exe
> from Win32 20101002 zip, and it also aborted, but not
> sure this is the 'same' problem... although the abort
> is at the same place - after the output -
>
> loaded 2925 total polys
> clipping polygons
> Running master clipper
> (-3.75,51.5) (3.5,51.625)
>
>
>
>
>
> ------------------------------------------------------------------------------
> Beautiful is writing same markup. Internet Explorer 9 supports
> standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3.
> Spend less time writing and rewriting code and more time creating great
> experiences on the web. Be a part of the beta today.
> http://p.sf.net/sfu/beautyoftheweb
> _______________________________________________
> Flightgear-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
>
--
Curtis Olson:
http://www.atiak.com - http://aem.umn.edu/~uav/
http://www.flightgear.org -
http://www.flightgear.org/blogs/category/curt/<http://www.flightgear.org/blogs/category/personal/curt/>
------------------------------------------------------------------------------
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3.
Spend less time writing and rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb
_______________________________________________
Flightgear-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
