Re: [Xen-devel] C qualifiers

[Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>]

> > I guess there's a philosophical argument about which is wrong (the
> > StdC definition of 'const' or the StdC definition of 'strstr') but
> > basically I'd like to keep the usual prototype for th estring
> > functions but not have to suffer compile warnings :-) 'const' and
> > 'volatile' are both difficult to use sanely -- I try to avoid them
> > wherever possible.
> 
> I think const is a perfectly usable construct. It is great for
> allowing the compiler to check that functions that are supposed to
> treat their inputs as immutable, do in fact not mutate them. I think
> the StdC function definitions are braindead. How is it that you can
> pass in an immutable reference to a function and then have that function
> return a mutable reference to the same data? That doesn't make *any*
> sense to me. If someone can explain the rationale behind it, I'm happy
> to listen.

Right. The string functions shouldn't be const-qualifying their
parameters. Unfortunately 'const' is so sticky that when you start
applying it to function parameters then it starts to proliferate
within your program --- I think it creates more hassle than it could
possibly save. If you could squash 'const' when computing a return
valkue then that would be very useful -- essentially trust the caller
to know what they're doing and only write via the return value if the
passed in a mutable argument.

'volatile' has similar problems and it's broken to use
it in portable programs anyway (and often broken even in non-portable
programs, if the program is multithreaded [since the CPU can reorder
volatile memory accesses, even though they were emitted in the correct
order by the compiler]).

 -- Keir


-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel