[GRASS-dev] [GRASS-SVN] r60054

[Glynn Clements]

Huidae Cho wrote:

> Why don't we keep an array of Map_info only internally (private to
> libvect), just like R__.fileinfo, and use an integer map descriptor at high
> level? Then we can implement accessor functions, only through which high
> level routines can read/write map properties.

It doesn't necessarily have to be an integer (although that would
avoid the issue of code bypassing the accessor functions and
dereferencing the pointer locally).

The fact that an integer is used for raster maps is largely a
historical accident. Prior to 7.0, the "descriptor" was the actual
file descriptor of the cell/fcell file (hence the common use of the
name "fd" for the variable holding the descriptor). As file
descriptors are small, non-negative integers, this could be (and was)
used as the index into a table which held other information about the
map.

In 7.0, the "descriptor" is only the index into the table
(R__.fileinfo[fd]). The actual file descriptor for the cell/fcell file
is stored in R__.fileinfo[fd].data_fd. This avoids wasting a slot for
each open file which isn't a raster map's cell/fcell file.

> > > which in turn sounds like something for GRASS 8.
> >
> > FWIW, the first 6.0 beta was tagged on 2005-01-12, i.e. over 9 years
> > ago. Unless there's a reason to believe that 7.0->8.0 will happen
> > somewhat quicker than 6.0->7.0, 8.0 is too long to wait.
> 
> I think it all depends on how we want to change the vector lib. IMHO, only
> adding an array of open Map_infos would not be very invasive, but
> synchronizing with librast (e.g., using a map descriptor and hiding
> Map_info) would take a lot more work and need to wait until 8.0.

Provided that modules (or higher-level libraries) don't try to do
anything unexpected with the Map_info structures, we could just keep a
table of pointers.

Problems only arise if code does something like passing in a pointer
to one structure when opening a map, copying it, then passing in a
pointer to the copy when closing it. With the existing API, this would
probably work.

I find it hard to envisage code actually doing that, but it's not
something which could easily be checked statically (i.e. by analysing
the code). We'd have to implement the internal table-of-pointers, add
code to check that any Map_info pointers passed to other functions
were already in the table, then run tests (or rely upon the users
reporting any warnings).

-- 
Glynn Clements <glynn at gclements.plus.com>