[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Issue 5698: int->vsize in various alignment and page-layout methods
From: |
David Kastrup |
Subject: |
Re: Issue 5698: int->vsize in various alignment and page-layout methods (issue 563420043 by address@hidden) |
Date: |
Mon, 27 Jan 2020 15:33:25 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) |
Dan Eble <address@hidden> writes:
> On Jan 27, 2020, at 03:26, address@hidden wrote:
>>
>> LGTM
>>
>> Not for this change, but could we do a global
>>
>> vsize -> size_t
>>
>> search & replace. Do we have a reason to keep our own typedef for this?
>
> I fully support this. I wasn't going to bring it up yet because I
> worried that it would lead to a lot of discussion and I have bigger
> fish to fry, but I would like to eliminate the following from flower
> because they reduce clarity.
>
> * real.hh:typedef double Real;
> * std-string.hh:typedef size_t ssize;
> * std-vector.hh:typedef size_t vsize;
They fix certain types that are used consistently. If you say they
"reduce clarity", then every typedef reduces clarity.
ssize and vsize may depend on our internal implementations of
std-string.hh and std-vector.hh. With the current code base, as far as
I know our own types are gone, so size_t seems fine for replacement.
I am decidedly less sure about Real. Different sizes than just double
might make sense where it is used, say, as the base type of Offset. I
am not overly sure that we use it consistently, though.
> I would like to replace the following with standard types (uint8_t
> etc.). The standard types are portable, but these are not.
>
> * flower-proto.hh:typedef unsigned char Byte;
> * flower-proto.hh:typedef long long I64;
> * flower-proto.hh:typedef unsigned char U8;
> * flower-proto.hh:typedef short I16;
> * flower-proto.hh:typedef unsigned short U16;
> * flower-proto.hh:typedef unsigned U32;
> * flower-proto.hh:typedef int I32;
> * flower-proto.hh:typedef unsigned long long U64;
I don't really mind here, but "portable" practically means just portable
to GCC and Clang which closely follows GCC, so it's not a problem in
practice but at most in readability, and the names are clear enough.
At any rate, like with running fixcc.py I think the best point of time
would be when the stable branch has seen a formal end of cherry-picking
in order not to complicate it. The style changes can happen in parallel
on both release branches. With regard to the somewhat more invasive
type frobbing, I think I'd wait for it until 2.21.0 has already been
out.
--
David Kastrup
Re: Issue 5698: int->vsize in various alignment and page-layout methods (issue 563420043 by address@hidden), nine . fierce . ballads, 2020/01/27
Re: Issue 5698: int->vsize in various alignment and page-layout methods (issue 563420043 by address@hidden), jonas . hahnfeld, 2020/01/27
Re: Issue 5698: int->vsize in various alignment and page-layout methods (issue 563420043 by address@hidden), nine . fierce . ballads, 2020/01/27