On Tue, Jan 03, 2017 at 04:33:24PM -0800, Paul Eggert wrote:
> (An aside: It's typically safer in C to assign to a typed temporary than
> to cast to the type, as casts are too powerful. This is orthogonal to
> the long-vs-ptrdiff_t issue.)
Yes.
Sometimes, to make casts safer, I declare macros to
On 01/03/2017 04:16 PM, Ben Pfaff wrote:
> One strategy is to use PRIdPTR for ptrdiff_t and PRIdMAX or PRIuMAX
> (plus a cast) for other types.
PRIdPTR is for intptr_t, not for ptrdiff_t.
(An aside: It's typically safer in C to assign to a typed temporary than
to cast to the type, as casts are
On Mon, Jan 02, 2017 at 04:09:59PM -0800, Paul Eggert wrote:
> Bruno Haible wrote:
> >I would vote for removing this sentence "Gnulib code can assume that standard
> >internal types like size_t are no wider than long." The fix is easy nowadays
> >(since MSVC now has ): Use intptr_t or ptrdiff_t or
Bruno Haible wrote:
I would vote for removing this sentence "Gnulib code can assume that standard
internal types like size_t are no wider than long." The fix is easy nowadays
(since MSVC now has ): Use intptr_t or ptrdiff_t or size_t as
appropriate.
It's not that easy for code that wants to
Paul Smith wrote:
> > Gnulib code can assume that standard internal types like size_t are no
> > wider than long.
>
> Is that right? On a 64bit system compiling with Microsoft Visual C,
> long is only a 32bit integer. Is it saying that gnulib is specifically
> not intended to work with MS
Looking at the portability guidelines[1] there is some confusion; early
on it says:
> Currently we assume at least a freestanding C89 compiler
But then later in that same section I see things like:
> The GNU coding standards allow one departure from strict C99
and:
> Hence Gnulib code should
