Garrett D'Amore writes:
> Piotr Jasiukajtis / estibi wrote:
> > Since I hit a little deeper with the changes I have a question...
> > What functions I just shouldn't touch in order to not break the
> > compatibility with drivers?
> >
>
> In general, any *argument* to a function can be made const char *
> (assuming that it isn't modified), but I'd avoid changing any function
> return from char * to const char * if they are part of the DDI.
That's not quite true.
There are two separate issues here: run time and compile time.
Changing a return value from 'char *' to 'const char *' has no effect
on run time -- the same old binaries will still work -- so it's not
the sort of compatibility issue that causes a stop-all-work bug.
Instead, it causes warnings or errors at compile time. And,
presumably, there's a human involved somewhere during compile time,
and (at least in the normal Solaris software development and
distribution model, unlike the Linux one) that human is a developer of
some sort.
For that reason, I'd be a bit more lenient on cleaning up DDI
functions, and would allow reasonable fixes. If there was no
legitimate way that the calling function could have changed the
returned storage, then making it const may well be a good thing,
particularly in a Minor release. (Doing that in a patch/micro
release, though, would likely be wrong.)
Some other things to consider:
- Use the 'restrict' keyword when the function has multiple pointer
arguments and there's no way the pointers could (or should) refer
to the same storage.
- Don't use 'const' with non-pointer arguments. It's silly there.
- Be very careful with 'const', because it doesn't always mean what
you think it means, or work the way you probably think it should.
On that last point, see CR 4526778. I had a *long* discussion with
the compiler guys about this one before eventually getting that they
were right and that the language is just weird. In other words, this
works in C:
const char *foo;
char *bar;
foo = bar;
but this does not:
const char **foo;
char **bar;
foo = bar;
Explaining why is beyond the scope of this posting. ;-}
> (As a general rule, if the the function has a man page, then its return
> value shouldn't be changed. If it doesn't have a man page, then its
> probably only internal to ON and it should be fine.) If you provide a
> list of candidate functions, I can review them.
If it has a man page, you can presume that it's Committed (unless
specified otherwise), and that changing it will require some minor
paperwork.
If it doesn't have a man page, it's generally Consolidation Private
and can be changed without notice ... unless the lack of a man page is
actually an oversight. So do be careful, and apply some reason to it.
--
James Carlson, Solaris Networking <[EMAIL PROTECTED]>
Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
_______________________________________________
opensolaris-code mailing list
opensolaris-code@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
