From: Dave.Martin@arm.com (Dave Martin)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH] ARM: add workaround for ambiguous C99 stdint.h types
Date: Fri, 9 Aug 2013 15:30:39 +0100 [thread overview]
Message-ID: <20130809143039.GD3977@localhost.localdomain> (raw)
In-Reply-To: <CAKv+Gu9TMDdyvZ=1fqRQQq_7Sz7hxWBbHqnF_mbVhh5uqJgTJg@mail.gmail.com>
On Fri, Aug 09, 2013 at 04:18:30PM +0200, Ard Biesheuvel wrote:
> On 9 August 2013 16:14, Dave Martin <Dave.Martin@arm.com> wrote:
> > On Fri, Aug 09, 2013 at 09:36:42AM +0200, Ard Biesheuvel wrote:
>
> [...]
>
> > Somebody else might have the opposite problem to ARM, so I'm doubtful
> > about whether it's safe to do this for all arches. The arch maintainers
> > would have to comment on that. This looks ugly in an otherwise generic
> > header.
> >
>
> This is actually under arch/arm so that should not be a problem. In
> fact, it's a copy of asm-generic/types.h with just the #defines added.
Duh. Misread your patch, sorry about that.
> > (As a cosmetic thing, you can lose the #ifdefs. #undef doesn't trigger
> > an error of the specified macro doesn't already exist.)
> >
>
> I am aware of that, but I think it is cleaner not to pollute the
> namespace if the defines weren't there to begin with.
Ah, I see what you mean. Yes, that makes sense. I'd read the #ifdefs
as just being there to avoid redefinition errors.
I'll leave the thread for other people to comment, but this looks like
a reasonable thing to do for now.
Because the kernel is not a hosted C environment, we shouldn't be including
any foreign headers which care about the distinction, except for GCC's own
headers like arm_neon.h.
Cheers
---Dave
next prev parent reply other threads:[~2013-08-09 14:30 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-09 7:36 [RFC PATCH] ARM: add workaround for ambiguous C99 stdint.h types Ard Biesheuvel
2013-08-09 14:14 ` Dave Martin
2013-08-09 14:18 ` Ard Biesheuvel
2013-08-09 14:30 ` Dave Martin [this message]
2013-08-13 18:33 ` Ard Biesheuvel
2013-08-13 23:33 ` Nicolas Pitre
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=20130809143039.GD3977@localhost.localdomain \
--to=dave.martin@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
/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;
as well as URLs for NNTP newsgroup(s).