James Carlson wrote:
> Garrett D'Amore writes:
>
>>> So, with the putback for 6711665 we have a small
>>> binary incompatibility.
>>>
>>>
>> Ouch. How much of a concern is this (for this particular case)?
>>
>
> Here's a way in which it's a concern: meem rightly notes that the
> macros are ancient in origin (with the UCB warning label on ioccom.h).
> It's likely that it's used widely even if not documented, and that
> there are hidden overflows everywhere.
>
> If anyone compiles a driver on an older Solaris release (say, S10) and
> then delivers that driver with a header file defining the ioctls it
> provides in terms of the system sys/ioccom.h (rather than just rolling
> its own macros), then the user is set up for a fall.
>
> If the user installs this package on OpenSolaris, and then attempts to
> write an application that uses the supplied ioctl, it will fail
> because the system ioctl macros are different, and now get a different
> answer with the same constants.
>
> I'm at the edge of taking back my suggestion for #2. Either #1 or
> doing something quite different (such as defining a new set of _NEWIO*
> macros) might be necessary.
>
>
Very, very few drivers are likely to use this in a way that overflows, I
think. Yes, there could be a fall. We used to have the DDICT to
validate things, and the DDICT would have warned about this usage.
Yes, the headers exist since BSD heritage. (Notably Linux doesn't have
them, at least not in the same place.)
I'm actually leaning, given Meem's point that the ioctls in ON that are
at risk are about to be removed anyway, towards #3.
-- Garrett
_______________________________________________
opensolaris-code mailing list
opensolaris-code@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
