Doug Evans writes:
> long long (+ unsigned long long) is ok by me.
> I could also rename the functions to read_uleb128_to_ull (unsigned
> long long) to allow for a day if/when someone wants
> read_uleb128_to_uint64. Ok?
Sounds good to me.
Thanks.
Ian
On Mon, May 21, 2012 at 10:08 AM, Ian Lance Taylor wrote:
> d...@google.com (Doug Evans) writes:
>
>> 2012-05-17 Doug Evans
>>
>> * leb128.h: New file.
>
> I'm not entirely sure about the use of int64_t to hold the result. Do
> we want to let this interface support larger types some day?
d...@google.com (Doug Evans) writes:
> 2012-05-17 Doug Evans
>
> * leb128.h: New file.
I'm not entirely sure about the use of int64_t to hold the result. Do
we want to let this interface support larger types some day? E.g.,
should the result be long long?
I'll approve this patch, but
On Mon, 21 May 2012 02:30:58 +0200, Doug Evans wrote:
> Ping.
> On Thu, May 17, 2012 at 11:29 AM, Doug Evans wrote:
[...]
> > --- /dev/null 1 Jan 1970 00:00:00 -
> > +++ leb128.h 17 May 2012 18:23:29 -
[...]
> > +/* Get a definition for NULL. */
> > +#include
I think for NULL.
[
Ping.
On Thu, May 17, 2012 at 11:29 AM, Doug Evans wrote:
> Hi.
>
> This is a slightly modified version of my previous patch.
>
> ref: http://gcc.gnu.org/ml/gcc-patches/2012-05/msg00962.html
>
> The only change is to make the result of the functions an int
> instead of a const pointer.
> This let
Hi.
This is a slightly modified version of my previous patch.
ref: http://gcc.gnu.org/ml/gcc-patches/2012-05/msg00962.html
The only change is to make the result of the functions an int
instead of a const pointer.
This lets them be used in places where the code is using
non-const pointers without
Hi.
This patch creates leb128.h which contains a few functions for
reading leb128 values.
They're in a header as static inlines because they can be speed critical.
I've only included what I need in GDB.
Ok to check in?
2012-05-14 Doug Evans
* leb128.h: New file.
Index: leb128.h
