Hi Paul,
Here's my take on the typedef for indices and sizes.
As I've said in
https://lists.gnu.org/archive/html/bug-gnulib/2017-06/msg00024.html
and later, the point is to make the code clearer. For example, in
canonicalize-lgpl.c when we write
ptrdiff_t dest_offset = dest - rpath;
it means
On 12/3/20 6:25 AM, Bruno Haible wrote:
/* The user can define UNSIGNED_INDSIZE_T, to get a different set of compiler
warnings. */
I'm leery of this complexity, as it would change the semantics of what the type
means. The type is not just about compiler warnings; it's about preferring
si
Hello,
I'm using gnulib for quite a long time now to supply missing functions
(eg: get_opt) in some C++ projects. And suddenly everything breaks down.
Apparently read is redefined to _read when compiling for Windows since
this September. I'm cross compiling with x86_64-w64-mingw32.
In some
On 12/2/20 3:56 PM, Bruno Haible wrote:
can we have typedef names for these signed types that
are supposed to only have values >= 0 ?
More generally, when I'm reviewing code I naturally look for relationships like
0 <= i < j < n. I can see where one might want to say "j is of type i+1 .. n-1"
Martin Storsjö wrote:
> FAIL: test-fprintf-posix3.sh
This patch fixes it. It now produces a diagnostic
"Skipping test: cannot trust address space size on this platform"
2020-12-03 Bruno Haible
fprintf-posix-tests: Avoid a test failure on macOS 10.13.
Reported by Martin Storsj
Paul Eggert wrote:
> More generally, when I'm reviewing code I naturally look for relationships
> like
> 0 <= i < j < n. I can see where one might want to say "j is of type i+1 ..
> n-1"
> but all things considered it'd be better for the compiler and/or human reader
> to
> infer that sort of
Hi Paul,
> > /* The user can define UNSIGNED_INDSIZE_T, to get a different set of
> > compiler
> > warnings. */
>
> I'm leery of this complexity, as it would change the semantics of what the
> type
> means. The type is not just about compiler warnings; it's about preferring
> signed inte
On 12/3/20 2:02 PM, Bruno Haible wrote:
For this reason I see the choice of a signed type as an_implementation_ detail.
It's a crucial detail and it belongs in the API. I not not want to waste time
worrying whether idx_t is signed in any code that uses idx_t, as
signed-vs-unsigned problems a
Paul Eggert wrote:
> > For this reason I see the choice of a signed type as an_implementation_
> > detail.
>
> It's a crucial detail and it belongs in the API. I not not want to waste time
> worrying whether idx_t is signed in any code that uses idx_t, as
> signed-vs-unsigned problems are ende
