Re: [Xen-devel] compile fixes for mini-os

[Kip Macy <kmacy@xxxxxxxxxxx>]

>
> Actually, I've looked at and applied your patch just now.

Cool. That was a lot faster than "the middle of next week" :-).

>
> I think that most of the warnings options may be sane for Xen
> (especially once the crufty Linux devuce drivers have been moved out
> of teh code base).

Good.

> live without that though...

I'm not actually sure what is wrong with the nested extern declaration.
In general I think externs are a sign of sloppiness (to which I'm in no
way immune). However, if one is going to use them, I don't see what is
wrong with putting them right where one needs them.

>
> However, -Wcast-qual really sucks. I haven't even added it to the
> mini-os! Anything which makes it impossible to implement Standard C
> functions (eg. strstr()) without causing compiler warnings is just
> plain wrong!

I think one needs to be able to exempt functions from checking just
as one can with lint. For example, lint checks that if a function
returns a value, any caller should check the return value. "printf"
returns an int, *no one* does or should check the value of printf.
In the absence of such a facility I'm willing to let casting issues
slide.

>
> 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.


Thanks Keir. I hope that shortly I will be contributing something more
than just compiler warnings ;-).


                                        -Kip


-------------------------------------------------------
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