[GRASS5] [PATCHES]: pg.in.dbf

[Paul Kelly]

In the absence of any comment from the original author I think we should
go ahead and apply Thierry's patches so they can be tested. The only thing
I would be concerned about is that there are maybe parts that should also
be applied to GRASS 5.7 if it perhaps shares some of this code? I am not
familiar with this part of GRASS so I can't comment.

I get a feeling the patches are a big improvement on the current pg.in.dbf
so I will go ahead and apply them in a few days if nobody objects.

Paul

On Sun, 12 Oct 2003, Thierry Laronde wrote:

> Hello,
>
> I have fixed several problems and made ---I think--- some improvements.
> Some bugs were serious ones. In particular, the `init' function in
> pgdump.c was not initializing correctly a structure causing random
> data to be passed to PG.
> I have not looked in the bug base, but these should close some bugs
> referenced there.
>
> Here is the ChangeLog :
>
>
> main.c:
> 	- Added option to set the DELIMITER to a user defined character
> 	value (only used for super-user when using COPY command);
> 	-> Now PgDumpFromDBF takes 3 arguments: filename, mode and delimiter
> 	- PgDumpFromDBF proto removed from main.c and added to
> 	pgdump.h;
> 	- include <string.h> for strlen
> 	- include "pgdump.h" for PgDumpFromDBF proto
> 	- Default delimiter now changed to '\t';
> 	- Suppressed bogus parm structure ;
> 	- no_rattle -> normal_user: more explicit, match PgDumpFromDBF and
> 	... well the way the assignement was made was queer: changed too!
> 	- Added comments
>
> pgdump.h:
> 	- created for PgDumpFromDBF proto
>
> pgdump.c:
> 	-XXX in the `init' function used to initialize the my_string struct
> 	the initial string pointed to by the data member was not initialized
> 	to NULL.
> 	Hence, the use of the function `append', not taking into account
> 	the length of the string and using `strcat' directly concatenated
> 	the random data found where my_string.data was pointing until it
> 	found some '\0'
> 	=> Now my_string.data points to a null string at initialization;
> 	- include "pgdump.h" for PgDumpFromDBF proto
> 	- modified PgDumpFromDBF: now takes 4 arguments:
> 		filename, normal_user, delimiter, null_string
> 	- modified DBFDumpASCII: now takes 3 arguments:
> 		DBFHandle, File pointer, delimiter
>
> -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 that
> 	was read not written_ 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".
>
>
> Cheers,
> --
> Thierry Laronde (Alceste) <tlaronde at polynum.org>
> Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C
>