[BRLTTY] A bug in revision 3008-09 of version 3.8dev?

Nicolas Pitre nico at cam.org
Mon Apr 30 14:52:48 EDT 2007


On Mon, 30 Apr 2007, Dave Mielke wrote:

> [quoted lines by Nicolas Pitre on 2007/04/30 at 12:00 -0400]
> 
> >Better yet, the BRLTTY version could be stored in every dynamically 
> >loaded drivers and BRLTTY refuse to use them if the version doesn't 
> >match.  This is the best way to avoid mysterious bug reports like this 
> >one was.
> 
> I like this aproach the best as it's automatic and doesn't require human
> guesswork. Perhaps, though, brltty should issue a warning rather than an error
> just in case it'll keep on running well enough for the user to read it.  This
> should be okay as long as we ensure that the mismatch is logged before any code
> within the dynamic object is executed.

Agreed.

> The nicest way would be to store a true string, i.e. a pointer to a string of
> variable length. This may cause a new core with old drivers (which don't yet
> provide whis data) to crash, though, so do you think we should resort to a
> fixed-length field to store the version number?

No, I'd use a simple zero terminated string.

The new core with old drivers won't be able to locate the version string 
with dlsym() hence it should be considered as non matching.

> Do you think there's any reason to retain the current driver version numbers? 
> They aren't really being maintained properly anyway (finger pointing at
> myself). Maybe we should just store brltty's version in that already-existing
> field (which is a real string).

Ah, hmm, no.  I didn't mean the existing driver version string at all. I 
really mean to have a separate symbol automatically added to each 
dynamically loaded driver pointing to that string with the global BRLTTY 
version.  And that string may not only be "BRLTTY version 3.8" but it 
should also include the svn revision number as reported by svn during 
the build process, like $(svn info | sed -ne 's/^Revision: //p') as well 
to be safe.  It would need to be autogenerated and included in the .tgz 
distribution of course.


Nicolas


More information about the BRLTTY mailing list