jiro@shaman.com (Jiro Nakamura) (02/25/91)
Hiya -
As you all know, I've been working with the sg driver for
some while. There's a bug/typo in one of the declarations in
/usr/include/nextdev/scsireg.h that might cause some problems for
people wanting to use the sg driver.
The bug/typo is in the file scsireg.h. On System 1.0, it is
on line 283, on System 2.0-extended, it is on line 253. The line
reads:
char ir_revision[32]; /* revision level info in
ascii */
The "32" is the typo. Of course the ir_revision is not 32
bytes long. If you check the SCSI Manual, it is 32 *bits* long, or 4
bytes. Thus, it should be declared:
char ir_revision[4];
or
char ir_revision:32;
Any program which depends on the structure in which this
definition is defined may crash when it overruns it buffer length.
Please beware of this bug.
Oh, a plug for myself. My program SCSIInquirer, which is on
nova.cc.purdue.edu and cs.orst.edu defines the class <SCSI> which
gives an object-orientated interface to the sg driver. It also
contains some good source code for anyone interested in programming
at the device level.
- Jiro Nakamura
jiro@shaman.com
ps. I've already reported this to bug_next and it's being tracked
(hopefully/apparently).
-------
Jiro Nakamura jiro@shaman.com
Shaman Consulting (607) 253-0687 VOICE
"Bring your dead, dying shamans here!" (607) 253-7809 FAX/Modemjiro@shaman.com (Jiro Nakamura) (02/26/91)
In article <9102241804.AA01402@shaman.com> I write: > [There's a bug in the scsireg.h file] Well, Doug Mitch (he wrote the SCSI drivers for NeXT) wrote back today and said, that's not a bug, that's a feature. :-) (Well, not those words exactly). Yes, ir_revision is supposed to be 4 bytes in the standard, but there can be bytes that follow it adding additional information that is not specified in the standard. His rational for having it 32 bytes long was so that we (developers) could easily read that extra info. My question is why not provide an additional character array after ir_revision to allow that? That would be more intuitive, and quieten smart- (or dumb-) alecks like myself. Oh well. - Jiro Nakamura -- Jiro Nakamura jiro@shaman.com Shaman Consulting (607) 253-0687 VOICE "Bring your dead, dying shamans here!" (607) 253-7809 FAX/Modem