[GRASS5] Some news: KerGIS

[Thierry Laronde]

Hello Paul,

On Sat, Jan 24, 2004 at 05:37:57PM +0000, Paul Kelly wrote:
> 
> > 2.S Security
> >
> > G_gets has been replaced with the secure (newly created) G_read_line
> >
> > But the code remains unsafe, since there are a lot of sprintf spread all
> > around that don't limit nor check the amount of data they put in the
> > buffer
> > 	=> TODO
> >
> 
> Do you have an opinion on the G_asprintf() by Eric Miller that we use in
> GRASS 5.7?:
> 
> http://grass.itc.it/pipermail/grass5/2002-May/005324.html
> 
> http://freegis.org/cgi-bin/viewcvs.cgi/grass51/lib/gis/asprintf.c?rev=1.1&content-type=text/vnd.viewcvs-markup

No, no opinion since I have absolutely not looked of what has been done
(on a more general basis, when I have fixed the code and the program 
was not working as expected I have debug it my way and not try to look
at what had been done previously to correct the thing).

> 
> Also did you have a chance to have a good look at g.setproj (I see you
> have kept it; I wouldn't)? I always thought it seems to be quite badly
> written and had been done separately from v.proj and src/libes/proj,
> which apparently were done by SCS, and had been done quite well and
> consistently. I think the original idea was to create PROJ_INFO /
> PROJ_UNITS manually with a text editor and g.setproj (perhaps originally
> called m.setproj?) was added by somebody else.

As I have explained, _by principle_ I have kept all the programs
distributed by CERL throwing away duplicates, junk, multiple versions,
things that are useless to support now (hardware specific display
drivers, paint drivers, print management ---will be done with the system
tools) and, for programs for which I have some doubt if I will keep them
finally or not, I have been conservative UNLESS when I tried to fix 
the code (C syntactic correctness) I stumble on errors that made 
clear that the coder did not understand what he was doing.

Since I don't know if g.setproj will survive (and I know that there are
programs that I have fixed whose lifetime in KerGIS will be short) but I
had the average problems to fix it, it is still here.

There is another reason for this conservative approach.

For example, with the current v.digit in GNU GRASS, I have never been
able to digitize a non connected line, which leads to the chicken and
egg problem: if a line must be connected, I do you draw the first one?
BUT the original version of v.digit doesn't suffer from this: v.digit
issues a warning that the nodes are not connected, but the line is
created.

What I mean is that to have the complete overview, and to understand
what was the big picture and how things were meant to work together, we
need to see the original bare version. Relying on "features" of the
present programs, where people have blindy modified some things that may
have broken the whole, is dangerous.

For the PROJ library, I must say that I had a rough time with it at the
beginning. Since to track, generally, the uninitialized variables one
must read the code and the code must be reasonnably readable, I have
launched indent and on that particular library it was a disaster due to
the way it is coded.
I distate heartily the coding style and particularily the way the
pre-processor is used, but I must say that, from the strict C standard
point of view, this was a library that caused very little problems.

So my conclusions are that, even if I do not like the style, the 
programmer understood what he was doing (and for contributions not 
originating from CERL this is an assumption that do not generally 
holds...).

For g.setproj and v.proj they were both developped by the same guy from
SCS: M.L.Holko. So... we will have to wait to see the whole picture.

Cheers,
-- 
Thierry Laronde (Alceste) <tlaronde at polynum.org>
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C