bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: range types, ptrdiff_t, signed integers for internals


From: Paul Eggert
Subject: Re: range types, ptrdiff_t, signed integers for internals
Date: Thu, 12 Dec 2019 14:24:01 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2

On 12/12/19 12:50 AM, Bruno Haible wrote:

Several programming languages have range types:

Pascal is where I first saw them.

I would distinguish the range type [0 .. PTRDIFF_MAX] (which is an abstract
concept) from the actual implementation (through the typedef). It could
be represented by a signed type or an unsigned type; either is fine.

Part of the motivation for this change is that unsigned types are not "fine": they can't be checked for overflow via -fsanitize=undefined, and they are not optimized as well for index calculations and the like due to their wraparound overflow semantics.

Also, where would we put these new typedefs? dfa.h doesn't seem like the
right place.

That's up to you. It could well be a separate .h file that is a module of
its own (like verify.h and intprops.h are).

For now I was more conservative installed the attached, which limits the scope of the new type (which I dubbed "idx_t", by analogy from Idx in the regex code) to dfa.c. If we want to make this type visible we have more work to do, including publishing its maximum value (IDX_MAX in dfa.c), and making it easy to printf (I used "%td" in dfa.c, which is quite convenient but it assumes idx_t is ptrdiff_t).

From my use of idx_t in dfa.c I'm not entirely sold on the distinction between it and ptrdiff_t. The type is not separate from ptrdiff_t; it means "ptrdiff_t but nonnegative" and the code relies on that. There were iffy places where it kinda doesn't matter whether one uses ptrdiff_t or idx_t and where I expect other developers won't bother about the difference (as no tools check for it).

Attachment: 0001-dfa-prefer-ptrdiff_t-for-API-too.patch
Description: Text Data


reply via email to

[Prev in Thread] Current Thread [Next in Thread]