public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
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

  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