WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

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