[GRASS5] [5.0][PATCH]pg.in.dbf/dbfopen.c: fix weird filenames acrobatics

Hello,

In dbfopen.c, the filename of the DBF file supposed to be opened was
subject of extension changes, `strcmp' being used as if it was a
matching function returning 0 if failed or not zero on success. And indeed
this is almost exactly the contrary.
Furthermore, the combination of two conditions made the first test succeeds
in all cases, transforming every extension in ".dbf".

Last but not least, _without renaming or copying the file_ this was this
modified version of the filename that was given to `fopen' resulting in a
failure in every case except when the change to ".dbf" was a null one, that
is when the filename was already ending with ".dbf".

The patch removes the offending stuff.

Cheers,

PS0: please don't be upset by the tone of the comments: I have the very
same with my own errors, and I make a lot of these. This is just aimed to
be matter of fact and descriptive.

PS1: I'm still working on the 5.0 [5.3] branch since I have installed it
at my work and have some job to be done without changing everything at the
moment.

PS2: I have downloaded 5.7 and started to look at the new vector format (and
will ask some questions/give some suggestions hopefully in the next days).

PS3: to avoid problem, when I work on GRASS by itself, I make it during my
spare time to be sure that I own all the copyrights of my work and can
give/share them with the project (I'm not officially hired for doing
programming, so during my spare time I'm sure my boss can claim strictly
nothing). This can explain why I will make apparitions only from time to
time).
--
Thierry Laronde (Alceste) <tlaronde@polynum.org>
Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C

(attachments)

patch-src::src.garden::grass.postgresql::pg.in.dbf::dbfopen.c (2 KB)

On Sun, Sep 14, 2003 at 04:54:23PM +0200, Thierry Laronde wrote:

In dbfopen.c, the filename of the DBF file supposed to be opened was
subject of extension changes, `strcmp' being used as if it was a
matching function returning 0 if failed or not zero on success. And indeed
this is almost exactly the contrary.
Furthermore, the combination of two conditions made the first test succeeds
in all cases, transforming every extension in ".dbf".

Last but not least, _without renaming or copying the file_ this was this
modified version of the filename that was given to `fopen' resulting in a
failure in every case except when the change to ".dbf" was a null one, that
is when the filename was already ending with ".dbf".

The patch removes the offending stuff.

Sound reasonable,
but others have to judge this from the technical point of view.
I'm not sure how actively used the src.garden submodule actually is.

PS0: please don't be upset by the tone of the comments: I have the very
same with my own errors, and I make a lot of these. This is just aimed to
be matter of fact and descriptive.

No problem at all.
As for a development list we can talk right down to the technical features.

PS1: I'm still working on the 5.0 [5.3] branch since I have installed it
at my work and have some job to be done without changing everything at the
moment.

Perfectly fine.
That is what this branch is for.

PS2: I have downloaded 5.7 and started to look at the new vector format (and
will ask some questions/give some suggestions hopefully in the next days).

Your suggestions, questions and remarks are very welcome.

PS3: to avoid problem, when I work on GRASS by itself, I make it during my
spare time to be sure that I own all the copyrights of my work and can
give/share them with the project (I'm not officially hired for doing
programming, so during my spare time I'm sure my boss can claim strictly
nothing). This can explain why I will make apparitions only from time to
time).

Sounds like a good strategy to me,
happy hacking,
  Bernhard

On Mon, Sep 15, 2003 at 11:26:31AM +0200, Bernhard Reiter wrote:

On Sun, Sep 14, 2003 at 04:54:23PM +0200, Thierry Laronde wrote:

[..]

>
> The patch removes the offending stuff.

Sound reasonable,
but others have to judge this from the technical point of view.
I'm not sure how actively used the src.garden submodule actually is.

The use I have for this, and I think others, is not really to import
DBF in PostgreSQL directly, but simply to be able to retrieve the
information of a DBF file given by a ArcView user (and I don't want
to use MS/Excell simply to dump to text).

Thanks for the comments Bernhard,
--
Thierry Laronde (Alceste) <tlaronde@polynum.org>
Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C