This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Ping Re: Make strtod respect the rounding mode (bug 14518)
On Thu, 6 Sep 2012, Joseph S. Myers wrote:
> > Instead, just put the common part in
> > sysdeps/generic/rounding-mode.h and make sysdeps/.../rounding-mode.h files
> > include that explicitly by name.
>
> That seems to complicate unduly providing the generic version of
> get_rounding_mode based on fpu_control.h - sysdeps files would need to
> define some macro telling the generic header not to define the generic
> version, rather than just providing a single inline function as at
> present. (The generic header has to be included before the
> get_rounding_mode function is defined, since the generic header provides
> the return type for that function.) I think there is a natural separation
> into two headers here, the header providing the rounding_mode_t type and
> the round_away function (only one version) and the header providing the
> get_rounding_mode function (multiple versions including a generic one that
> some architectures but not others override), with the latter being
> included by the former. I don't think combining the generic
> bits/rounding-mode.h with the all-architectures include/rounding-mode.h
> makes sense. And include/rounding-mode.h doesn't go directly in stdlib/
> because it will be used in printf as well; it's an internal,
> system-independent header shared by multiple directories.
To be clear: I have no problems with *renaming* headers - for example,
changing bits/rounding-mode.h to get-rounding-mode.h and putting the
default version of that in sysdeps/generic/, if that's what's preferred
rather than using a bits/ naming convention. But I don't think
*combining* the system-independent header (rounding-mode.h in the current
patch) with the default version of the system-dependent header
(bits/rounding-mode.h in the current patch) makes sense; I think the
natural and cleanest approach is for those to be in separate files.
--
Joseph S. Myers
joseph@codesourcery.com