mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Vegard Nossum" <vegard.nossum@gmail.com>
To: "Andreas Schwab" <schwab@suse.de>
Cc: "Robert P. J. Day" <rpjday@crashcourse.ca>,
	"Jan Engelhardt" <jengelh@computergmbh.de>,
	axboe@kernel.dk,
	"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
	"Christoph Hellwig" <hch@infradead.org>
Subject: Re: [PATCH] Include header required for INT_MAX
Date: Mon, 12 Nov 2007 13:57:04 +0100	[thread overview]
Message-ID: <19f34abd0711120457x720f0ac8q9d6d0632e6a970fb@mail.gmail.com> (raw)
In-Reply-To: <je1wav3bxh.fsf@sykes.suse.de>

On Nov 12, 2007 1:06 PM, Andreas Schwab <schwab@suse.de> wrote:
> "Robert P. J. Day" <rpjday@crashcourse.ca> writes:
>
> > On Mon, 12 Nov 2007, Andreas Schwab wrote:
> >
> >> Jan Engelhardt <jengelh@computergmbh.de> writes:
> >>
> >> > No, because I be damn sure that some developers try compiling programs
> >> > in non-linux environments (cygwin, solaris, andyourpersonaldistro, you
> >> > name it) which do not have to adhere to <limits.h>. It might use
> >> > <cosmiclimits.h> instead, or whatever.
> >>
> >> Every C compiler has <limit.h>.
> >
> > i'm assuming you mean <limits.h>, no?
>
> Yes, sorry for the typo.

This seems like a good time to ask why the kernel doesn't use
<stdint.h> for its INT_MAX and type definitions like uint32_t., etc.
>From the manpage: "The <stdint.h> header is a subset of the
<inttypes.h> header more suitable for use in freestanding
environments, which might not support the formatted I/O functions. In
some environments, if the formatted conversion support  is  not
wanted,  using this header instead of the <inttypes.h> header avoids
defining such a large number of macros."

limits.h, on the other hand, seems to define a lot of
userspace-related things like ARG_MAX, ATEXIT_MAX. Or BC_BASE_MAX
(Maximum obase values allowed by the bc utility.). Which have nothing
to do with the kernel at all.

So even though another header is mentioned (inttypes.h), the argument
in favour of using stdint.h still holds; it defines the subset of
macros/types that is suitable in a freestanding environment (i.e. the
kernel).

Vegard

  reply	other threads:[~2007-11-12 12:57 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-11-11 22:52 Jan Engelhardt
2007-11-12 10:21 ` Peter Zijlstra
2007-11-12 10:46 ` Andreas Schwab
2007-11-12 10:51   ` Robert P. J. Day
2007-11-12 12:06     ` Andreas Schwab
2007-11-12 12:57       ` Vegard Nossum [this message]
2007-11-12 13:37         ` Jan Engelhardt
2007-11-12 20:50 ` Mike Frysinger
  -- strict thread matches above, loose matches on Subject: below --
2007-11-10 14:55 Thomas Koeller
2007-11-10 15:56 ` Christoph Hellwig
2007-11-11  0:52   ` Thomas Koeller
2007-11-10 16:48 ` Alexander E. Patrakov

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=19f34abd0711120457x720f0ac8q9d6d0632e6a970fb@mail.gmail.com \
    --to=vegard.nossum@gmail.com \
    --cc=axboe@kernel.dk \
    --cc=hch@infradead.org \
    --cc=jengelh@computergmbh.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rpjday@crashcourse.ca \
    --cc=schwab@suse.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

all inboxes | Powered by JetHome®