Re: [PATCH] Deprecate 32-bit off_t support

[Szabolcs Nagy <Szabolcs dot Nagy at arm dot com>]

On 04/01/2019 13:15, Szabolcs Nagy wrote:
> On 04/01/2019 12:39, Florian Weimer wrote:
>> diff --git a/NEWS b/NEWS
>> index cc20102fda..2f601c6217 100644
>> --- a/NEWS
>> +++ b/NEWS
>> @@ -85,6 +85,15 @@ Deprecated and removed features, and other changes affecting compatibility:
>>    as all functions that call vscanf, vfscanf, or vsscanf are annotated with
>>    __attribute__ ((format (scanf, ...))).
>>  
>> +* A future release of glibc will use a 64-bit off_t type on all
>> +  architectures (as currently available with -D_FILE_OFFSET_BITS=64 on
>> +  32-bit architectures).  Building new applications with
>> +  -D_FILE_OFFSET_BITS=32 will no longer be supported.  The off64_t type and
>> +  the 64-bit function aliases (such as fstat64) will remain available under
>> +  the appropriate feature test macros.  In preparation, libraries should
>> +  stop using off_t in public header files, and use off64_t (or a fixed-width
> 
> please do not recommend the use of a non-standard type
> in place of a standard one (off64_t is not even available
> with default feature test macros in posix headers).
> 
> instead i'd recommend the consistent use of
> -D_FILE_OFFSET_BITS=64 and warn
> #if _FILE_OFFSET_BITS==32
> where appropriate.

we could recommend

#ifndef _FILE_OFFSET_BITS
_Static_assert(sizeof(off_t)>4, "32bit off_t is deprecated, on platforms where it is still supported use explicit -D_FILE_OFFSET_BITS=32.");
#endif

or similar when off_t is used in public apis.

then first change the default, then drop support.

>> +  type such as int64_t or uint64_t) instead.
>> +
>>  Changes to build and runtime requirements:
>>  
>>  * Python 3.4 or later is required to build the GNU C Library.
>>
>