[GRASS-dev] svn access

[Radim Blazek]

On Mon, May 18, 2009 at 9:53 AM, Hamish <hamish_b at yahoo.com> wrote:
>> > should the real fix be "alloc += GMAPSET_MAX"?
>>
>> I dont think so, dynamic allocation is used.
>
> ok, right. G_store() calls G_malloc() to hold the actual mapset name
> using dynamic length.

I mean the array of pointers to mapset names.

>> > or to modify/fix the header comments to say that the pointer will
>> > be null if the location dir can't be opened or no mapsets are found?
>>
>> No, it says 'zero terminated array' so it should not be changed now so
>> that it can return NULL, I think.
>
> but before your patch it *did* return NULL if the location dir was not
> found, or no viable mapsets were found. So the code and the header docs
> are in disagreement, and perhaps somewhere in the code expects to test for
> that NULL?

You are right, with the patch was fixed both possible missing NULL and
the disagreement, ie. NULL instead of array.

> if it is allowed to return null, then there is no need to init the alloc
> to 50 until the original n+2>alloc test later on.

Yes but I wanted to do what doc says, that means to return an array always.
At least QGIS does not test if NULL is returned. Normaly it should never happen
because we have at lest PERMANENT, but I thought that in future the structure
of GRASS files/database can change and locations with no mapsets will
be allowed.

So the possibility it returned NULL was just another bug which should
never be executed.

> the final mapset's name-string will always be null terminated by the
> strcpy() in G_store(), so there will always be a \0 at the end of the
> actual data, but the **mapsets list would rely on the G_realloc() += 50
> elements list to be filled with zeros. And since there is no associated
> number_of_mapsets integer to test against, to find the end of the array
> a bit of code would need to scan until it sees two consecutive nulls.
> right?

It returns a pointer to an array of pointers to strings.

Radim