yakra / tmtools

Tools to aid in development of the TravelMapping project
0 stars 0 forks source link

DBFtrim info display: newline on zero-length fields #1

Closed yakra closed 6 years ago

yakra commented 6 years ago

Newline on zero-length fields messes up the rest of info display.

A simple IF at the last cout, to check for a null pointer, should be enough to fix this. ...Or perhaps more elegantly, if (!MaxVal) MaxVal = (char*)"\0"; in GetMax

However, there was odd behaviour here before, even back... • when MaxVal was a pointer to a null (terminator) char, rather than a null pointer (was it though?) • when MaxVal was returned to main() from FindMax(), rather than stored in field reserved bytes

I'd like to take a deeper look into the origins and history of this bug.

yakra commented 6 years ago

20171031a & 20171030e:

yakra@BiggaTomato:~/proj/chm/DBFtrim$ ./a.out Station-Length.dbf mass.dbf 

Station-Length.dbf opened.
DBF Filesize:   58349017 (sanity check borderline; may be missing terminal 0x1A)
Number Records: 0x87ab8 555704
Header Length:  0x61    97
Record Length:  0x69    105
First char: 0x3 3
Final char: 0x30    48
2 fields:
FieldName   Type    Length  Max Data
Station     C   80  0   yakra@BiggaTomato:~/proj/chm/DBFtrim$

• because oDBF.fArr[i].MaxVal is a null pointer • because MaxVal never gets set to value • because strlen(value) is never greater than 0

This holds true for both versions of the code, with both GetMax and FindMax.

yakra commented 6 years ago

20171030d & 20171030, presumably everything in between:

yakra@BiggaTomato:~/proj/chm/DBFtrim$ ./a.out Station-Length.dbf mass.dbf

Station-Length.dbf opened.
DBF Filesize:   58349017 (sanity check borderline; may be missing terminal 0x1A)
Number Records: 0x87ab8 555704
Header Length:  0x61    97
Record Length:  0x69    105
First char: 0x3 3
Final char: 0x30    48
2 fields:
FieldName   Type    Length  Max Data
Station         C       80      0       x{�ی                                   
Length      N   24  24    <Type N fields unsupported>

• data changes, but last char always seems to be 007F • because *oMaxVal = new char[len+1]; never written to • because strlen(value) is never greater than 0

yakra commented 6 years ago

20171026 & 20171029, presumably everything in between:

yakra@BiggaTomato:~/proj/chm/DBFtrim$ ./a.out Station-Length.dbf mass.dbf

Station-Length.dbf opened.
DBF Filesize:   58349017 (sanity check borderline; may be missing terminal 0x1A)
Number Records: 0x87ab8 555704
Header Length:  0x61    97
Record Length:  0x69    105
First char: 0x3 3
Final char: 0x30    48
2 fields:
FieldName   Type    Length  Max Data
Station     C   80  0   
Length      N   24  24    <Type N fields unsupported>

...consistently thru several trials Why does this actually look OK? • FindMax code is the same between 20171029 & 20171030. MaxVal is created here, and returned. • The only difference is indentation, and function definition inside/outside of the field class • Standalone FieldArray, vs. a member of the DBF class, should not make any difference • WTF

yakra commented 6 years ago

Fixed in b38e014bce7a7b928ec0d22b2a544d4bd17fd945. While it bothers me that I can't explain why the first three code versions' output looked fine, the scenario of the uninitialized char array no longer exists (replaced by the null pointer scenario, which is now fixed). There being nothing left to fix here, I'm closing this issue, historical unsolved mystery notwithstanding.