Hello. The bug log contains a slightly improved v16. Marc Poulhiès: > issue we currently see is that some application code doesn't build. In > particular gprbuild needs to be adjusted following your changes. We don't want > to split the ecosystem between code that builds with latest compiler only and > code that builds with older compilers only. > We're currently discussing the possible solutions. The case of gprbuild is > very > localized and comes from the removal of the Timeval type in the > GNAT.Sockets.Thin_Common package, but we fear that this pattern may exist in > many other applications. Testing the changes is not straightforward as we need > to adjust many downstream projects (gprbuild as already mentioned, but also > many > custom runtimes that now fail to build, and probably others that we will > discover as we fix previous failures...).
The types in System.C_Time could remain visible for a while, with Obsolescent warnings that they will eventually be private. Then, types removed by patch 1 could be replaced with subtypes. For example, in GNAT.Sockets.Thin_Common: subtype time_t is System.C_Time.time_t; pragma Obsolescent (time_t, "please use System.C_Time"); subtype suseconds_t is System.C_Time.usec_t; pragma Obsolescent (suseconds_t, "please use System.C_Time"); subtype timeval is System.C_Time.timeval; pragma Obsolescent (timeval, "please use System.C_Time"); Except for the casing, the timeval/spec record components were consistently named, so most user code accessing them should build unchanged. Would this solve the issues you are encountering? If so, it does not cost much to replace each visible removal in patch 1 with a subtype or a function renaming (and an Obsolescent pragma), just in case someone outside GNAT is relying on it.
