https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114065

--- Comment #55 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
Following Olivier's message, we decided to go one step farther and to propose
further changes:

  - The record types in System.C_Time are declared with both Convention C and
ranges for their components, which is a bit contradictory. Moreover, the ranges
are nonnegative, which cannot work for negative values of Duration, so we
propose dropping them.

  - Using privacy in System.C_Time also seems a bit contradictory: this is a
unit aimed at interfacing with C at very low-level so you'd better expose
everything.

  - The changes to the Ada hierarchy gratuitously break backward compatibility:

   --  These four functions deliberately raise Constraint_Error when
   --  the C timespec struct cannot represent the value, even if the
   --  Ada types would otherwise allow a direct conversion.

They should be dropped and the Ada hierarchy left alone; this will streamline
the new System.C_Time unit in the process.

  - The algorithm used for the conversion routines in System.C_Time should be
copied from the existing implementation for the sake of backward compatibility.

  - The change adds a few pragma Obsolescent in the GNAT hierarchy, which is a
good idea, but they read:

pragma Obsolescent (timeval, "please use System.C_Time");

But if you use System.C_Time directly, you'll get the usual warning that it's
an internal unit, so we suggest adding a GNAT.C_Time unit as a renaming of it
and adjust the wording of the pragma.

  - The change reuses s-osprim__rtems.adb for Darwin and x32/Linux, which is
problematic: the RTEMS folks must be able to change the file without testing on
Darwin or x32/Linux. This should be dropped as well.

  - The change does not touch the abomination that is the declaration of time_t
in System.OS_Lib, but we think that we really need to get rid of it.


On the procedural side, we suggest merging all the patches except for the
second one into a single change and applying the second one, specific to the
Y2038 Glibc transition, as a second step separately.  Proposed first patch to
be attached.

Reply via email to