I''m compiling the mini-os files in the FreeBSD build environment which uses the following extra flags: -Wcast-qual -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wpointer-arith -Winline -ansi This produces a number of annoying warnings which are fixed by the attached patch. In addition the sabon.sty doesn''t exist in my environment - I was able to comment it out in style.tex any apparent ill effect.
> I''m compiling the mini-os files in the FreeBSD build environment which > uses the following extra flags: > > -Wcast-qual -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wpointer-arith -Winline -ansi > > This produces a number of annoying warnings which are fixed by the > attached patch. In addition the sabon.sty doesn''t exist in my > environment - I was able to comment it out in style.tex any > apparent ill effect.Okay, I guess that relying on the sabon package is a bad idea. Also thanks for the C++ comment-style fixes. Personally I dislike the warnings GCC emits when it''s placed in super-anal mode. I would never take fixes for Xen or Xenolinux to stop those warnings since I think GCC should be run with a more permissive set of options. For the mini-os I''ll give the patches some thought. I guess it''s being used as a starting point for ports that may use a different compiler or have a predetermined set of command-line options, so perhaps it makes sense... -- Keir PS. Please send your documentation updates when you think it''s worthwhile. They''ll be vey useful! . ------------------------------------------------------- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
I''ve attached the full diff as well as interface.tex. I sent interface.tex to Ian, but haven''t got any ack back.> Personally I dislike the warnings GCC emits when it''s placed in > super-anal mode. I would never take fixes for Xen or Xenolinux to stop > those warnings since I think GCC should be run with a more permissive > set of options.I admit that many of the options are just plain annoying. However, in one instance you were casting away volatile, which could get you in trouble. There are more mundane problems that could cause issues, such as signed/unsigned comparisons. I would argue that you might as well never use the const qualifier if you''re just going to cast it away in most cases. In addition you frequently do pointer arithmetic with void pointers, you''re just relying on the compiler to know that you really mean char pointer. The changes to inline usage are neccessary to get the code to compile at all with -ansi.> For the mini-os I''ll give the patches some thought. I guess it''s being > used as a starting point for ports that may use a different compiler > or have a predetermined set of command-line options, so perhaps it > makes sense...Your point is taken for Xen. However, a lot of environments are more restrictive, so it would be a service to users to accomodate them in that respect.> PS. Please send your documentation updates when you think it''s > worthwhile. They''ll be vey useful! > .It is pretty incomplete as things stand, but it might provide a sufficient start so that others would feel happy adding a bit here and there as the pieces fall into place for them.
> > Personally I dislike the warnings GCC emits when it''s placed in > > super-anal mode. I would never take fixes for Xen or Xenolinux to stop > > those warnings since I think GCC should be run with a more permissive > > set of options. > > I admit that many of the options are just plain annoying. However, in > one instance you were casting away volatile, which could get you in > trouble.Hmmm... volatile generally gets sprinkled round like magic dust. I''m not convinced it''s usually needed.> There are more mundane problems that could cause issues, such > as signed/unsigned comparisons. I would argue that you might as well > never use the const qualifier if you''re just going to cast it away in > most cases. In addition you frequently do pointer arithmetic with void > pointers, you''re just relying on the compiler to know that you really > mean char pointer. The changes to inline usage are neccessary to get > the code to compile at all with -ansi.I''ll give the fixes a look - probably when I get back to Cambridge in teh middle of next week. I''ll probably take them all for the mini-os - I''ll have a think about whether any of the warning options should be added to Xen as well. -- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
> > Hmmm... volatile generally gets sprinkled round like magic dust. I''m > not convinced it''s usually needed.Looking closer at the code, it looks like gcc is just being dumb about the context. The overhead of using -Wcast-qual and most of the others probably isn''t worth it. The one that is probably worth having for Xen, if only because doing arithmetic on void pointers seems like blatantly bad form, is -Wpointer-arith.> > I''ll give the fixes a look - probably when I get back to Cambridge in > teh middle of next week. I''ll probably take them all for the mini-os - > I''ll have a think about whether any of the warning options should be > added to Xen as well. >Thanks. -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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
> > > > Hmmm... volatile generally gets sprinkled round like magic dust. I''m > > not convinced it''s usually needed. > > Looking closer at the code, it looks like gcc is just being dumb about > the context. The overhead of using -Wcast-qual and most of the others > probably isn''t worth it. The one that is probably worth having for Xen, > if only because doing arithmetic on void pointers seems like blatantly > bad form, is -Wpointer-arith.Actually, I''ve looked at and applied your patch just now. 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). The only two possible exceptions are -Wcast-qual and -Wnested-externs. I like being able to make extern declarations in function scope (it''s for when I''m too lazy to place it in a sane header file, and it indicates that only one function needs to be fixed up if I ever want to do the declaration properly). I could perhaps live without that though... 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 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. -- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
> > 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
> > 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel