This is the mail archive of the
newlib@sourceware.org
mailing list for the newlib project.
Re: [RFA] confine _TIMEVAL_DEFINED guard in libc/include/sys/time.h
On Mon, Nov 12, 2012 at 09:39:22AM -0600, Joel Sherrill wrote:
>On 11/12/2012 09:20 AM, Christopher Faylor wrote:
>> On Mon, Nov 12, 2012 at 11:40:31AM +0100, Corinna Vinschen wrote:
>>> On Nov 11 13:58, Christopher Faylor wrote:
>>>> The _TIMEVAL_DEFINED guard in time.h is a little to enthusiastic in what
>>>> it is guarding. It's possible that there are other guards needed here
>>>> but, IMO, _TIMEVAL_DEFINED shouldn't be turning off the declaration of
>>>> timezone. Without this change, using Mingw64 headers becomes
>>>> problematic.
>>>>
>>>> Ok to apply?
>>> More or less, yes. The Mingw64 header uses the _TIMEVAL_DEFINED guard
>>> also to guard the macros timerisset, timercmp, and timerclear, so we
>>> should do the same. Would you mind to add that?
>> Well, maybe, but that isn't a necessary change as far as getting 32-bit
>> Cygwin building is concerned*. Although I can see the sense in putting
>> the macros under this conditional, the macros on Linux are not protected
>> by the equivalent "__need_timeval". Also, moving the macros has
>> potential side-effects for rtems. Do they have to weigh in on this too?
>RTEMS only supports newlib currently so as long as newlib is
>internally consistent, we should be OK.
>
>As a disclaimer to that, we have lots of code from NetBSD and
>FreeBSD for things that range from shell commands to the
>USB and TCP/IP stacks. Those may have .h files which depend
>on the structure of this conditional. But I don't see _TIMEVAL_DEFINED
>used in any of that code.
>
>I think changing this to the cleanest form is OK for RTEMS.
>> I thought this was an obvious change architecturally for newlib since
>> the guard (or at least the naming of the guard) was clearly wrong.
>> Moving the macros seems slightly less obvious.
>
>What's correct and what breaks assumptions that have been in place for
>years are unfortunately often two different things.
CVS spelunking would show that these particular assumptions have only
been in place since July.
But, yes, the whole point of my attempting to be cautious was obviously
so that I didn't break code which relied on legacy behavior.
cgf