All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kip Macy <kmacy@fsmware.com>
To: Keir Fraser <Keir.Fraser@cl.cam.ac.uk>
Cc: xen-devel@lists.sourceforge.net
Subject: Re: compile fixes for mini-os
Date: Sat, 24 Jan 2004 19:34:32 -0800 (PST)	[thread overview]
Message-ID: <20040124191918.I81692@demos.bsdclusters.com> (raw)
In-Reply-To: <E1Akamc-0005Tn-00@wisbech.cl.cam.ac.uk>

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

  reply	other threads:[~2004-01-25  3:34 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-01-24 21:39 compile fixes for mini-os Kip Macy
2004-01-25  1:00 ` Keir Fraser
2004-01-25  1:27   ` Kip Macy
2004-01-25  1:58     ` Keir Fraser
2004-01-25  2:07       ` Kip Macy
2004-01-25  3:17         ` Keir Fraser
2004-01-25  3:34           ` Kip Macy [this message]
2004-01-25  6:11             ` C qualifiers Keir Fraser

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20040124191918.I81692@demos.bsdclusters.com \
    --to=kmacy@fsmware.com \
    --cc=Keir.Fraser@cl.cam.ac.uk \
    --cc=xen-devel@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.