public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Gabriel Dos Reis <gdr@integrable-solutions.net>
To: Kai Tietz <ktietz70@googlemail.com>
Cc: Paolo Carlini <paolo.carlini@oracle.com>,
	GCC Patches <gcc-patches@gcc.gnu.org>,
		"libstdc++" <libstdc++@gcc.gnu.org>
Subject: Re: [patch libstdc++]: Fix LLP64 pointer-size issues for cxxabi, eh_alloc, and hash_bytes
Date: Fri, 21 Dec 2012 15:04:00 -0000	[thread overview]
Message-ID: <CAAiZkiCzQmkVboUPPv8pqxZHuJKufNpWnEaHa8FkoJPU5-FqhA@mail.gmail.com> (raw)
In-Reply-To: <CAEwic4YCxiCmnd5pY-Ra7vq4AJ7rkwwe75E=YstOeEWDWJHNeg@mail.gmail.com>

On Fri, Dec 21, 2012 at 3:48 AM, Kai Tietz <ktietz70@googlemail.com> wrote:
> 2012/12/21 Paolo Carlini <paolo.carlini@oracle.com>:
>> On 12/21/2012 10:36 AM, Kai Tietz wrote:
>>>
>>> well, issue isn't that 'long' is always 'ptrdiff_t'.
>>
>> But then, if we just change the type without paying attention to size (and
>> alignment) aren't we looking for BIG ABI trouble?!?
>
> Huh?  We have ABI-trouble due long is  too small to hold a
> pointer-diff for llp64.  Intended is here 'pointer-size' AFAICS in
> code, but with wrong assumption that a 'long' is always long enough.
>
>  Btw I just checked all targets we have right now in gcc.  The type
> ptrdiff_t is always either 'long', or 'int' (ilp32, lp64), and 'long
> long' for LLP64.  Means ptrdiff_t gets always equal (or bigger) to
> biggest pointer-size for target (AFAICS).
>
> Kai

We must write the codes so that their intents are clear, without
requiring lot of reverse engineering every time one looks at them.  If we
intend offset, then clearly ptrdiff_t is the first choice.  Solid
reasons must be provided why it can't be ptrdiff_t and such
reasons must be part of the code as comments explaining why
the obvious thing should be discounted.

- Gaby

  parent reply	other threads:[~2012-12-21 15:04 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-12-21  8:00 Kai Tietz
2012-12-21  9:12 ` Marc Glisse
2012-12-21  9:13 ` Paolo Carlini
2012-12-21  9:16   ` Kai Tietz
2012-12-21  9:32     ` Paolo Carlini
2012-12-21  9:36       ` Kai Tietz
2012-12-21  9:39         ` Paolo Carlini
2012-12-21  9:48           ` Kai Tietz
2012-12-21  9:59             ` Kai Tietz
2012-12-21 10:02               ` Paolo Carlini
2012-12-21 15:04             ` Gabriel Dos Reis [this message]
2012-12-21 15:54               ` Kai Tietz
2012-12-21 14:59 ` Gabriel Dos Reis
2012-12-21 10:13 Uros Bizjak
2012-12-21 10:16 ` Kai Tietz

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=CAAiZkiCzQmkVboUPPv8pqxZHuJKufNpWnEaHa8FkoJPU5-FqhA@mail.gmail.com \
    --to=gdr@integrable-solutions.net \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=ktietz70@googlemail.com \
    --cc=libstdc++@gcc.gnu.org \
    --cc=paolo.carlini@oracle.com \
    /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 read-only IMAP folder(s) and NNTP newsgroup(s).