[PATCH] manual: remove misplaced time_t note from _FILE_OFFSET_BITS [BZ #34095]

[Mark Harris]

Shamil Abdulaev wrote:
>
> The paragraph warning that _FILE_OFFSET_BITS's default may change due
> to time_t Y2038 safety was placed inside the _FILE_OFFSET_BITS
> section, but Y2038 is a concern of _TIME_BITS.  The adjacent _TIME_BITS
> section already documents the Y2038 behaviour, so remove the
> misplaced paragraph rather than merging it in.

This is not misplaced.  It is saying that as the year 2038 approaches,
a change to _TIME_BITS=64 is inevitable.  However as mentioned later,
_TIME_BITS=64 requires _FILE_OFFSET_BITS=64.  Therefore a change to
_FILE_OFFSET_BITS=64 is also inevitable, and you should not assume in
your code that the current default will persist just because it has
been that way for decades.  Even if your software will never need to
support files over 2 GB and you plan to never update it, you may be
unable to avoid rebuilding it with the new default just to keep it
working.

 - Mark


>
> Signed-off-by: Shamil Abdulaev <ashamil435@gmail.com>
> ---
>  manual/creature.texi | 5 -----
>  1 file changed, 5 deletions(-)
>
> diff --git a/manual/creature.texi b/manual/creature.texi
> index 90f9f8e35b..e1888d5f72 100644
> --- a/manual/creature.texi
> +++ b/manual/creature.texi
> @@ -161,11 +161,6 @@ under different names (as they are with @code{_LARGEFILE64_SOURCE}).
>  Instead the old function names now reference the new functions, e.g., a
>  call to @code{fseeko} now indeed calls @code{fseeko64}.
>
> -If the macro is not defined it currently defaults to @code{32}, but
> -this default is planned to change due to a need to update
> -@code{time_t} for Y2038 safety, and applications should not rely on
> -the default.
> -
>  This macro should only be selected if the system provides mechanisms for
>  handling large files.  On @w{64 bit} systems this macro has no effect
>  since the @code{*64} functions are identical to the normal functions.
> --
> 2.54.0
>