Bug in prefix hierarchy handling?

[Olly Betts]

On Fri, Jan 16, 2004 at 03:53:57PM +0000, Martin Green wrote:
> Given that the err file is produced correctly, I suspect that caverns 
> internal knowledge of the station names is fine. The problem is caused by 
> the code that writes/reads the 3d file. In doing this to save file space it 
> does not record the full name of every station. Instead at has a binary 
> number just before writing the text bit, there are various things this 
> number can mean, such as delete n characters or delete up to a full stop n 
> times. Something may have been wrongly implemented with the meanings of 
> these numbers.

This is correct - there's an off by one error in decoding which
manifests itself only very rarely.  So the file generated by cavern is
correct - the code which reads the file into aven, 3dtopos, etc is
wrong.

Thanks for finding the smaller test case Dave - it was very useful in
helping track down the problem quickly.

> I suspect it is the long names and multiple levels of hierarchy that has 
> caused this bug to come to light.

Pretty much - it'll only strike when more than 17 characters need
removing to get to the next name, and then only if the 17th character
from the end is a dot.

> Olly recently wrote a file specification of the 3d file, although I am
> not sure where it can be found.

http://cvs.survex.com/*checkout*/survex/doc/3dformat.htm?rev=HEAD&content-type=text/html

Cheers,
    Olly