From: Scott Wood <scottwood@freescale.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] flash.h: pull in common.h for types
Date: Tue, 17 Nov 2009 18:01:25 -0600 [thread overview]
Message-ID: <4B033955.2050301@freescale.com> (raw)
In-Reply-To: <20091117215658.B70F7F51B12@gemini.denx.de>
Wolfgang Denk wrote:
> Dear Scott Wood,
>
> In message <4B031158.20501@freescale.com> you wrote:
>>> My question: is there a definitive position somewhere (for example
>>> for the Linux kernel; I'm sure we don't have one for U-Boot [yet]),
>>> whether system headers should be self-sufficient?
>> I'd say they should be self-sufficient, in that the inclusion of the
>> header itself should not fail if I haven't included some arbitrary other
>> header. I don't see what the argument would be for not doing this.
>
> Well, Theo de Raadt says for example "... people would be able to
> include less files; indeed, almost be careless about what they
> include. But this would not increase portability in any way. And
> 'make build' would probably, if it was taken the nth degree, take
> twice as long. Therefore there is no benefit for the crazy rule you
> suggest..." - see
> http://www.mail-archive.com/tech at openbsd.org/msg00425.html
Making the headers self-sufficient is not an excuse for the including C
file to not include everything it uses -- it just makes the C file not
have to care about other stuff in the header that it does not intend to
use, or which is a header implementation detail.
>> Which man pages are you looking at?
>
> Well, for example:
>
> open(2):
> SYNOPSIS
> #include <sys/types.h>
> #include <sys/stat.h>
> #include <fcntl.h>
>
> mknod(2):
> SYNOPSIS
> #include <sys/types.h>
> #include <sys/stat.h>
> #include <fcntl.h>
> #include <unistd.h>
>
> stat(2):
> SYNOPSIS
> #include <sys/types.h>
> #include <sys/stat.h>
> #include <unistd.h>
>
> Why do we need these lists of #includes? WHy doe - for example -
> <sys/stat.h> not auto-include anything it might need?
>
> To me this seems to be an indication that there is no intention to
> make headers self-sufficent, but I am absolutely not sure.
That is just listing the headers to include in order to have access to
all of the facilities described. However, any one of those headers
should be able to be included by itself without the inclusion alone
causing the build to fail. A quick test under Linux/glibc shows this to
be the case (i.e. no failures).
-Scott
next prev parent reply other threads:[~2009-11-18 0:01 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-11-16 19:58 [U-Boot] [PATCH] flash.h: pull in common.h for types Mike Frysinger
2009-11-16 21:31 ` Wolfgang Denk
2009-11-16 22:03 ` Mike Frysinger
2009-11-17 21:00 ` Wolfgang Denk
2009-11-17 21:10 ` Scott Wood
2009-11-17 21:56 ` Wolfgang Denk
2009-11-18 0:01 ` Scott Wood [this message]
2009-11-18 0:18 ` Mike Frysinger
2009-11-18 1:34 ` J. William Campbell
2009-11-18 22:28 ` Wolfgang Denk
2009-11-18 23:43 ` Mike Frysinger
2010-01-18 1:52 ` Mike Frysinger
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=4B033955.2050301@freescale.com \
--to=scottwood@freescale.com \
--cc=u-boot@lists.denx.de \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox