From: Jes Sorensen <Jes.Sorensen@redhat.com>
To: malc <av1474@comtv.ru>
Cc: Blue Swirl <blauwirbel@gmail.com>, qemu-devel <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] [PATCH 2/5] CODING_STYLE: add C type rules
Date: Tue, 17 Aug 2010 21:43:33 +0200 [thread overview]
Message-ID: <4C6AE665.7090502@redhat.com> (raw)
In-Reply-To: <alpine.LNX.2.00.1008172324090.1756@linmac>
On 08/17/10 21:24, malc wrote:
> On Tue, 17 Aug 2010, Jes Sorensen wrote:
>
>> On 08/17/10 20:55, malc wrote:
>>> On Tue, 17 Aug 2010, Blue Swirl wrote:
>>>>> The other thing that might be worth mentioning in the int/long section
>>>>> is that long is complicated in broken development environments such as
>>>>> Windows where it is only 32 bit :(
>>>
>>> There's absolutely nothing broken about LLP64 it's as valid as any other
>>> ABI. (That's to Jes)
>>
>> Well it works if you program for it, but it still doesn't make it any
>> good when you can't keep a pointer in a long to apply arithmetic to it.
>> Anyway point with the documentation is to make it clear that we rely on
>> being able to do long foo = (long)ptr;
>
> Which isn't (and never was) sanctioned by any standard, IOW not good.
Well maybe this is where the problem is. Not being able to do this means
that we need a special integer type to cover this case if we wanted to
work on win64. Switching to long long would generate bad code on 32 bit
archs so thats not an option.
Depending on your viewpoint it is either it not being a standard that is
bad, or the LLP64 that is bad.
Anyway this is personal preference.
Jes
next prev parent reply other threads:[~2010-08-17 19:44 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-08-12 17:50 [Qemu-devel] [PATCH 2/5] CODING_STYLE: add C type rules Blue Swirl
2010-08-13 19:37 ` [Qemu-devel] " Blue Swirl
2010-08-17 8:09 ` [Qemu-devel] " Jes Sorensen
2010-08-17 17:56 ` Blue Swirl
2010-08-17 18:55 ` malc
2010-08-17 19:23 ` Jes Sorensen
2010-08-17 19:24 ` malc
2010-08-17 19:43 ` Jes Sorensen [this message]
2010-08-17 20:29 ` Anthony Liguori
2010-08-17 20:33 ` malc
2010-08-17 18:39 ` Richard Henderson
2010-08-17 19:15 ` Jes Sorensen
2010-08-18 16:46 ` Avi Kivity
2010-08-19 7:58 ` Jes Sorensen
2010-08-19 8:10 ` Avi Kivity
2010-08-19 8:17 ` Jes Sorensen
2010-08-19 12:24 ` Avi Kivity
2010-08-19 12:52 ` malc
2010-08-19 12:59 ` Avi Kivity
2010-08-18 8:35 ` [Qemu-devel] " Paolo Bonzini
2010-08-18 8:58 ` Jes Sorensen
2010-08-18 10:30 ` Kevin Wolf
2010-08-18 13:57 ` Paolo Bonzini
2010-08-18 16:55 ` Avi Kivity
2010-08-19 7:51 ` Paolo Bonzini
2010-08-19 8:12 ` Avi Kivity
2010-08-18 16:44 ` [Qemu-devel] " Avi Kivity
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=4C6AE665.7090502@redhat.com \
--to=jes.sorensen@redhat.com \
--cc=av1474@comtv.ru \
--cc=blauwirbel@gmail.com \
--cc=qemu-devel@nongnu.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).