Re: Issue 5698: int->vsize in various alignment and page-layout methods (issue 563420043 by address@hidden)

[David Kastrup]

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