This is the mail archive of the newlib@sourceware.org mailing list for the newlib project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RTEMS Targets Issue #2 - ftello()/fseeko()


On Mar 20 10:15, Joel Sherrill wrote:
> On 03/20/2016 07:35 AM, Corinna Vinschen wrote:
> >On Mar 19 22:35, Yaakov Selkowitz wrote:
> >>On 2016-03-19 12:10, Joel Sherrill wrote:
> >>>We have a few files which get warnings because
> >>>ftello() and/or fseeko() are not prototyped.
> >>>These were protected by:
> >>>
> >>>#if !defined(__STRICT_ANSI__) || defined(__USE_XOPEN2K)
> >>Note that __USE_* is the glibc form of the internal macros, where newlib has
> >>(even prior to my changes) used the BSD form __*_VISIBLE.  So this was wrong
> >>to start with.
> >>
> >>>But now have:
> >>>
> >>>#if __LARGEFILE_VISIBLE
> >>>
> >>>The RTEMS fseeko() test does not explicitly define
> >>>__USE_XOPEN2K so I am guessing it was implicit before.
> >>>
> >>>Does the newlib guard need tinkering, the RTEMS default
> >>>features, or the test code in RTEMS?
> >>feature_test_macros(7) says that _XOPEN_SOURCE>= 500 includes these two
> >>largefile functions implicitly, but fseeko(3) says they are also
> >>POSIX.1-2001.  Does changing the guard to:
> >>
> >>#if __LARGEFILE_VISIBLE || __POSIX_VISIBLE>= 200112
> >>
> >>fix this issue?
> Hacking on an installed header to use this and I didn't
> get a warning.
> >glibc's fseeko/ftello man page claims this guard:
> >
> >    _FILE_OFFSET_BITS == 64 || _POSIX_C_SOURCE>= 200112L ||
> >    _XOPEN_SOURCE>= 600
> >    (defining the obsolete _LARGEFILE_SOURCE macro also works)
> >
> >Note especially the _FILE_OFFSET_BITS == 64.  So fseeko/ftello are
> >always defined on systems with sizeof(off_t) == 8.
> >
> If someone turns that into the conditional, I will test it also.
> But it looks like it should work also. Or commit something
> and I will rebuild tools and do a clean test sweep.
> 
> I need to double check but the only other issues I think I am
> seeing are:
> 
> + binutils master has an ld issue on v850
> + epiphany's machine/stdlib.h includes its own unique versions
>    of a couple of random methods. We want to turn them off for
>    at least RTEMS. They are an incomplete set and make a single
>    target inconsistent with the rest of our targets.
> 
> diff --git a/newlib/libc/machine/epiphany/machine/stdlib.h
> b/newlib/libc/machine
> index 95b4063..7ede4dd 100644
> --- a/newlib/libc/machine/epiphany/machine/stdlib.h
> +++ b/newlib/libc/machine/epiphany/machine/stdlib.h
> @@ -1,3 +1,4 @@
> +#ifndef __rtems__
>  static __inline__ long int
>  random (void)
>  {
> @@ -13,3 +14,4 @@ srandom (unsigned int seed)
> 
>    srand (seed);
>  }
> +#endif
> 
> Is this patch OK? If so, I will post it formally with a comment.

Yes, go ahead.


Thanks,
Corinna

-- 
Corinna Vinschen
Cygwin Maintainer
Red Hat

Attachment: signature.asc
Description: PGP signature


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]