public inbox for elfutils@sourceware.org
 help / color / mirror / Atom feed
From: Richard Henderson <rth@redhat.com>
To: elfutils-devel@lists.fedorahosted.org
Subject: Re: [PATCH 2/3] Simplify and inline get_uleb128 and get_sleb128
Date: Wed, 23 Apr 2014 11:51:19 -0700	[thread overview]
Message-ID: <53580BA7.8050303@redhat.com> (raw)
In-Reply-To: m2r44nq4ld.fsf@redhat.com

[-- Attachment #1: Type: text/plain, Size: 1214 bytes --]

On 04/23/2014 11:32 AM, Petr Machata wrote:
> Richard Henderson <rth@redhat.com> writes:
> 
>> On 04/23/2014 03:17 AM, Petr Machata wrote:
>>> Wouldn't something like this get us off the hook as well?
>>>
>>> -	(var) |= (typeof (var)) __s.i << ((nth) * 7);			      \
>>> +	(var) |= (typeof (var))						      \
>>> +	  (((uint64_t) (typeof (var)) __s.i) << ((nth) * 7));		      \
>>>
>>> We are really only using the bitfield trick to avoid having to
>>> sign-extend by hand, but we can shift unsigned without losing anything.
>>
>> It gets us off the hook, but might introduce a 64-bit shift where
>> only a 32-bit shift was required.
> 
> Good point, but get_sleb128_step is only used from __libdw_get_sleb128,
> where the type is int64_t.  This macro is not safe for outside use
> anyway, as it uses its parameters more than once.
> 
> Hmm, should we maybe #undef it after __libdw_get_sleb128, so that it's
> clear that it's for local use only?

In that case, why play around with the typeof at all?  Just merge the macro
into its only user.  At which point using uint64_t makes total sense in context.

Similarly with get_uleb128_step, I assume, at least wrt to the typeof.


r~


             reply	other threads:[~2014-04-23 18:51 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-23 18:51 Richard Henderson [this message]
  -- strict thread matches above, loose matches on Subject: below --
2014-04-24  9:49 Mark Wielaard
2014-04-23 22:32 Petr Machata
2014-04-23 21:54 Mark Wielaard
2014-04-23 20:29 Petr Machata
2014-04-23 19:01 Josh Stone
2014-04-23 18:32 Petr Machata
2014-04-23 15:27 Richard Henderson
2014-04-23 10:17 Petr Machata
2014-04-22 22:04 Mark Wielaard
2014-04-22 15:58 Richard Henderson
2014-04-22 15:52 Josh Stone
2014-04-22 15:03 Richard Henderson
2014-04-22 15:01 Richard Henderson
2014-04-22 14:55 Mark Wielaard
2013-12-12 22:23 Petr Machata
2013-12-12 19:06 Josh Stone
2013-12-12 12:13 Petr Machata
2013-12-11  1:35 Josh Stone

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=53580BA7.8050303@redhat.com \
    --to=rth@redhat.com \
    --cc=elfutils-devel@lists.fedorahosted.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 read-only IMAP folder(s) and NNTP newsgroup(s).