tag:old.nabble.com,2006:forum-12240
Nabble - Sourceware - newlib
2009-12-22T02:47:08Z
Newlib is a C library intended for use on embedded systems. It is a conglomeration of several library parts. Sourceware - newlib home is <a href="http://sourceware.org/newlib/" target="_top" rel="nofollow">here</a>.
tag:old.nabble.com,2006:post-26886542
Re: fix getsubopt declaration
2009-12-22T02:47:08Z
2009-12-22T02:47:08Z
Corinna Vinschen
On Dec 21 22:11, Eric Blake wrote:
<div class='shrinkable-quote'><br>> -----BEGIN PGP SIGNED MESSAGE-----
<br>> Hash: SHA1
<br>>
<br>> Any objections to this? POSIX 2008 requires getsubopt in <stdlib.h> (even
<br>> though it also requires getopt in <unistd.h> - what a historical wart).
<br>>
<br>> 2009-12-22 Eric Blake <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26886542&i=0" target="_top" rel="nofollow">ebb9@...</a>>
<br>>
<br>> * libc/include/sys/unistd.h (suboptarg, getsubopt): Move...
<br>> * libc/include/stdlib.h: ...here, to match POSIX for getsubopt.
</div><br>Looks good to me. Please apply.
<br><br><br>Thanks,
<br>Corinna
<br><br>--
<br>Corinna Vinschen
<br>Cygwin Project Co-Leader
<br>Red Hat
<br><p>From forum: <a href="http://old.nabble.com/Sourceware---newlib-list-f12241.html" embed="fixTarget[12241]" target="_top" >Sourceware - newlib list</a></p>
tag:old.nabble.com,2006:post-26884022
fix getsubopt declaration
2009-12-21T21:11:08Z
2009-12-21T21:11:08Z
Eric Blake
-----BEGIN PGP SIGNED MESSAGE-----
<br>Hash: SHA1
<br><br>Any objections to this? POSIX 2008 requires getsubopt in <stdlib.h> (even
<br>though it also requires getopt in <unistd.h> - what a historical wart).
<br><br>2009-12-22 Eric Blake <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26884022&i=0" target="_top" rel="nofollow">ebb9@...</a>>
<br><br> * libc/include/sys/unistd.h (suboptarg, getsubopt): Move...
<br> * libc/include/stdlib.h: ...here, to match POSIX for getsubopt.
<br><br>- --
<br>Don't work too hard, make some time for fun as well!
<br><br>Eric Blake <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26884022&i=1" target="_top" rel="nofollow">ebb9@...</a>
<br>-----BEGIN PGP SIGNATURE-----
<br>Version: GnuPG v1.4.9 (Cygwin)
<br>Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
<br>Comment: Using GnuPG with Mozilla - <a href="http://enigmail.mozdev.org/" target="_top" rel="nofollow">http://enigmail.mozdev.org/</a><br><br>iEYEARECAAYFAkswVPkACgkQ84KuGfSFAYDVwgCeP4PCfcFs8wwRyXnJIk0mgs4g
<br>ChIAn1o912ryNC8lOlPfx0kDoUHrp7+G
<br>=H8QO
<br>-----END PGP SIGNATURE-----
<br><br />From ddf936891b7adf6fe397c81cfb8518b869e2a88d Mon Sep 17 00:00:00 2001
<br>From: Eric Blake <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26884022&i=2" target="_top" rel="nofollow">ebb9@...</a>>
<br>Date: Mon, 21 Dec 2009 22:09:55 -0700
<br>Subject: [PATCH] fix getsubopt header
<br><br>---
<br> newlib/libc/include/stdlib.h | 4 ++++
<br> newlib/libc/include/sys/unistd.h | 3 ---
<br> 2 files changed, 4 insertions(+), 3 deletions(-)
<br><br>diff --git a/newlib/libc/include/stdlib.h b/newlib/libc/include/stdlib.h
<br>index 82a2207..b33503d 100644
<br>--- a/newlib/libc/include/stdlib.h
<br>+++ b/newlib/libc/include/stdlib.h
<br>@@ -83,6 +83,10 @@ char * _EXFUN(getenv,(const char *__string));
<br> char * _EXFUN(_getenv_r,(struct _reent *, const char *__string));
<br> char * _EXFUN(_findenv,(_CONST char *, int *));
<br> char * _EXFUN(_findenv_r,(struct _reent *, _CONST char *, int *));
<br>+#ifndef __STRICT_ANSI__
<br>+extern char *suboptarg; /* getsubopt(3) external variable */
<br>+int _EXFUN(getsubopt,(char **, char * const *, char **));
<br>+#endif
<br> long _EXFUN(labs,(long));
<br> ldiv_t _EXFUN(ldiv,(long __numer, long __denom));
<br> _PTR _EXFUN_NOTHROW(malloc,(size_t __size));
<br>diff --git a/newlib/libc/include/sys/unistd.h b/newlib/libc/include/sys/unistd.h
<br>index 80c35da..4193002 100644
<br>--- a/newlib/libc/include/sys/unistd.h
<br>+++ b/newlib/libc/include/sys/unistd.h
<br>@@ -191,9 +191,6 @@ extern int optreset; /* getopt(3) external variable */
<br><br> #ifndef _POSIX_SOURCE
<br> pid_t _EXFUN(vfork, (void ));
<br>-
<br>-extern char *suboptarg; /* getsubopt(3) external variable */
<br>-int getsubopt(char **, char * const *, char **);
<br> #endif /* _POSIX_SOURCE */
<br><br> #ifdef _COMPILING_NEWLIB
<br>--
<br>1.6.5.rc1
<br><br><p>From forum: <a href="http://old.nabble.com/Sourceware---newlib-list-f12241.html" embed="fixTarget[12241]" target="_top" >Sourceware - newlib list</a></p>
tag:old.nabble.com,2006:post-26838197
Re: VMIN/VTIME and read expectations
2009-12-17T18:19:59Z
2009-12-17T18:19:59Z
Joel Sherrill <joel@OARcorp.com>
On 12/17/2009 06:05 PM, Eric Norum wrote:
<br>> ???
<br>> How did you make the TERMIOS stuff work on a socket?
<br>> I use SO_SNDTIMEOand SO_RCVTIMEO options for sockets on RTEMS. This causes read to return -1 with errno=EWOULDBLOCK on timeout.
<br>I think this is the root of the problem. The code behaves differently
<br>on the
<br>head from the last release branch. I need to see what has changed.
<br>>
<br>> We should probably take this correspondence off the newlib
<br>>
<br>Yep. Sorry folks. Moving...
<br><br>--joel
<div class='shrinkable-quote'><br>> On Dec 17, 2009, at 3:27 PM, Joel Sherrill wrote:
<br>>
<br>>
<br>>> On 12/17/2009 04:30 PM, Eric Norum wrote:
<br>>>
<br>>>> When you're using VMIN=0, VTIME=255 you have ICANON=0 so 'end-of-file' doesn't really exist.
<br>>>>
<br>>>>
<br>>> I was kind of guessing that. Unfortunately this is in the RTEMS login code.
<br>>> I can make it work OK for serial ports but when attached to a socket, I
<br>>> have no idea how to detect when the socket is dropped.
<br>>>
<br>>> I switched to calling read() and as documented, it always returns 0
<br>>> when there is no data. When the connection is dropped, it returns 0
<br>>> VERY quickly. Do you think this part is a bug in the read on a socket?
<br>>>
<br>>> If this turns into an RTEMS specific issue, we need to switch lists.
<br>>> But I would really like to know what is correct. :)
<br>>>
<br>>> --joel
<br>>>
<br>>>> On Dec 17, 2009, at 2:16 PM, Joel Sherrill wrote:
<br>>>>
<br>>>>
<br>>>>
<br>>>>> Hi,
<br>>>>>
<br>>>>> I have been looking into a program on RTEMS that
<br>>>>> uses VMIN=0, VTIME=255. The program calls
<br>>>>> fgetc() which calls read().
<br>>>>>
<br>>>>> fp->_flags == 0x2806 before the fgetc() call.
<br>>>>> read() times out and returns 0.
<br>>>>> fgetc() returns -1 and fp->_flags == 0x2826
<br>>>>>
<br>>>>>
<br>>>>> The 0x0020 being set is _SEOF.
<br>>>>>
<br>>>>> My questions are:
<br>>>>>
<br>>>>> + Is this correct behaviour?
<br>>>>>
<br>>>>> + How does the application programmer distinguish
<br>>>>> between a real EOF and an unsatisfied read? Even the
<br>>>>> Fedora read(2) man page says:
<br>>>>>
<br>>>>> On success, the number of bytes read is returned (zero indicates end of
<br>>>>> file), and the file position is advanced by this number.
<br>>>>>
<br>>>>> So even if I dropped down to read(2), I still don't know
<br>>>>> how to distinguish EOF from a read timeout.
<br>>>>>
<br>>>>> Thanks.
<br>>>>>
<br>>>>> --
<br>>>>> Joel Sherrill, Ph.D. Director of Research& Development
<br>>>>> <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26838197&i=0" target="_top" rel="nofollow">joel.sherrill@...</a> On-Line Applications Research
<br>>>>> Ask me about RTEMS: a free RTOS Huntsville AL 35805
<br>>>>> Support Available (256) 722-9985
<br>>>>>
<br>>>>>
<br>>>>>
<br>>>>>
<br>>>>
<br>>>>
<br>>>
<br>>> --
<br>>> Joel Sherrill, Ph.D. Director of Research& Development
<br>>> <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26838197&i=1" target="_top" rel="nofollow">joel.sherrill@...</a> On-Line Applications Research
<br>>> Ask me about RTEMS: a free RTOS Huntsville AL 35805
<br>>> Support Available (256) 722-9985
<br>>>
<br>>>
<br>>>
<br>>
</div><br><p>From forum: <a href="http://old.nabble.com/Sourceware---newlib-list-f12241.html" embed="fixTarget[12241]" target="_top" >Sourceware - newlib list</a></p>
tag:old.nabble.com,2006:post-26837178
Re: VMIN/VTIME and read expectations
2009-12-17T16:05:39Z
2009-12-17T16:05:39Z
Eric Norum
???
<br>How did you make the TERMIOS stuff work on a socket?
<br>I use SO_SNDTIMEOand SO_RCVTIMEO options for sockets on RTEMS. This causes read to return -1 with errno=EWOULDBLOCK on timeout.
<br>We should probably take this correspondence off the newlib
<br><br>On Dec 17, 2009, at 3:27 PM, Joel Sherrill wrote:
<br><div class='shrinkable-quote'><br>> On 12/17/2009 04:30 PM, Eric Norum wrote:
<br>>> When you're using VMIN=0, VTIME=255 you have ICANON=0 so 'end-of-file' doesn't really exist.
<br>>>
<br>>
<br>> I was kind of guessing that. Unfortunately this is in the RTEMS login code.
<br>> I can make it work OK for serial ports but when attached to a socket, I
<br>> have no idea how to detect when the socket is dropped.
<br>>
<br>> I switched to calling read() and as documented, it always returns 0
<br>> when there is no data. When the connection is dropped, it returns 0
<br>> VERY quickly. Do you think this part is a bug in the read on a socket?
<br>>
<br>> If this turns into an RTEMS specific issue, we need to switch lists.
<br>> But I would really like to know what is correct. :)
<br>>
<br>> --joel
<br>>> On Dec 17, 2009, at 2:16 PM, Joel Sherrill wrote:
<br>>>
<br>>>
<br>>>> Hi,
<br>>>>
<br>>>> I have been looking into a program on RTEMS that
<br>>>> uses VMIN=0, VTIME=255. The program calls
<br>>>> fgetc() which calls read().
<br>>>>
<br>>>> fp->_flags == 0x2806 before the fgetc() call.
<br>>>> read() times out and returns 0.
<br>>>> fgetc() returns -1 and fp->_flags == 0x2826
<br>>>>
<br>>>>
<br>>>> The 0x0020 being set is _SEOF.
<br>>>>
<br>>>> My questions are:
<br>>>>
<br>>>> + Is this correct behaviour?
<br>>>>
<br>>>> + How does the application programmer distinguish
<br>>>> between a real EOF and an unsatisfied read? Even the
<br>>>> Fedora read(2) man page says:
<br>>>>
<br>>>> On success, the number of bytes read is returned (zero indicates end of
<br>>>> file), and the file position is advanced by this number.
<br>>>>
<br>>>> So even if I dropped down to read(2), I still don't know
<br>>>> how to distinguish EOF from a read timeout.
<br>>>>
<br>>>> Thanks.
<br>>>>
<br>>>> --
<br>>>> Joel Sherrill, Ph.D. Director of Research& Development
<br>>>> <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26837178&i=0" target="_top" rel="nofollow">joel.sherrill@...</a> On-Line Applications Research
<br>>>> Ask me about RTEMS: a free RTOS Huntsville AL 35805
<br>>>> Support Available (256) 722-9985
<br>>>>
<br>>>>
<br>>>>
<br>>>
<br>>
<br>>
<br>> --
<br>> Joel Sherrill, Ph.D. Director of Research& Development
<br>> <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26837178&i=1" target="_top" rel="nofollow">joel.sherrill@...</a> On-Line Applications Research
<br>> Ask me about RTEMS: a free RTOS Huntsville AL 35805
<br>> Support Available (256) 722-9985
<br>>
<br>>
</div><br>--
<br>Eric Norum
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26837178&i=2" target="_top" rel="nofollow">eric@...</a>
<br><br><br><br><br><p>From forum: <a href="http://old.nabble.com/Sourceware---newlib-list-f12241.html" embed="fixTarget[12241]" target="_top" >Sourceware - newlib list</a></p>
tag:old.nabble.com,2006:post-26836830
RE: VMIN/VTIME and read expectations
2009-12-17T15:31:52Z
2009-12-17T15:31:52Z
Howland Craig D (Craig)
In effect, you're set up to be using non-blocking I/O. In that case,
<br>read() is supposed to set errno to EAGAIN to indicate that it failed
<br>because nothing was available. So the way to tell would be to check
<br>errno. (I'm not sure how you'd tell from a C streams level, but since
<br>you've gone to read, it doesn't matter.)
<br>
<br>Craig
<br><br><br>-----Original Message-----
<br>From: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26836830&i=0" target="_top" rel="nofollow">newlib-owner@...</a> [mailto:<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26836830&i=1" target="_top" rel="nofollow">newlib-owner@...</a>]
<br>On Behalf Of Joel Sherrill
<br>Sent: Thursday, December 17, 2009 6:28 PM
<br>To: Eric Norum
<br>Cc: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26836830&i=2" target="_top" rel="nofollow">newlib@...</a>
<br>Subject: Re: VMIN/VTIME and read expectations
<br><br>On 12/17/2009 04:30 PM, Eric Norum wrote:
<br>> When you're using VMIN=0, VTIME=255 you have ICANON=0 so 'end-of-file'
<br>doesn't really exist.
<br>>
<br><br>I was kind of guessing that. Unfortunately this is in the RTEMS login
<br>code.
<br>I can make it work OK for serial ports but when attached to a socket, I
<br>have no idea how to detect when the socket is dropped.
<br><br>I switched to calling read() and as documented, it always returns 0
<br>when there is no data. When the connection is dropped, it returns 0
<br>VERY quickly. Do you think this part is a bug in the read on a socket?
<br><br>If this turns into an RTEMS specific issue, we need to switch lists.
<br>But I would really like to know what is correct. :)
<br><br>--joel
<div class='shrinkable-quote'><br>> On Dec 17, 2009, at 2:16 PM, Joel Sherrill wrote:
<br>>
<br>>
<br>>> Hi,
<br>>>
<br>>> I have been looking into a program on RTEMS that
<br>>> uses VMIN=0, VTIME=255. The program calls
<br>>> fgetc() which calls read().
<br>>>
<br>>> fp->_flags == 0x2806 before the fgetc() call.
<br>>> read() times out and returns 0.
<br>>> fgetc() returns -1 and fp->_flags == 0x2826
<br>>>
<br>>>
<br>>> The 0x0020 being set is _SEOF.
<br>>>
<br>>> My questions are:
<br>>>
<br>>> + Is this correct behaviour?
<br>>>
<br>>> + How does the application programmer distinguish
<br>>> between a real EOF and an unsatisfied read? Even the
<br>>> Fedora read(2) man page says:
<br>>>
<br>>> On success, the number of bytes read is returned (zero
</div>indicates end of
<div class='shrinkable-quote'><br>>> file), and the file position is advanced by this number.
<br>>>
<br>>> So even if I dropped down to read(2), I still don't know
<br>>> how to distinguish EOF from a read timeout.
<br>>>
<br>>> Thanks.
<br>>>
<br>>> --
<br>>> Joel Sherrill, Ph.D. Director of Research& Development
<br>>> <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26836830&i=3" target="_top" rel="nofollow">joel.sherrill@...</a> On-Line Applications Research
<br>>> Ask me about RTEMS: a free RTOS Huntsville AL 35805
<br>>> Support Available (256) 722-9985
<br>>>
<br>>>
<br>>>
<br>>
</div><br><br>--
<br>Joel Sherrill, Ph.D. Director of Research& Development
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26836830&i=4" target="_top" rel="nofollow">joel.sherrill@...</a> On-Line Applications Research
<br>Ask me about RTEMS: a free RTOS Huntsville AL 35805
<br> Support Available (256) 722-9985
<br><br><br><p>From forum: <a href="http://old.nabble.com/Sourceware---newlib-list-f12241.html" embed="fixTarget[12241]" target="_top" >Sourceware - newlib list</a></p>
tag:old.nabble.com,2006:post-26836780
Re: VMIN/VTIME and read expectations
2009-12-17T15:27:49Z
2009-12-17T15:27:49Z
Joel Sherrill <joel@OARcorp.com>
On 12/17/2009 04:30 PM, Eric Norum wrote:
<br>> When you're using VMIN=0, VTIME=255 you have ICANON=0 so 'end-of-file' doesn't really exist.
<br>>
<br><br>I was kind of guessing that. Unfortunately this is in the RTEMS login
<br>code.
<br>I can make it work OK for serial ports but when attached to a socket, I
<br>have no idea how to detect when the socket is dropped.
<br><br>I switched to calling read() and as documented, it always returns 0
<br>when there is no data. When the connection is dropped, it returns 0
<br>VERY quickly. Do you think this part is a bug in the read on a socket?
<br><br>If this turns into an RTEMS specific issue, we need to switch lists.
<br>But I would really like to know what is correct. :)
<br><br>--joel
<div class='shrinkable-quote'><br>> On Dec 17, 2009, at 2:16 PM, Joel Sherrill wrote:
<br>>
<br>>
<br>>> Hi,
<br>>>
<br>>> I have been looking into a program on RTEMS that
<br>>> uses VMIN=0, VTIME=255. The program calls
<br>>> fgetc() which calls read().
<br>>>
<br>>> fp->_flags == 0x2806 before the fgetc() call.
<br>>> read() times out and returns 0.
<br>>> fgetc() returns -1 and fp->_flags == 0x2826
<br>>>
<br>>>
<br>>> The 0x0020 being set is _SEOF.
<br>>>
<br>>> My questions are:
<br>>>
<br>>> + Is this correct behaviour?
<br>>>
<br>>> + How does the application programmer distinguish
<br>>> between a real EOF and an unsatisfied read? Even the
<br>>> Fedora read(2) man page says:
<br>>>
<br>>> On success, the number of bytes read is returned (zero indicates end of
<br>>> file), and the file position is advanced by this number.
<br>>>
<br>>> So even if I dropped down to read(2), I still don't know
<br>>> how to distinguish EOF from a read timeout.
<br>>>
<br>>> Thanks.
<br>>>
<br>>> --
<br>>> Joel Sherrill, Ph.D. Director of Research& Development
<br>>> <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26836780&i=0" target="_top" rel="nofollow">joel.sherrill@...</a> On-Line Applications Research
<br>>> Ask me about RTEMS: a free RTOS Huntsville AL 35805
<br>>> Support Available (256) 722-9985
<br>>>
<br>>>
<br>>>
<br>>
</div><br><br>--
<br>Joel Sherrill, Ph.D. Director of Research& Development
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26836780&i=1" target="_top" rel="nofollow">joel.sherrill@...</a> On-Line Applications Research
<br>Ask me about RTEMS: a free RTOS Huntsville AL 35805
<br> Support Available (256) 722-9985
<br><br><br><p>From forum: <a href="http://old.nabble.com/Sourceware---newlib-list-f12241.html" embed="fixTarget[12241]" target="_top" >Sourceware - newlib list</a></p>
tag:old.nabble.com,2006:post-26836272
Re: VMIN/VTIME and read expectations
2009-12-17T14:36:56Z
2009-12-17T14:36:56Z
Eric Norum
Hit 'send' too soon.
<br>Of course if you're using the modem control lines (CLOCAL=0) then a loss-of-carrier will also result in read returning 0.
<br>So I guess there is a ambiguity after all.
<br><br>On Dec 17, 2009, at 2:30 PM, Eric Norum wrote:
<br><div class='shrinkable-quote'><br>> When you're using VMIN=0, VTIME=255 you have ICANON=0 so 'end-of-file' doesn't really exist.
<br>> On Dec 17, 2009, at 2:16 PM, Joel Sherrill wrote:
<br>>
<br>>> Hi,
<br>>>
<br>>> I have been looking into a program on RTEMS that
<br>>> uses VMIN=0, VTIME=255. The program calls
<br>>> fgetc() which calls read().
<br>>>
<br>>> fp->_flags == 0x2806 before the fgetc() call.
<br>>> read() times out and returns 0.
<br>>> fgetc() returns -1 and fp->_flags == 0x2826
<br>>>
<br>>>
<br>>> The 0x0020 being set is _SEOF.
<br>>>
<br>>> My questions are:
<br>>>
<br>>> + Is this correct behaviour?
<br>>>
<br>>> + How does the application programmer distinguish
<br>>> between a real EOF and an unsatisfied read? Even the
<br>>> Fedora read(2) man page says:
<br>>>
<br>>> On success, the number of bytes read is returned (zero indicates end of
<br>>> file), and the file position is advanced by this number.
<br>>>
<br>>> So even if I dropped down to read(2), I still don't know
<br>>> how to distinguish EOF from a read timeout.
<br>>>
<br>>> Thanks.
<br>>>
<br>>> --
<br>>> Joel Sherrill, Ph.D. Director of Research& Development
<br>>> <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26836272&i=0" target="_top" rel="nofollow">joel.sherrill@...</a> On-Line Applications Research
<br>>> Ask me about RTEMS: a free RTOS Huntsville AL 35805
<br>>> Support Available (256) 722-9985
<br>>>
<br>>>
<br>>
<br>> --
<br>> Eric Norum
<br>> <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26836272&i=1" target="_top" rel="nofollow">eric@...</a>
<br>>
<br>>
<br>>
<br>>
</div><br>--
<br>Eric Norum
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26836272&i=2" target="_top" rel="nofollow">eric@...</a>
<br><br><br><br><br><p>From forum: <a href="http://old.nabble.com/Sourceware---newlib-list-f12241.html" embed="fixTarget[12241]" target="_top" >Sourceware - newlib list</a></p>
tag:old.nabble.com,2006:post-26836199
Re: VMIN/VTIME and read expectations
2009-12-17T14:30:39Z
2009-12-17T14:30:39Z
Eric Norum
When you're using VMIN=0, VTIME=255 you have ICANON=0 so 'end-of-file' doesn't really exist.
<br>On Dec 17, 2009, at 2:16 PM, Joel Sherrill wrote:
<br><div class='shrinkable-quote'><br>> Hi,
<br>>
<br>> I have been looking into a program on RTEMS that
<br>> uses VMIN=0, VTIME=255. The program calls
<br>> fgetc() which calls read().
<br>>
<br>> fp->_flags == 0x2806 before the fgetc() call.
<br>> read() times out and returns 0.
<br>> fgetc() returns -1 and fp->_flags == 0x2826
<br>>
<br>>
<br>> The 0x0020 being set is _SEOF.
<br>>
<br>> My questions are:
<br>>
<br>> + Is this correct behaviour?
<br>>
<br>> + How does the application programmer distinguish
<br>> between a real EOF and an unsatisfied read? Even the
<br>> Fedora read(2) man page says:
<br>>
<br>> On success, the number of bytes read is returned (zero indicates end of
<br>> file), and the file position is advanced by this number.
<br>>
<br>> So even if I dropped down to read(2), I still don't know
<br>> how to distinguish EOF from a read timeout.
<br>>
<br>> Thanks.
<br>>
<br>> --
<br>> Joel Sherrill, Ph.D. Director of Research& Development
<br>> <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26836199&i=0" target="_top" rel="nofollow">joel.sherrill@...</a> On-Line Applications Research
<br>> Ask me about RTEMS: a free RTOS Huntsville AL 35805
<br>> Support Available (256) 722-9985
<br>>
<br>>
</div><br>--
<br>Eric Norum
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26836199&i=1" target="_top" rel="nofollow">eric@...</a>
<br><br><br><br><br><p>From forum: <a href="http://old.nabble.com/Sourceware---newlib-list-f12241.html" embed="fixTarget[12241]" target="_top" >Sourceware - newlib list</a></p>
tag:old.nabble.com,2006:post-26836193
Away for the holidays
2009-12-17T14:30:11Z
2009-12-17T14:30:11Z
Jeff Johnston
I will be away until Jan 4th on Christmas vacation. If you celebrate
<br>Christmas, Merry Christmas to you, otherwise, enjoy Happy Holidays and
<br>have a Happy New Year.
<br><br>If there are any 1.18.0 issues, I'll deal with them in the New Year.
<br><br>Regards,
<br><br>-- Jeff J.
<br><p>From forum: <a href="http://old.nabble.com/Sourceware---newlib-list-f12241.html" embed="fixTarget[12241]" target="_top" >Sourceware - newlib list</a></p>
tag:old.nabble.com,2006:post-26836110
Newlib 1.18.0 is released
2009-12-17T14:24:09Z
2009-12-17T14:24:09Z
Jeff Johnston
The latest snapshot is on the web-site.
<br><br>Thanks to everyone who contributed.
<br><br>*** Major changes in newlib version 1.18.0:
<br><br>* wide-char enhancements
<br>* long double math routines added for platforms where LDBL == DBL
<br>* long long math routines added
<br>* math cleanup
<br>* UTF-16 modifications for Cygwin
<br>* major locale charset overhaul including added charsets
<br>* added moxie platform
<br>* added rx platform
<br>* added xc16x platform
<br>* various cleanups
<br>* various bug fixes
<br><br><br><p>From forum: <a href="http://old.nabble.com/Sourceware---newlib-list-f12241.html" embed="fixTarget[12241]" target="_top" >Sourceware - newlib list</a></p>
tag:old.nabble.com,2006:post-26835994
VMIN/VTIME and read expectations
2009-12-17T14:16:14Z
2009-12-17T14:16:14Z
Joel Sherrill <joel@OARcorp.com>
Hi,
<br><br>I have been looking into a program on RTEMS that
<br>uses VMIN=0, VTIME=255. The program calls
<br>fgetc() which calls read().
<br><br>fp->_flags == 0x2806 before the fgetc() call.
<br>read() times out and returns 0.
<br>fgetc() returns -1 and fp->_flags == 0x2826
<br><br><br>The 0x0020 being set is _SEOF.
<br><br>My questions are:
<br><br>+ Is this correct behaviour?
<br><br>+ How does the application programmer distinguish
<br>between a real EOF and an unsatisfied read? Even the
<br>Fedora read(2) man page says:
<br><br> On success, the number of bytes read is returned (zero indicates
<br>end of
<br> file), and the file position is advanced by this number.
<br><br>So even if I dropped down to read(2), I still don't know
<br>how to distinguish EOF from a read timeout.
<br><br>Thanks.
<br><br>--
<br>Joel Sherrill, Ph.D. Director of Research& Development
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26835994&i=0" target="_top" rel="nofollow">joel.sherrill@...</a> On-Line Applications Research
<br>Ask me about RTEMS: a free RTOS Huntsville AL 35805
<br> Support Available (256) 722-9985
<br><br><br><p>From forum: <a href="http://old.nabble.com/Sourceware---newlib-list-f12241.html" embed="fixTarget[12241]" target="_top" >Sourceware - newlib list</a></p>
tag:old.nabble.com,2006:post-26833807
Re: Mixing function pointers and regular functions with the _EXFUN macro
2009-12-17T11:43:59Z
2009-12-17T11:43:59Z
Jeff Johnston
On 16/12/09 07:41 PM, Jerker Bäck wrote:
<div class='shrinkable-quote'><br>>> Leave the original _EXPARM macro alone and create a new macro: _EXFNPTR
<br>>> which you can define as you have changed _EXPARM. Use the new macro in
<br>>> your patch and please post the finished patch "here" and not in the bug.
<br>>> I am going to close bugzillas from now on immediately.
<br>>>
<br>>> If you can do this by tomorrow afternoon, I'll get the patch in for the
<br>>> snapshot.
<br>>>
<br>>> -- Jeff J.
<br>>
<br>> OK, thanks!
<br>>
<br>> I agree completely with Craig that _EXFNPTR is a better name. I also think
<br>> that the original idea from 2000 is a clever model, since it solves a common
<br>> issue when compiling unix source in Windows. Just note that for the patch to
<br>> work, it has to be consistently applied to all function pointers, leaving
<br>> the old macro name obsolete. Also note the changes in unistd.h.
<br>>
<br>> Cheers
<br>> Jerker B
<br>>
<br>>
<br>>
</div><br>Patch applied.
<br><br>-- Jeff J.
<br><p>From forum: <a href="http://old.nabble.com/Sourceware---newlib-list-f12241.html" embed="fixTarget[12241]" target="_top" >Sourceware - newlib list</a></p>
tag:old.nabble.com,2006:post-26833576
Re: RTEMS patch sweep 5
2009-12-17T11:26:52Z
2009-12-17T11:26:52Z
Jeff Johnston
On 17/12/09 01:45 AM, Ralf Corsepius wrote:
<br>> 2009-12-17 Ralf Corsépius<<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26833576&i=0" target="_top" rel="nofollow">ralf.corsepius@...</a>>
<br>>
<br>> * libc/include/machine/ieeefp.h: Rework __IEEE_*_ENDIAN handling.
<br>> * libc/machine/arm/machine/endian.h: Remove (Conflicts with
<br>> libc/include/machine/endian.h)
<br>>
<br><br>Patch applied.
<br><br>-- Jeff J.
<br><p>From forum: <a href="http://old.nabble.com/Sourceware---newlib-list-f12241.html" embed="fixTarget[12241]" target="_top" >Sourceware - newlib list</a></p>
tag:old.nabble.com,2006:post-26833549
Re: RTEMS patch sweep 4
2009-12-17T11:24:34Z
2009-12-17T11:24:34Z
Jeff Johnston
On 17/12/09 01:09 AM, Ralf Corsepius wrote:
<br>> 2009-12-17 Ralf Corsépius<<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26833549&i=0" target="_top" rel="nofollow">ralf.corsepius@...</a>>
<br>>
<br>> * libc/include/machine/setjmp.h: Set up _JBLEN #ifdef __m68k__.
<br>>
<br><br>Patch applied. Thanks.
<br><br>-- Jeff J.
<br><p>From forum: <a href="http://old.nabble.com/Sourceware---newlib-list-f12241.html" embed="fixTarget[12241]" target="_top" >Sourceware - newlib list</a></p>
tag:old.nabble.com,2006:post-26833527
Re: RTEMS patch sweep 3
2009-12-17T11:22:58Z
2009-12-17T11:22:58Z
Jeff Johnston
On 17/12/09 02:19 PM, Jeff Johnston wrote:
<div class='shrinkable-quote'><br>> On 17/12/09 11:55 AM, Ralf Corsepius wrote:
<br>>> On 12/17/2009 05:34 PM, Jeff Johnston wrote:
<br>>>> On 16/12/09 10:42 PM, Ralf Corsepius wrote:
<br>>>>> On 12/16/2009 07:45 PM, Jeff Johnston wrote:
<br>>>>>> On 16/12/09 12:53 PM, Ralf Corsepius wrote:
<br>>>>>>> On 12/16/2009 06:50 PM, Ralf Corsepius wrote:
<br>>>>>>>> Hi,
<br>>>>>>>>
<br>>>>>>>> ... and another one.
<br>>>>>>>>
<br>>>>>>>> This patch aims at making some parts of newlib more posix compliant.
<br>>>>>>>>
<br>>>>>>>> One part is #ifdef'ed __rtems__, because it relies on (POSIX) types
<br>>>>>>>> which (AFAICT) newlib currently are only supplies for RTEMS
<br>>>>>>>> (blksize_t,
<br>>>>>>>> blkcnt_t) and because we haven't tested it in other configurations
<br>>>>>>>> but
<br>>>>>>>> in RTEMS configurations.
<br>>>>>>>>
<br>>>>>>>> Ralf
<br>>>>>>>
<br>>>>>>> Oops, fingers faster than brains - The attachment containing the
<br>>>>>>> patch
<br>>>>>>> was missing ;)
<br>>>>>>>
<br>>>>>>> Ralf
<br>>>>>>
<br>>>>>> Shouldn't the added #endif be after the long st_spare4[]? Otherwise,
<br>>>>>> you
<br>>>>>> are changing the struct for the #if before it which normally wouldn't
<br>>>>>> have included this field.
<br>>>>>
<br>>>>> I am not sure. It would depend upon which purpose st_spare4 was
<br>>>>> intended
<br>>>>> to be used for, IMO.
<br>>>>>
<br>>>>> Probably it was only "having 2 longs in reserve" to void breaking
<br>>>>> backward compatibility, in case should one want to extend "struct
<br>>>>> stat".
<br>>>>>
<br>>>>>
<br>>>>> As we consider newlib-version upgrades to be "not ABI/API-preserving"
<br>>>>> and utilize newlib-version upgrades to deliberately break API/ABIs,
<br>>>>> this
<br>>>>> point is not of much importance to us.
<br>>>>>
<br>>>>> The only effect keeping st_spare4 should have on RTEMS would be
<br>>>>> "wasting
<br>>>>> 2 longs" on "struct stat" and keeping this field available should
<br>>>>> newlib
<br>>>>> start using it internally.
<br>>>>>
<br>>>>> That said, I don't have a problem with moving the #endif, such that
<br>>>>> st_spare4 stays also preserved on RTEMS.
<br>>>>>
<br>>>>> Below is an updated patch, now with st_spare4 kept for RTEMS.
<br>>>>>
<br>>>>> Ralf
<br>>>>
<br>>>> Actually, I am referring to the fact that the
<br>>>>
<br>>>> #if defined(__svr4__) && !defined(__PPC__) && !defined(__sun__)
<br>>>>
<br>>>> did not previously get the spare fields prior to your change. Now they
<br>>>> do. I believe that both #endifs belong after the spare fields.
<br>>> Ah, now I see! Yes, this wasn't intended. I had wanted to preserve the
<br>>> previous state for the non-rtems targets.
<br>>>
<br>>> Can you change this or shall I submit another patch?
<br>>>
<br>>> Ralf
<br>>>
<br>>
<br>> I'll fix it. Just wanted to make sure what was intended.
<br>>
<br>> -- Jeff J.
</div><br>Done with modification.
<br><br>-- Jeff J.
<br><p>From forum: <a href="http://old.nabble.com/Sourceware---newlib-list-f12241.html" embed="fixTarget[12241]" target="_top" >Sourceware - newlib list</a></p>
tag:old.nabble.com,2006:post-26833470
Re: RTEMS patch sweep 3
2009-12-17T11:19:09Z
2009-12-17T11:19:09Z
Jeff Johnston
On 17/12/09 11:55 AM, Ralf Corsepius wrote:
<div class='shrinkable-quote'><br>> On 12/17/2009 05:34 PM, Jeff Johnston wrote:
<br>>> On 16/12/09 10:42 PM, Ralf Corsepius wrote:
<br>>>> On 12/16/2009 07:45 PM, Jeff Johnston wrote:
<br>>>>> On 16/12/09 12:53 PM, Ralf Corsepius wrote:
<br>>>>>> On 12/16/2009 06:50 PM, Ralf Corsepius wrote:
<br>>>>>>> Hi,
<br>>>>>>>
<br>>>>>>> ... and another one.
<br>>>>>>>
<br>>>>>>> This patch aims at making some parts of newlib more posix compliant.
<br>>>>>>>
<br>>>>>>> One part is #ifdef'ed __rtems__, because it relies on (POSIX) types
<br>>>>>>> which (AFAICT) newlib currently are only supplies for RTEMS
<br>>>>>>> (blksize_t,
<br>>>>>>> blkcnt_t) and because we haven't tested it in other configurations
<br>>>>>>> but
<br>>>>>>> in RTEMS configurations.
<br>>>>>>>
<br>>>>>>> Ralf
<br>>>>>>
<br>>>>>> Oops, fingers faster than brains - The attachment containing the patch
<br>>>>>> was missing ;)
<br>>>>>>
<br>>>>>> Ralf
<br>>>>>
<br>>>>> Shouldn't the added #endif be after the long st_spare4[]? Otherwise,
<br>>>>> you
<br>>>>> are changing the struct for the #if before it which normally wouldn't
<br>>>>> have included this field.
<br>>>>
<br>>>> I am not sure. It would depend upon which purpose st_spare4 was intended
<br>>>> to be used for, IMO.
<br>>>>
<br>>>> Probably it was only "having 2 longs in reserve" to void breaking
<br>>>> backward compatibility, in case should one want to extend "struct stat".
<br>>>>
<br>>>>
<br>>>> As we consider newlib-version upgrades to be "not ABI/API-preserving"
<br>>>> and utilize newlib-version upgrades to deliberately break API/ABIs, this
<br>>>> point is not of much importance to us.
<br>>>>
<br>>>> The only effect keeping st_spare4 should have on RTEMS would be "wasting
<br>>>> 2 longs" on "struct stat" and keeping this field available should newlib
<br>>>> start using it internally.
<br>>>>
<br>>>> That said, I don't have a problem with moving the #endif, such that
<br>>>> st_spare4 stays also preserved on RTEMS.
<br>>>>
<br>>>> Below is an updated patch, now with st_spare4 kept for RTEMS.
<br>>>>
<br>>>> Ralf
<br>>>
<br>>> Actually, I am referring to the fact that the
<br>>>
<br>>> #if defined(__svr4__) && !defined(__PPC__) && !defined(__sun__)
<br>>>
<br>>> did not previously get the spare fields prior to your change. Now they
<br>>> do. I believe that both #endifs belong after the spare fields.
<br>> Ah, now I see! Yes, this wasn't intended. I had wanted to preserve the
<br>> previous state for the non-rtems targets.
<br>>
<br>> Can you change this or shall I submit another patch?
<br>>
<br>> Ralf
<br>>
</div><br>I'll fix it. Just wanted to make sure what was intended.
<br><br>-- Jeff J.
<br><p>From forum: <a href="http://old.nabble.com/Sourceware---newlib-list-f12241.html" embed="fixTarget[12241]" target="_top" >Sourceware - newlib list</a></p>
tag:old.nabble.com,2006:post-26831251
Re: RTEMS patch sweep 3
2009-12-17T08:55:21Z
2009-12-17T08:55:21Z
Ralf Corsepius-2
On 12/17/2009 05:34 PM, Jeff Johnston wrote:
<div class='shrinkable-quote'><br>> On 16/12/09 10:42 PM, Ralf Corsepius wrote:
<br>>> On 12/16/2009 07:45 PM, Jeff Johnston wrote:
<br>>>> On 16/12/09 12:53 PM, Ralf Corsepius wrote:
<br>>>>> On 12/16/2009 06:50 PM, Ralf Corsepius wrote:
<br>>>>>> Hi,
<br>>>>>>
<br>>>>>> ... and another one.
<br>>>>>>
<br>>>>>> This patch aims at making some parts of newlib more posix compliant.
<br>>>>>>
<br>>>>>> One part is #ifdef'ed __rtems__, because it relies on (POSIX) types
<br>>>>>> which (AFAICT) newlib currently are only supplies for RTEMS
<br>>>>>> (blksize_t,
<br>>>>>> blkcnt_t) and because we haven't tested it in other configurations
<br>>>>>> but
<br>>>>>> in RTEMS configurations.
<br>>>>>>
<br>>>>>> Ralf
<br>>>>>
<br>>>>> Oops, fingers faster than brains - The attachment containing the patch
<br>>>>> was missing ;)
<br>>>>>
<br>>>>> Ralf
<br>>>>
<br>>>> Shouldn't the added #endif be after the long st_spare4[]? Otherwise,
<br>>>> you
<br>>>> are changing the struct for the #if before it which normally wouldn't
<br>>>> have included this field.
<br>>>
<br>>> I am not sure. It would depend upon which purpose st_spare4 was intended
<br>>> to be used for, IMO.
<br>>>
<br>>> Probably it was only "having 2 longs in reserve" to void breaking
<br>>> backward compatibility, in case should one want to extend "struct stat".
<br>>>
<br>>>
<br>>> As we consider newlib-version upgrades to be "not ABI/API-preserving"
<br>>> and utilize newlib-version upgrades to deliberately break API/ABIs, this
<br>>> point is not of much importance to us.
<br>>>
<br>>> The only effect keeping st_spare4 should have on RTEMS would be "wasting
<br>>> 2 longs" on "struct stat" and keeping this field available should newlib
<br>>> start using it internally.
<br>>>
<br>>> That said, I don't have a problem with moving the #endif, such that
<br>>> st_spare4 stays also preserved on RTEMS.
<br>>>
<br>>> Below is an updated patch, now with st_spare4 kept for RTEMS.
<br>>>
<br>>> Ralf
<br>>
<br>> Actually, I am referring to the fact that the
<br>>
<br>> #if defined(__svr4__) && !defined(__PPC__) && !defined(__sun__)
<br>>
<br>> did not previously get the spare fields prior to your change. Now
<br>> they do. I believe that both #endifs belong after the spare fields.
</div>Ah, now I see! Yes, this wasn't intended. I had wanted to preserve the
<br>previous state for the non-rtems targets.
<br><br>Can you change this or shall I submit another patch?
<br><br>Ralf
<br><br><p>From forum: <a href="http://old.nabble.com/Sourceware---newlib-list-f12241.html" embed="fixTarget[12241]" target="_top" >Sourceware - newlib list</a></p>
tag:old.nabble.com,2006:post-26830905
Re: RTEMS patch sweep 3
2009-12-17T08:34:13Z
2009-12-17T08:34:13Z
Jeff Johnston
On 16/12/09 10:42 PM, Ralf Corsepius wrote:
<div class='shrinkable-quote'><br>> On 12/16/2009 07:45 PM, Jeff Johnston wrote:
<br>>> On 16/12/09 12:53 PM, Ralf Corsepius wrote:
<br>>>> On 12/16/2009 06:50 PM, Ralf Corsepius wrote:
<br>>>>> Hi,
<br>>>>>
<br>>>>> ... and another one.
<br>>>>>
<br>>>>> This patch aims at making some parts of newlib more posix compliant.
<br>>>>>
<br>>>>> One part is #ifdef'ed __rtems__, because it relies on (POSIX) types
<br>>>>> which (AFAICT) newlib currently are only supplies for RTEMS (blksize_t,
<br>>>>> blkcnt_t) and because we haven't tested it in other configurations but
<br>>>>> in RTEMS configurations.
<br>>>>>
<br>>>>> Ralf
<br>>>>
<br>>>> Oops, fingers faster than brains - The attachment containing the patch
<br>>>> was missing ;)
<br>>>>
<br>>>> Ralf
<br>>>
<br>>> Shouldn't the added #endif be after the long st_spare4[]? Otherwise, you
<br>>> are changing the struct for the #if before it which normally wouldn't
<br>>> have included this field.
<br>>
<br>> I am not sure. It would depend upon which purpose st_spare4 was intended
<br>> to be used for, IMO.
<br>>
<br>> Probably it was only "having 2 longs in reserve" to void breaking
<br>> backward compatibility, in case should one want to extend "struct stat".
<br>>
<br>>
<br>> As we consider newlib-version upgrades to be "not ABI/API-preserving"
<br>> and utilize newlib-version upgrades to deliberately break API/ABIs, this
<br>> point is not of much importance to us.
<br>>
<br>> The only effect keeping st_spare4 should have on RTEMS would be "wasting
<br>> 2 longs" on "struct stat" and keeping this field available should newlib
<br>> start using it internally.
<br>>
<br>> That said, I don't have a problem with moving the #endif, such that
<br>> st_spare4 stays also preserved on RTEMS.
<br>>
<br>> Below is an updated patch, now with st_spare4 kept for RTEMS.
<br>>
<br>> Ralf
</div><br>Actually, I am referring to the fact that the
<br><br>#if defined(__svr4__) && !defined(__PPC__) && !defined(__sun__)
<br><br>did not previously get the spare fields prior to your change. Now they
<br>do. I believe that both #endifs belong after the spare fields.
<br><br>-- Jeff J.
<br><p>From forum: <a href="http://old.nabble.com/Sourceware---newlib-list-f12241.html" embed="fixTarget[12241]" target="_top" >Sourceware - newlib list</a></p>
tag:old.nabble.com,2006:post-26830498
Re: RTEMS patch sweep
2009-12-17T08:10:58Z
2009-12-17T08:10:58Z
Jeff Johnston
On 16/12/09 10:10 PM, Ralf Corsepius wrote:
<div class='shrinkable-quote'><br>> On 12/16/2009 07:28 PM, Jeff Johnston wrote:
<br>>> On 16/12/09 12:28 PM, Ralf Corsepius wrote:
<br>>>> Hi,
<br>>>>
<br>>>> Below is a patch containing RTEMS-only patches to newlib, we would like
<br>>>> to see incorporated in the upcoming newlib tarball.
<br>>>>
<br>>>> Ralf
<br>>>
<br>>> Patch applied.
<br>>
<br>> Could it be you missed to
<br>> cvs add libc/sys/rtems/machine/_types.h ?
<br>>
<br>> Ralf
</div><br>Yes, thanks for catching that. Fixed.
<br><br>-- Jeff J.
<br><p>From forum: <a href="http://old.nabble.com/Sourceware---newlib-list-f12241.html" embed="fixTarget[12241]" target="_top" >Sourceware - newlib list</a></p>
tag:old.nabble.com,2006:post-26823941
RTEMS patch sweep 5
2009-12-16T22:45:43Z
2009-12-16T22:45:43Z
Ralf Corsepius-2
... and another one:
<br><br>This patch addresses 2 issues with newlib's arm support:
<br><br>* libc/machine/arm/machine/endian.h clashes with
<br>libc/include/machine/endian.h.
<br><br>The build machinery physically replaces libc/include/machine/endian.h
<br>with libc/machine/arm/machine/endian.h, resulting into broken installations.
<br><br>* Several subtile issues in arm fpu handling in ieeefp.h.
<br><br>Ralf
<br><br />2009-12-17 Ralf Corsépius <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26823941&i=0" target="_top" rel="nofollow">ralf.corsepius@...</a>>
<br><br> * libc/include/machine/ieeefp.h: Rework __IEEE_*_ENDIAN handling.
<br> * libc/machine/arm/machine/endian.h: Remove (Conflicts with
<br> libc/include/machine/endian.h)
<br><br>Index: libc/include/machine/ieeefp.h
<br>===================================================================
<br>RCS file: /cvs/src/src/newlib/libc/include/machine/ieeefp.h,v
<br>retrieving revision 1.43
<br>diff -u -r1.43 ieeefp.h
<br>--- libc/include/machine/ieeefp.h 10 Dec 2009 17:12:11 -0000 1.43
<br>+++ libc/include/machine/ieeefp.h 17 Dec 2009 06:36:39 -0000
<br>@@ -62,8 +62,12 @@
<br> # define __IEEE_BIG_ENDIAN
<br> # endif
<br> #else
<br>-# define __IEEE_BIG_ENDIAN
<br> # ifdef __ARMEL__
<br>+# define __IEEE_LITTLE_ENDIAN
<br>+# else
<br>+# define __IEEE_BIG_ENDIAN
<br>+# endif
<br>+# ifdef __ARMWEL__
<br> # define __IEEE_BYTES_LITTLE_ENDIAN
<br> # endif
<br> #endif
<br>Index: libc/machine/arm/machine/endian.h
<br>===================================================================
<br>RCS file: libc/machine/arm/machine/endian.h
<br>diff -N libc/machine/arm/machine/endian.h
<br>--- libc/machine/arm/machine/endian.h 7 May 2004 20:29:24 -0000 1.1
<br>+++ /dev/null 1 Jan 1970 00:00:00 -0000
<br>@@ -1,12 +0,0 @@
<br>-/* ARM configuration file */
<br>-
<br>-#ifndef _MACHINE_ENDIAN_H
<br>-# define _MACHINE_ENDIAN_H
<br>-
<br>-#ifdef __ARMEB__
<br>-#define BYTE_ORDER BIG_ENDIAN
<br>-#else
<br>-#define BYTE_ORDER LITTLE_ENDIAN
<br>-#endif
<br>-
<br>-#endif
<br><p>From forum: <a href="http://old.nabble.com/Sourceware---newlib-list-f12241.html" embed="fixTarget[12241]" target="_top" >Sourceware - newlib list</a></p>
tag:old.nabble.com,2006:post-26823670
RTEMS patch sweep 4
2009-12-16T22:09:37Z
2009-12-16T22:09:37Z
Ralf Corsepius-2
Hi,
<br><br>another RTEMS patch, we would like to see incorporated into the upcoming
<br>newlib release.
<br><br>We are carrying this patch with us for many years, but it for some
<br>reasons has never made it into the "official newlib".
<br><br>IIRC, it originates from GCC once having switched from unconditionally
<br>supplying __mc68000__ to __m68k__, many years ago, but I don't fully
<br>recall the reasons for us using this patch :(
<br><br>Ralf
<br><br />2009-12-17 Ralf Corsépius <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26823670&i=0" target="_top" rel="nofollow">ralf.corsepius@...</a>>
<br><br> * libc/include/machine/setjmp.h: Set up _JBLEN #ifdef __m68k__.
<br><br>Index: libc/include/machine/setjmp.h
<br>===================================================================
<br>RCS file: /cvs/src/src/newlib/libc/include/machine/setjmp.h,v
<br>retrieving revision 1.41
<br>diff -u -r1.41 setjmp.h
<br>--- libc/include/machine/setjmp.h 26 Oct 2009 10:05:22 -0000 1.41
<br>+++ libc/include/machine/setjmp.h 17 Dec 2009 04:45:49 -0000
<br>@@ -27,7 +27,7 @@
<br>
<br> /* necv70 was 9 as well. */
<br>
<br>-#ifdef __mc68000__
<br>+#if defined(__m68k__) || defined(__mc68000__)
<br> /*
<br> * onsstack,sigmask,sp,pc,psl,d2-d7,a2-a6,
<br> * fp2-fp7 for 68881.
<br><p>From forum: <a href="http://old.nabble.com/Sourceware---newlib-list-f12241.html" embed="fixTarget[12241]" target="_top" >Sourceware - newlib list</a></p>
tag:old.nabble.com,2006:post-26822859
Re: Joel's Only Outstanding RTEMS Newlib Patch
2009-12-16T20:13:28Z
2009-12-16T20:13:28Z
Ralf Corsepius-2
On 12/17/2009 12:00 AM, Joel Sherrill wrote:
<div class='shrinkable-quote'><br>> On 12/16/2009 04:12 PM, Jeff Johnston wrote:
<br>>> On 16/12/09 04:55 PM, Joel Sherrill wrote:
<br>>>> On 12/16/2009 03:37 PM, Jeff Johnston wrote:
<br>>>>> On 16/12/09 04:13 PM, Joel Sherrill wrote:
<br>>>>>> 2009-12-16 Joel Sherrill<<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26822859&i=0" target="_top" rel="nofollow">joel.sherrill@...</a>>
<br>>>>>>
<br>>>>>> * libc/sys/rtems/machine/param.h: Only use sizeof(double) -1
<br>>>>>> for ALIGNBYTES on SPARC.
<br>>>>> Patch checked in. I still need to hear from you guys regarding my
<br>>>>> comments to Ralf's 3rd patch (re: the #endif position).
<br>>>> I think your reading of the placement is right. I don't think
<br>>>> we want the st_spare4. That should only show up on
<br>>>> the "sun, etc." path.
<br>>>>
<br>>>> Is that what you mean?
<br>>>>
<br>>>> --joel
<br>>> Yes.
<br>>>
<br>> I think it is OK but it is midnight in Germany,
<br>> so Ralf will
<br>> probably not reply until he wakes up. :)
</div>Right, he just woke up and is checking emails ;)
<br><br>Wrt. st_spare4, cf. my other mail, I sent a couple of minutes ago.
<br><br>Wrt. your sparc-ALIGNBYTES patch: I think this patch is wrong, and feel
<br>are playing with symptoms of a bug lurking somewhere else:
<br><br>a) Keying ALIGNBYTES to sizeof(double) doesn't make any sense to me,
<br>because I don't see how doubles are related to alignment at all.
<br>Likely sizeof(double) (8 in your case) is big enough to give enough room
<br>to pamper over some other bug elsewhere.
<br><br>b) Alignment is a compiler-tuneable feature. It's wrong to hardcode it
<br>anywhere in newlib.
<br><br>Ralf
<br><p>From forum: <a href="http://old.nabble.com/Sourceware---newlib-list-f12241.html" embed="fixTarget[12241]" target="_top" >Sourceware - newlib list</a></p>
tag:old.nabble.com,2006:post-26822657
Re: RTEMS patch sweep 3
2009-12-16T19:42:58Z
2009-12-16T19:42:58Z
Ralf Corsepius-2
On 12/16/2009 07:45 PM, Jeff Johnston wrote:
<div class='shrinkable-quote'><div class='shrinkable-quote'><br>> On 16/12/09 12:53 PM, Ralf Corsepius wrote:
<br>>> On 12/16/2009 06:50 PM, Ralf Corsepius wrote:
<br>>>> Hi,
<br>>>>
<br>>>> ... and another one.
<br>>>>
<br>>>> This patch aims at making some parts of newlib more posix compliant.
<br>>>>
<br>>>> One part is #ifdef'ed __rtems__, because it relies on (POSIX) types
<br>>>> which (AFAICT) newlib currently are only supplies for RTEMS (blksize_t,
<br>>>> blkcnt_t) and because we haven't tested it in other configurations but
<br>>>> in RTEMS configurations.
<br>>>>
<br>>>> Ralf
<br>>>
<br>>> Oops, fingers faster than brains - The attachment containing the patch
<br>>> was missing ;)
<br>>>
<br>>> Ralf
<br>>
<br>> Shouldn't the added #endif be after the long st_spare4[]? Otherwise, you
<br>> are changing the struct for the #if before it which normally wouldn't
<br>> have included this field.
</div></div>I am not sure. It would depend upon which purpose st_spare4 was intended
<br>to be used for, IMO.
<br><br>Probably it was only "having 2 longs in reserve" to void breaking
<br>backward compatibility, in case should one want to extend "struct stat".
<br><br><br>As we consider newlib-version upgrades to be "not ABI/API-preserving"
<br>and utilize newlib-version upgrades to deliberately break API/ABIs, this
<br>point is not of much importance to us.
<br><br>The only effect keeping st_spare4 should have on RTEMS would be "wasting
<br>2 longs" on "struct stat" and keeping this field available should newlib
<br>start using it internally.
<br><br>That said, I don't have a problem with moving the #endif, such that
<br>st_spare4 stays also preserved on RTEMS.
<br><br>Below is an updated patch, now with st_spare4 kept for RTEMS.
<br><br>Ralf
<br><br />2009-12-17 Ralf Corsepius <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26822657&i=0" target="_top" rel="nofollow">ralf.corsepius@...</a>>
<br><br> * libc/include/pthread.h: Add pthread_atfork, pthread_rwlock_unlock
<br> * libc/include/sys/stat.h: Use struct timespec st_*tim,
<br> blksize_t st_blksize, blkcnt_t st_blocks.
<br> Add st_*time compatibility macros.
<br><br>Index: libc/include/pthread.h
<br>===================================================================
<br>RCS file: /cvs/src/src/newlib/libc/include/pthread.h,v
<br>retrieving revision 1.7
<br>diff -u -r1.7 pthread.h
<br>--- libc/include/pthread.h 17 Jun 2009 16:47:02 -0000 1.7
<br>+++ libc/include/pthread.h 16 Dec 2009 17:34:13 -0000
<br>@@ -33,21 +33,10 @@
<br> #include <time.h>
<br> #include <sys/sched.h>
<br>
<br>-/* Register Fork Handlers, P1003.1c/Draft 10, P1003.1c/Draft 10, p. 27
<br>-
<br>- If an OS does not support processes, then it falls under this provision
<br>- and may not provide pthread_atfork():
<br>-
<br>- "Either the implementation shall support the pthread_atfork() function
<br>- as described above or the pthread_atfork() funciton shall not be
<br>- provided."
<br>-
<br>- NOTE: RTEMS does not provide pthread_atfork(). */
<br>-
<br>-#if !defined(__rtems__) && !defined(__XMK__)
<br>-#warning "Add pthread_atfork() prototype"
<br>-#endif
<br>-
<br>+/* Register Fork Handlers */
<br>+int _EXFUN(pthread_atfork,(void (*prepare)(void), void (*parent)(void),
<br>+ void (*child)(void)));
<br>+
<br> /* Mutex Initialization Attributes, P1003.1c/Draft 10, p. 81 */
<br>
<br> int _EXFUN(pthread_mutexattr_init, (pthread_mutexattr_t *__attr));
<br>@@ -345,6 +334,7 @@
<br> int _EXFUN(pthread_rwlock_tryrdlock,(pthread_rwlock_t *__rwlock));
<br> int _EXFUN(pthread_rwlock_timedrdlock,
<br> (pthread_rwlock_t *__rwlock, _CONST struct timespec *__abstime));
<br>+int _EXFUN(pthread_rwlock_unlock,(pthread_rwlock_t *__rwlock));
<br> int _EXFUN(pthread_rwlock_wrlock,(pthread_rwlock_t *__rwlock));
<br> int _EXFUN(pthread_rwlock_trywrlock,(pthread_rwlock_t *__rwlock));
<br> int _EXFUN(pthread_rwlock_timedwrlock,
<br>Index: libc/include/sys/stat.h
<br>===================================================================
<br>RCS file: /cvs/src/src/newlib/libc/include/sys/stat.h,v
<br>retrieving revision 1.20
<br>diff -u -r1.20 stat.h
<br>--- libc/include/sys/stat.h 26 Apr 2008 07:49:39 -0000 1.20
<br>+++ libc/include/sys/stat.h 17 Dec 2009 03:40:53 -0000
<br>@@ -32,6 +32,13 @@
<br> gid_t st_gid;
<br> dev_t st_rdev;
<br> off_t st_size;
<br>+#if defined(__rtems__)
<br>+ struct timespec st_atim;
<br>+ struct timespec st_mtim;
<br>+ struct timespec st_ctim;
<br>+ blksize_t st_blksize;
<br>+ blkcnt_t st_blocks;
<br>+#else
<br> /* SysV/sco doesn't have the rest... But Solaris, eabi does. */
<br> #if defined(__svr4__) && !defined(__PPC__) && !defined(__sun__)
<br> time_t st_atime;
<br>@@ -46,9 +53,17 @@
<br> long st_spare3;
<br> long st_blksize;
<br> long st_blocks;
<br>- long st_spare4[2];
<br> #endif
<br>+#endif
<br>+ long st_spare4[2];
<br> };
<br>+
<br>+#if defined(__rtems__)
<br>+#define st_atime st_atim.tv_sec
<br>+#define st_ctime st_ctim.tv_sec
<br>+#define st_mtime st_mtim.tv_sec
<br>+#endif
<br>+
<br> #endif
<br>
<br> #define _IFMT 0170000 /* type of file */
<br><p>From forum: <a href="http://old.nabble.com/Sourceware---newlib-list-f12241.html" embed="fixTarget[12241]" target="_top" >Sourceware - newlib list</a></p>
tag:old.nabble.com,2006:post-26822455
Re: RTEMS patch sweep
2009-12-16T19:10:22Z
2009-12-16T19:10:22Z
Ralf Corsepius-2
On 12/16/2009 07:28 PM, Jeff Johnston wrote:
<br>> On 16/12/09 12:28 PM, Ralf Corsepius wrote:
<br>>> Hi,
<br>>>
<br>>> Below is a patch containing RTEMS-only patches to newlib, we would like
<br>>> to see incorporated in the upcoming newlib tarball.
<br>>>
<br>>> Ralf
<br>>
<br>> Patch applied.
<br><br>Could it be you missed to
<br>cvs add libc/sys/rtems/machine/_types.h ?
<br><br>Ralf
<br><p>From forum: <a href="http://old.nabble.com/Sourceware---newlib-list-f12241.html" embed="fixTarget[12241]" target="_top" >Sourceware - newlib list</a></p>
tag:old.nabble.com,2006:post-26821248
Re: Mixing function pointers and regular functions with the _EXFUN macro
2009-12-16T16:41:32Z
2009-12-16T16:41:32Z
Jerker Bäck-3
> Leave the original _EXPARM macro alone and create a new macro: _EXFNPTR
<br>> which you can define as you have changed _EXPARM. Use the new macro in
<br>> your patch and please post the finished patch "here" and not in the bug.
<br>> I am going to close bugzillas from now on immediately.
<br>>
<br>> If you can do this by tomorrow afternoon, I'll get the patch in for the
<br>> snapshot.
<br>>
<br>> -- Jeff J.
<br><br>OK, thanks!
<br><br>I agree completely with Craig that _EXFNPTR is a better name. I also think
<br>that the original idea from 2000 is a clever model, since it solves a common
<br>issue when compiling unix source in Windows. Just note that for the patch to
<br>work, it has to be consistently applied to all function pointers, leaving
<br>the old macro name obsolete. Also note the changes in unistd.h.
<br><br>Cheers
<br>Jerker B
<br><br><br><br><br /><br>Patch for enable calling conventions on function pointers
<br><br><br>Index: libc/include/_ansi.h
<br>===================================================================
<br>RCS file: /cvs/src/src/newlib/libc/include/_ansi.h,v
<br>retrieving revision 1.8
<br>diff -d -u -p -r1.8 _ansi.h
<br>--- libc/include/_ansi.h 21 Apr 2009 18:24:59 -0000 1.8
<br>+++ libc/include/_ansi.h 16 Dec 2009 22:18:44 -0000
<br>@@ -19,7 +19,7 @@
<br> /* FIXME: This probably needs some work. Perhaps sys/config.h can be
<br> prevailed upon to give us a clue. */
<br>
<br>#ifdef __STDC__
<br>
<br>@@ -59,12 +59,14 @@
<br> #define _VOID void
<br> #ifdef __CYGWIN__
<br> #define _EXFUN_NOTHROW(name, proto) __cdecl name proto _NOTHROW
<br>#define _EXFUN(name, proto) __cdecl name proto
<br> #define _EXPARM(name, proto) (* __cdecl name) proto
<br>+#define _EXFNPTR(name, proto) (__cdecl * name) proto
<br> #else
<br> #define _EXFUN_NOTHROW(name, proto) name proto _NOTHROW
<br> #define _EXFUN(name, proto) name proto
<br> #define _EXPARM(name, proto) (* name) proto
<br>+#define _EXFNPTR(name, proto) (* name) proto
<br> #endif
<br> #define _DEFUN(name, arglist, args) name(args)
<br> #define _DEFUN_VOID(name) name(_NOARGS)
<br><br>
<br>Index: libc/iconv/lib/conv.h
<br>===================================================================
<br>RCS file: /cvs/src/src/newlib/libc/iconv/lib/conv.h,v
<br>retrieving revision 1.1
<br>diff -d -u -p -r1.1 conv.h
<br>--- libc/iconv/lib/conv.h 25 Jun 2004 20:32:44 -0000 1.1
<br>+++ libc/iconv/lib/conv.h 16 Dec 2009 22:18:44 -0000
<br>@@ -63,7 +63,7 @@ typedef struct
<br> * Pointer to conversion-specific data if success. In case of error
<br> * returns NULL and sets current thread's/process's errno.
<br> */
<br>- _VOID_PTR _EXPARM(open, (struct _reent *rptr,
<br>+ _VOID_PTR _EXFNPTR(open, (struct _reent *rptr,
<br> _CONST char *to,
<br> _CONST char *from));
<br>
<br>@@ -81,7 +81,7 @@ typedef struct
<br> * When successful, returns (size_t)0. In case of error, sets current
<br> * thread's/process's errno and returns (size_t)-1 (same as iconv_open()).
<br> */
<br>- size_t _EXPARM(close, (struct _reent *rptr,
<br>+ size_t _EXFNPTR(close, (struct _reent *rptr,
<br> _VOID_PTR data));
<br>
<br> /* convert - perform encoding conversion.
<br>@@ -114,7 +114,7 @@ typedef struct
<br> * Reversible conversions are not counted. In case of error, sets current
<br> * thread's/process's errno and returns (size_t)-1 (same as iconv()).
<br> */
<br>- size_t _EXPARM(convert, (struct _reent *rptr,
<br>+ size_t _EXFNPTR(convert, (struct _reent *rptr,
<br> _VOID_PTR data,
<br> _CONST unsigned char **inbuf,
<br> size_t *inbytesleft,
<br>@@ -135,7 +135,7 @@ typedef struct
<br> * If 'direction' is 0, "from" encoding is tested, else
<br> * "to" encoding is tested.
<br> */
<br>- _VOID _EXPARM(get_state, (_VOID_PTR data,
<br>+ _VOID _EXFNPTR(get_state, (_VOID_PTR data,
<br> mbstate_t *state,
<br> int direction));
<br>
<br>@@ -154,7 +154,7 @@ typedef struct
<br> * "to" encoding is set.
<br> * Returns 0 if '*state' object has right format, -1 else.
<br> */
<br>- int _EXPARM(set_state, (_VOID_PTR data,
<br>+ int _EXFNPTR(set_state, (_VOID_PTR data,
<br> mbstate_t *state,
<br> int direction));
<br>
<br>@@ -170,7 +170,7 @@ typedef struct
<br> * If 'direction' is 0, "from" encoding is tested, else
<br> * "to" encoding is tested.
<br> */
<br>- int _EXPARM(get_mb_cur_max, (_VOID_PTR data,
<br>+ int _EXFNPTR(get_mb_cur_max, (_VOID_PTR data,
<br> int direction));
<br>
<br> /*
<br>@@ -185,7 +185,7 @@ typedef struct
<br> * If 'direction' is 0, "from" encoding is tested, else
<br> * "to" encoding is tested.
<br> */
<br>- int _EXPARM(is_stateful, (_VOID_PTR data,
<br>+ int _EXFNPTR(is_stateful, (_VOID_PTR data,
<br> int direction));
<br>
<br> } iconv_conversion_handlers_t;
<br><br><br>Index: libc/iconv/lib/ucsconv.h
<br>===================================================================
<br>RCS file: /cvs/src/src/newlib/libc/iconv/lib/ucsconv.h,v
<br>retrieving revision 1.1
<br>diff -d -u -p -r1.1 ucsconv.h
<br>--- libc/iconv/lib/ucsconv.h 25 Jun 2004 20:32:44 -0000 1.1
<br>+++ libc/iconv/lib/ucsconv.h 16 Dec 2009 22:18:44 -0000
<br>@@ -68,7 +68,7 @@ typedef struct
<br> * Returns CES-specific data pointer if success. In case of error returns
<br> * NULL and sets current thread's/process's errno.
<br> */
<br>- _VOID_PTR _EXPARM(init, (struct _reent *rptr,
<br>+ _VOID_PTR _EXFNPTR(init, (struct _reent *rptr,
<br> _CONST char *encoding));
<br>
<br> /*
<br>@@ -84,7 +84,7 @@ typedef struct
<br> * Returns (size_t)0 if success. In case of error returns (size_t)-1 and
<br> * sets current thread's/process's errno.
<br> */
<br>- size_t _EXPARM(close, (struct _reent *rptr,
<br>+ size_t _EXFNPTR(close, (struct _reent *rptr,
<br> _VOID_PTR data));
<br>
<br> /*
<br>@@ -96,7 +96,7 @@ typedef struct
<br> * DESCRIPTION:
<br> * Returns encoding's maximum character length.
<br> */
<br>- int _EXPARM(get_mb_cur_max, (_VOID_PTR data));
<br>+ int _EXFNPTR(get_mb_cur_max, (_VOID_PTR data));
<br>
<br> /*
<br> * get_state - get current shift state.
<br>@@ -108,7 +108,7 @@ typedef struct
<br> * DESCRIPTION:
<br> * Returns encoding's current shift sequence.
<br> */
<br>- _VOID _EXPARM(get_state, (_VOID_PTR data,
<br>+ _VOID _EXFNPTR(get_state, (_VOID_PTR data,
<br> mbstate_t *state));
<br>
<br> /*
<br>@@ -123,7 +123,7 @@ typedef struct
<br> * object is zero-object - reset current shift state.
<br> * Returns 0 if '*state' object has right format, -1 else.
<br> */
<br>- int _EXPARM(set_state, (_VOID_PTR data,
<br>+ int _EXFNPTR(set_state, (_VOID_PTR data,
<br> mbstate_t *state));
<br>
<br> /*
<br>@@ -135,7 +135,7 @@ typedef struct
<br> * DESCRIPTION:
<br> * Returns 0 if encoding is stateless, else returns 1.
<br> */
<br>- int _EXPARM(is_stateful, (_VOID_PTR data));
<br>+ int _EXFNPTR(is_stateful, (_VOID_PTR data));
<br>
<br> /*
<br> * convert_to_ucs - convert character to UCS.
<br>@@ -155,7 +155,7 @@ typedef struct
<br> * returns ICONV_CES_INVALID_CHARACTER. If invalid or incomplete bytes
<br> * sequence was met, returns ICONV_CES_BAD_SEQUENCE.
<br> */
<br>- ucs4_t _EXPARM(convert_to_ucs, (_VOID_PTR data,
<br>+ ucs4_t _EXFNPTR(convert_to_ucs, (_VOID_PTR data,
<br> _CONST unsigned char **inbuf,
<br> size_t *inbytesleft));
<br> } iconv_to_ucs_ces_handlers_t;
<br>@@ -172,26 +172,26 @@ typedef struct
<br> typedef struct
<br> {
<br> /* Same as in iconv_to_ucs_ces_handlers_t */
<br>- _VOID_PTR _EXPARM(init, (struct _reent *rptr,
<br>+ _VOID_PTR _EXFNPTR(init, (struct _reent *rptr,
<br> _CONST char *encoding));
<br>
<br> /* Same as in iconv_to_ucs_ces_handlers_t */
<br>- size_t _EXPARM(close, (struct _reent *rptr,
<br>+ size_t _EXFNPTR(close, (struct _reent *rptr,
<br> _VOID_PTR data));
<br>
<br> /* Same as in iconv_to_ucs_ces_handlers_t */
<br>- int _EXPARM(get_mb_cur_max, (_VOID_PTR data));
<br>+ int _EXFNPTR(get_mb_cur_max, (_VOID_PTR data));
<br>
<br> /* Same as in iconv_to_ucs_ces_handlers_t */
<br>- _VOID _EXPARM(get_state, (_VOID_PTR data,
<br>+ _VOID _EXFNPTR(get_state, (_VOID_PTR data,
<br> mbstate_t *state));
<br>
<br> /* Same as in iconv_to_ucs_ces_handlers_t */
<br>- int _EXPARM(set_state, (_VOID_PTR data,
<br>+ int _EXFNPTR(set_state, (_VOID_PTR data,
<br> mbstate_t *state));
<br>
<br> /* Same as in iconv_to_ucs_ces_handlers_t */
<br>- int _EXPARM(is_stateful, (_VOID_PTR data));
<br>+ int _EXFNPTR(is_stateful, (_VOID_PTR data));
<br>
<br> /*
<br> * convert_from_ucs - convert UCS character to destination encoding.
<br>@@ -215,7 +215,7 @@ typedef struct
<br> * If there is no corresponding character in destination encoding, returns
<br> * ICONV_CES_INVALID_CHARACTER.
<br> */
<br>- size_t _EXPARM(convert_from_ucs, (_VOID_PTR data,
<br>+ size_t _EXFNPTR(convert_from_ucs, (_VOID_PTR data,
<br> ucs4_t in,
<br> unsigned char **outbuf,
<br> size_t *outbytesleft));
<br><br><br>Index: libc/include/stdlib.h
<br>===================================================================
<br>RCS file: /cvs/src/src/newlib/libc/include/stdlib.h,v
<br>retrieving revision 1.36
<br>diff -d -u -p -r1.36 stdlib.h
<br>--- libc/include/stdlib.h 22 Sep 2009 21:49:20 -0000 1.36
<br>+++ libc/include/stdlib.h 16 Dec 2009 22:18:44 -0000
<br>@@ -74,7 +74,7 @@ _PTR _EXFUN(bsearch,(const _PTR __key,
<br> const _PTR __base,
<br> size_t __nmemb,
<br> size_t __size,
<br>- int _EXPARM(_compar,(const _PTR, const _PTR))));
<br>+ int _EXFNPTR(_compar,(const _PTR, const _PTR))));
<br> _PTR _EXFUN_NOTHROW(calloc,(size_t __nmemb, size_t __size));
<br> div_t _EXFUN(div,(int __numer, int __denom));
<br> _VOID _EXFUN(exit,(int __status) _ATTRIBUTE ((noreturn)));
<br><br>Index: libc/include/sys/reent.h
<br>===================================================================
<br>RCS file: /cvs/src/src/newlib/libc/include/sys/reent.h,v
<br>retrieving revision 1.47
<br>diff -d -u -p -r1.47 reent.h
<br>--- libc/include/sys/reent.h 23 Nov 2009 17:02:19 -0000 1.47
<br>+++ libc/include/sys/reent.h 16 Dec 2009 22:18:45 -0000
<br>@@ -182,12 +182,12 @@ struct __sFILE {
<br> /* operations */
<br> _PTR _cookie; /* cookie passed to io functions */
<br>
<br>- _READ_WRITE_RETURN_TYPE _EXFUN((*_read),(struct _reent *, _PTR,
<br>+ _READ_WRITE_RETURN_TYPE _EXFNPTR(_read, (struct _reent *, _PTR,
<br> char *, int));
<br>- _READ_WRITE_RETURN_TYPE _EXFUN((*_write),(struct _reent *, _PTR,
<br>+ _READ_WRITE_RETURN_TYPE _EXFNPTR(_write, (struct _reent *, _PTR,
<br> const char *, int));
<br>- _fpos_t _EXFUN((*_seek),(struct _reent *, _PTR, _fpos_t, int));
<br>- int _EXFUN((*_close),(struct _reent *, _PTR));
<br>+ _fpos_t _EXFNPTR(_seek, (struct _reent *, _PTR, _fpos_t, int));
<br>+ int _EXFNPTR(_close, (struct _reent *, _PTR));
<br>
<br> /* separate buffer for long sequences of ungetc() */
<br> struct __sbuf _ub; /* ungetc buffer */
<br>@@ -237,12 +237,12 @@ struct __sFILE64 {
<br> /* operations */
<br> _PTR _cookie; /* cookie passed to io functions */
<br>
<br>- _READ_WRITE_RETURN_TYPE _EXFUN((*_read),(struct _reent *, _PTR,
<br>+ _READ_WRITE_RETURN_TYPE _EXFNPTR(_read, (struct _reent *, _PTR,
<br> char *, int));
<br>- _READ_WRITE_RETURN_TYPE _EXFUN((*_write),(struct _reent *, _PTR,
<br>+ _READ_WRITE_RETURN_TYPE _EXFNPTR(_write, (struct _reent *, _PTR,
<br> const char *, int));
<br>- _fpos_t _EXFUN((*_seek),(struct _reent *, _PTR, _fpos_t, int));
<br>- int _EXFUN((*_close),(struct _reent *, _PTR));
<br>+ _fpos_t _EXFNPTR(_seek, (struct _reent *, _PTR, _fpos_t, int));
<br>+ int _EXFNPTR(_close, (struct _reent *, _PTR));
<br>
<br> /* separate buffer for long sequences of ungetc() */
<br> struct __sbuf _ub; /* ungetc buffer */
<br>@@ -261,7 +261,7 @@ struct __sFILE64 {
<br> int _flags2; /* for future use */
<br>
<br> _off64_t _offset; /* current lseek offset */
<br>- _fpos64_t _EXFUN((*_seek64),(struct _reent *, _PTR, _fpos64_t, int));
<br>+ _fpos64_t _EXFNPTR(_seek64, (struct _reent *, _PTR, _fpos64_t, int));
<br>
<br> #ifndef __SINGLE_THREAD__
<br> _flock_t _lock; /* for thread-safety locking */
<br>@@ -376,7 +376,7 @@ struct _reent
<br>
<br> struct _mprec *_mp;
<br>
<br>- void _EXFUN((*__cleanup),(struct _reent *));
<br>+ void _EXFNPTR(__cleanup, (struct _reent *));
<br>
<br> int _gamma_signgam;
<br>
<br>@@ -593,7 +593,7 @@ struct _reent
<br>
<br> int __sdidinit; /* 1 means stdio has been init'd */
<br>
<br>- void _EXFUN((*__cleanup),(struct _reent *));
<br>+ void _EXFNPTR(__cleanup, (struct _reent *));
<br>
<br> /* used by mprec routines */
<br> struct _Bigint *_result;
<br><br><br>Index: libc/include/sys/unistd.h
<br>===================================================================
<br>RCS file: /cvs/src/src/newlib/libc/include/sys/unistd.h,v
<br>retrieving revision 1.73
<br>diff -d -u -p -r1.73 unistd.h
<br>--- libc/include/sys/unistd.h 8 Dec 2009 13:50:41 -0000 1.73
<br>+++ libc/include/sys/unistd.h 16 Dec 2009 22:18:45 -0000
<br>@@ -30,8 +30,8 @@ int _EXFUN(close, (int __fildes ));
<br> #if defined(__CYGWIN__)
<br> size_t _EXFUN(confstr, (int __name, char *__buf, size_t __len));
<br> #endif
<br>-char _EXFUN(*ctermid, (char *__s ));
<br>-char _EXFUN(*cuserid, (char *__s ));
<br>+char * _EXFUN(ctermid, (char *__s ));
<br>+char * _EXFUN(cuserid, (char *__s ));
<br> #if defined(__CYGWIN__)
<br> int _EXFUN(daemon, (int nochdir, int noclose));
<br> #endif
<br>@@ -67,7 +67,7 @@ pid_t _EXFUN(fork, (void ));
<br> long _EXFUN(fpathconf, (int __fd, int __name ));
<br> int _EXFUN(fsync, (int __fd));
<br> int _EXFUN(fdatasync, (int __fd));
<br>-char _EXFUN(*getcwd, (char *__buf, size_t __size ));
<br>+char * _EXFUN(getcwd, (char *__buf, size_t __size ));
<br> #if defined(__CYGWIN__)
<br> int _EXFUN(getdomainname ,(char *__name, size_t __len));
<br> #endif
<br>@@ -80,11 +80,11 @@ int _EXFUN(getgroups, (int __gidsets
<br> #if defined(__CYGWIN__)
<br> long _EXFUN(gethostid, (void));
<br> #endif
<br>-char _EXFUN(*getlogin, (void ));
<br>+char * _EXFUN(getlogin, (void ));
<br> #if defined(_POSIX_THREAD_SAFE_FUNCTIONS)
<br> int _EXFUN(getlogin_r, (char *name, size_t namesize) );
<br> #endif
<br>-char _EXFUN(*getpass, (const char *__prompt));
<br>+char * _EXFUN(getpass, (const char *__prompt));
<br> int _EXFUN(getpagesize, (void));
<br> #if defined(__CYGWIN__)
<br> int _EXFUN(getpeereid, (int, uid_t *, gid_t *));
<br>@@ -101,7 +101,7 @@ uid_t _EXFUN(getuid, (void ));
<br> #endif
<br> #ifdef __CYGWIN__
<br> char * _EXFUN(getusershell, (void));
<br>-char _EXFUN(*getwd, (char *__buf ));
<br>+char * _EXFUN(getwd, (char *__buf ));
<br> int _EXFUN(iruserok, (unsigned long raddr, int superuser, const char *ruser, const char *luser));
<br> #endif
<br> int _EXFUN(isatty, (int __fildes ));
<br>@@ -169,7 +169,7 @@ void _EXFUN(swab, (const void *, void
<br> long _EXFUN(sysconf, (int __name ));
<br> pid_t _EXFUN(tcgetpgrp, (int __fildes ));
<br> int _EXFUN(tcsetpgrp, (int __fildes, pid_t __pgrp_id ));
<br>-char _EXFUN(*ttyname, (int __fildes ));
<br>+char * _EXFUN(ttyname, (int __fildes ));
<br> #if defined(__CYGWIN__) || defined(__rtems__)
<br> int _EXFUN(ttyname_r, (int, char *, size_t));
<br> #endif
<br><br>Index: libc/search/bsearch.c
<br>===================================================================
<br>RCS file: /cvs/src/src/newlib/libc/search/bsearch.c,v
<br>retrieving revision 1.1
<br>diff -d -u -p -r1.1 bsearch.c
<br>--- libc/search/bsearch.c 20 Jun 2002 19:51:31 -0000 1.1
<br>+++ libc/search/bsearch.c 16 Dec 2009 22:18:47 -0000
<br>@@ -69,7 +69,7 @@ _DEFUN (bsearch, (key, base, nmemb, size
<br> _CONST _PTR base _AND
<br> size_t nmemb _AND
<br> size_t size _AND
<br>- int _EXFUN ((*compar), (const _PTR, const _PTR)))
<br>+ int _EXFNPTR(compar, (const _PTR, const _PTR)))
<br> {
<br> _PTR current;
<br> size_t lower = 0;
<br><br>Index: libc/stdio/fseek.c
<br>===================================================================
<br>RCS file: /cvs/src/src/newlib/libc/stdio/fseek.c,v
<br>retrieving revision 1.22
<br>diff -d -u -p -r1.22 fseek.c
<br>--- libc/stdio/fseek.c 24 Apr 2009 22:52:52 -0000 1.22
<br>+++ libc/stdio/fseek.c 16 Dec 2009 22:18:47 -0000
<br>@@ -123,7 +123,7 @@ _DEFUN(_fseek_r, (ptr, fp, offset, whenc
<br> long offset _AND
<br> int whence)
<br> {
<br>- _fpos_t _EXFUN((*seekfn), (struct _reent *, _PTR, _fpos_t, int));
<br>+ _fpos_t _EXFNPTR(seekfn, (struct _reent *, _PTR, _fpos_t, int));
<br> _fpos_t target;
<br> _fpos_t curoff = 0;
<br><br>Index: libc/stdio64/fseeko64.c
<br>===================================================================
<br>RCS file: /cvs/src/src/newlib/libc/stdio64/fseeko64.c,v
<br>retrieving revision 1.13
<br>diff -d -u -p -r1.13 fseeko64.c
<br>--- libc/stdio64/fseeko64.c 24 Nov 2008 17:15:43 -0000 1.13
<br>+++ libc/stdio64/fseeko64.c 16 Dec 2009 22:18:47 -0000
<br>@@ -104,7 +104,7 @@ _DEFUN (_fseeko64_r, (ptr, fp, offset, w
<br> _off64_t offset _AND
<br> int whence)
<br> {
<br>- _fpos64_t _EXFUN ((*seekfn), (struct _reent *, void *, _fpos64_t, int));
<br>+ _fpos64_t _EXFNPTR(seekfn, (struct _reent *, void *, _fpos64_t, int));
<br> _fpos64_t target, curoff;
<br> size_t n;
<br><br>Index: libc/stdlib/atexit.c
<br>===================================================================
<br>RCS file: /cvs/src/src/newlib/libc/stdlib/atexit.c,v
<br>retrieving revision 1.7
<br>diff -d -u -p -r1.7 atexit.c
<br>--- libc/stdlib/atexit.c 9 Sep 2004 19:46:54 -0000 1.7
<br>+++ libc/stdlib/atexit.c 16 Dec 2009 22:18:47 -0000
<br>@@ -60,7 +60,7 @@ Supporting OS subroutines required: <<cl
<br> int
<br> _DEFUN (atexit,
<br> (fn),
<br>- _VOID _EXFUN ((*fn), (_VOID)))
<br>+ _VOID _EXFNPTR(fn, (_VOID)))
<br> {
<br> return __register_exitproc (__et_atexit, fn, NULL, NULL);
<br> }
<br><br>Index: libc/stdlib/on_exit.c
<br>===================================================================
<br>RCS file: /cvs/src/src/newlib/libc/stdlib/on_exit.c,v
<br>retrieving revision 1.4
<br>diff -d -u -p -r1.4 on_exit.c
<br>--- libc/stdlib/on_exit.c 9 Sep 2004 19:46:54 -0000 1.4
<br>+++ libc/stdlib/on_exit.c 16 Dec 2009 22:18:47 -0000
<br>@@ -65,7 +65,7 @@ Supporting OS subroutines required: None
<br> int
<br> _DEFUN (on_exit,
<br> (fn, arg),
<br>- _VOID _EXFUN ((*fn), (int, _PTR)) _AND
<br>+ _VOID _EXFNPTR(fn, (int, _PTR)) _AND
<br> _PTR arg)
<br> {
<br> return __register_exitproc (__et_onexit, (void (*)(void)) fn, arg, NULL);
<br><br><br><p>From forum: <a href="http://old.nabble.com/Sourceware---newlib-list-f12241.html" embed="fixTarget[12241]" target="_top" >Sourceware - newlib list</a></p>
tag:old.nabble.com,2006:post-26820049
Re: Joel's Only Outstanding RTEMS Newlib Patch
2009-12-16T15:00:15Z
2009-12-16T15:00:15Z
Joel Sherrill <joel@OARcorp.com>
On 12/16/2009 04:12 PM, Jeff Johnston wrote:
<div class='shrinkable-quote'><br>> On 16/12/09 04:55 PM, Joel Sherrill wrote:
<br>>
<br>>> On 12/16/2009 03:37 PM, Jeff Johnston wrote:
<br>>>
<br>>>> On 16/12/09 04:13 PM, Joel Sherrill wrote:
<br>>>>
<br>>>>> 2009-12-16 Joel Sherrill<<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26820049&i=0" target="_top" rel="nofollow">joel.sherrill@...</a>>
<br>>>>>
<br>>>>> * libc/sys/rtems/machine/param.h: Only use sizeof(double) -1
<br>>>>> for ALIGNBYTES on SPARC.
<br>>>>>
<br>>>> Patch checked in. I still need to hear from you guys regarding my
<br>>>> comments to Ralf's 3rd patch (re: the #endif position).
<br>>>>
<br>>> I think your reading of the placement is right. I don't think
<br>>> we want the st_spare4. That should only show up on
<br>>> the "sun, etc." path.
<br>>>
<br>>> Is that what you mean?
<br>>>
<br>>> --joel
<br>>>
<br>> Yes.
<br>>
<br>>
</div>I think it is OK but it is midnight in Germany so Ralf will
<br>probably not reply until he wakes up. :)
<br><br>--joel
<br>> -- Jeff J.
<br>>
<br><br><br>--
<br>Joel Sherrill, Ph.D. Director of Research& Development
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26820049&i=1" target="_top" rel="nofollow">joel.sherrill@...</a> On-Line Applications Research
<br>Ask me about RTEMS: a free RTOS Huntsville AL 35805
<br> Support Available (256) 722-9985
<br><br><br><p>From forum: <a href="http://old.nabble.com/Sourceware---newlib-list-f12241.html" embed="fixTarget[12241]" target="_top" >Sourceware - newlib list</a></p>
tag:old.nabble.com,2006:post-26819392
Re: Joel's Only Outstanding RTEMS Newlib Patch
2009-12-16T14:12:09Z
2009-12-16T14:12:09Z
Jeff Johnston
On 16/12/09 04:55 PM, Joel Sherrill wrote:
<div class='shrinkable-quote'><br>> On 12/16/2009 03:37 PM, Jeff Johnston wrote:
<br>>> On 16/12/09 04:13 PM, Joel Sherrill wrote:
<br>>>> 2009-12-16 Joel Sherrill<<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26819392&i=0" target="_top" rel="nofollow">joel.sherrill@...</a>>
<br>>>>
<br>>>> * libc/sys/rtems/machine/param.h: Only use sizeof(double) -1
<br>>>> for ALIGNBYTES on SPARC.
<br>>> Patch checked in. I still need to hear from you guys regarding my
<br>>> comments to Ralf's 3rd patch (re: the #endif position).
<br>> I think your reading of the placement is right. I don't think
<br>> we want the st_spare4. That should only show up on
<br>> the "sun, etc." path.
<br>>
<br>> Is that what you mean?
<br>>
<br>> --joel
</div><br>Yes.
<br><br>-- Jeff J.
<br><p>From forum: <a href="http://old.nabble.com/Sourceware---newlib-list-f12241.html" embed="fixTarget[12241]" target="_top" >Sourceware - newlib list</a></p>
tag:old.nabble.com,2006:post-26819152
Re: Joel's Only Outstanding RTEMS Newlib Patch
2009-12-16T13:55:06Z
2009-12-16T13:55:06Z
Joel Sherrill <joel@OARcorp.com>
On 12/16/2009 03:37 PM, Jeff Johnston wrote:
<br>> On 16/12/09 04:13 PM, Joel Sherrill wrote:
<br>>
<br>>> 2009-12-16 Joel Sherrill<<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26819152&i=0" target="_top" rel="nofollow">joel.sherrill@...</a>>
<br>>>
<br>>> * libc/sys/rtems/machine/param.h: Only use sizeof(double) -1
<br>>> for ALIGNBYTES on SPARC.
<br>>>
<br>> Patch checked in. I still need to hear from you guys regarding my
<br>> comments to Ralf's 3rd patch (re: the #endif position).
<br>I think your reading of the placement is right. I don't think
<br>we want the st_spare4. That should only show up on
<br>the "sun, etc." path.
<br><br>Is that what you mean?
<br><br>--joel
<br><p>From forum: <a href="http://old.nabble.com/Sourceware---newlib-list-f12241.html" embed="fixTarget[12241]" target="_top" >Sourceware - newlib list</a></p>
tag:old.nabble.com,2006:post-26818903
Re: Joel's Only Outstanding RTEMS Newlib Patch
2009-12-16T13:37:07Z
2009-12-16T13:37:07Z
Jeff Johnston
On 16/12/09 04:13 PM, Joel Sherrill wrote:
<br>> 2009-12-16 Joel Sherrill <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26818903&i=0" target="_top" rel="nofollow">joel.sherrill@...</a>>
<br>>
<br>> * libc/sys/rtems/machine/param.h: Only use sizeof(double) -1
<br>> for ALIGNBYTES on SPARC.
<br><br>Patch checked in. I still need to hear from you guys regarding my
<br>comments to Ralf's 3rd patch (re: the #endif position).
<br><br>-- Jeff J.
<br><p>From forum: <a href="http://old.nabble.com/Sourceware---newlib-list-f12241.html" embed="fixTarget[12241]" target="_top" >Sourceware - newlib list</a></p>
tag:old.nabble.com,2006:post-26818581
Joel's Only Outstanding RTEMS Newlib Patch
2009-12-16T13:13:30Z
2009-12-16T13:13:30Z
Joel Sherrill <joel@OARcorp.com>
Hi,
<br><br>A while back I submitted a patch to use sizeof(double)-1
<br>for ALIGNBYTES to avoid an unaligned access on SPARC.
<br>param.h in BSD is target specific and this made it safe
<br>but larger than necessary. The attached patch makes
<br>if "sizeof(double)-1" for SPARC and retains the old
<br>value of "sizeof(int) - 1" for other targets.
<br><br>Our machine/param.h came from i386 so it isn't that surprising
<br>that it turned up an issue on a RISC CPU. It just took a long
<br>time and "ls" ported from BSD. :)
<br><br>2009-12-16 Joel Sherrill <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26818581&i=0" target="_top" rel="nofollow">joel.sherrill@...</a>>
<br><br> * libc/sys/rtems/machine/param.h: Only use sizeof(double) -1
<br> for ALIGNBYTES on SPARC.
<br><br>--
<br>Joel Sherrill, Ph.D. Director of Research& Development
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26818581&i=1" target="_top" rel="nofollow">joel.sherrill@...</a> On-Line Applications Research
<br>Ask me about RTEMS: a free RTOS Huntsville AL 35805
<br> Support Available (256) 722-9985
<br><br><br><br />Index: libc/sys/rtems/machine/param.h
<br>===================================================================
<br>RCS file: /cvs/src/src/newlib/libc/sys/rtems/machine/param.h,v
<br>retrieving revision 1.3
<br>diff -u -r1.3 param.h
<br>--- libc/sys/rtems/machine/param.h 19 Jun 2009 18:15:35 -0000 1.3
<br>+++ libc/sys/rtems/machine/param.h 16 Dec 2009 21:09:13 -0000
<br>@@ -19,7 +19,11 @@
<br> * for all data types (int, long, ...). The result is unsigned int
<br> * and must be cast to any desired pointer type.
<br> */
<br>+#if defined(__sparc__)
<br> #define ALIGNBYTES (sizeof(double) - 1)
<br>+#else
<br>+#define ALIGNBYTES (sizeof(int) - 1)
<br>+#endif
<br> #define ALIGN(p) (((unsigned)(p) + ALIGNBYTES) & ~ALIGNBYTES)
<br>
<br> #define PAGE_SHIFT 12 /* LOG2(PAGE_SIZE) */
<br><p>From forum: <a href="http://old.nabble.com/Sourceware---newlib-list-f12241.html" embed="fixTarget[12241]" target="_top" >Sourceware - newlib list</a></p>
tag:old.nabble.com,2006:post-26817542
Re: Infineon xc16x support
2009-12-16T12:02:10Z
2009-12-16T12:02:10Z
Jeff Johnston
On 16/12/09 02:42 PM, Conny Marco Menebröcker wrote:
<div class='shrinkable-quote'><br>> On Tuesday 15 December 2009 20:35:07 Jeff Johnston wrote:
<br>>> On 15/12/09 01:48 PM, Conny Marco Menebröcker wrote:
<br>>>> On Thursday 10 December 2009 18:22:19 Jeff Johnston wrote:
<br>>>>> On 04/12/09 12:34 PM, Conny Marco Menebröcker wrote:
<br>>>>>> On Sunday 15 November 2009 10:38:52 Conny Marco Menebröcker wrote:
<br>>>>>>> Hi,
<br>>>>>>>
<br>>>>>>> sorry my first patch file was defect.
<br>>>>>>> I've got problems sending my patch as atachment. The last mails got
<br>>>>>>> all lost, without any debounce mail. So please donload the file:
<br>>>>>>>
<br>>>>>>> <a href="http://www.menebroecker-web.de/wp-content/uploads/2009/11/newlib_xc16x" target="_top" rel="nofollow">http://www.menebroecker-web.de/wp-content/uploads/2009/11/newlib_xc16x</a><br>>>>>>> .t ar. gz
<br>>>>>>>
<br>>>>>>> Thanks and best regards,
<br>>>>>>> Conny
<br>>>>>>
<br>>>>>> Hi,
<br>>>>>>
<br>>>>>> please review my patch.
<br>>>>>>
<br>>>>>> Best regards,
<br>>>>>>
<br>>>>>> Conny
<br>>>>>
<br>>>>> Patch has been committed with the following changes:
<br>>>>>
<br>>>>> putchar.c has been moved to libc/machine/xc16x and its prototype has
<br>>>>> been changed to accept an int rather than a char, per ANSI.
<br>>>>>
<br>>>>> puts.c has also been moved libc/machine/xc16x.
<br>>>>>
<br>>>>> You should understand that the shared putchar macro in stdio.h will get
<br>>>>> invoked by any user including stdio.h unless they surround the function
<br>>>>> call with parentheses or #undef the macro. It calls putc() which
<br>>>>> eventually will end up using your write syscall in libgloss. I'm not
<br>>>>> sure why you chose to override this particular function by itself other
<br>>>>> than a possible performance improvement or experiment, but be aware of
<br>>>>> the previous information. If it was only meant as an experiment, feel
<br>>>>> free to request it being removed.
<br>>>>>
<br>>>>> I regenerated the autotool files locally.
<br>>>>>
<br>>>>> Regards,
<br>>>>>
<br>>>>> -- Jeff J.
<br>>>>
<br>>>> Hi Jeff,
<br>>>>
<br>>>> thank you for commiting my patch. But there is a typing error in
<br>>>> makefile.am. Please see attached my patch. This time I used
<br>>>> automake-1.11, so I think you can use my patch without regenerating the
<br>>>> autotool files.
<br>>>>
<br>>>> As I wrote in my first email, I just reworked the patch from Shrirang
<br>>>> Khishti. So I am not sure why he overrides the putchar function. But I
<br>>>> will work on it in the next days.
<br>>>>
<br>>>> Best regards
<br>>>>
<br>>>> Conny
<br>>>
<br>>> Typo fixed and file regenerated. I usually regenerate the files myself
<br>>> to avoid inconsistencies between autoconf/automake releases.
<br>>>
<br>>> -- Jeff J.
<br>>>
<br>> Hi Jeff,
<br>>
<br>> Sorry, but I did some mistakes in the configure and makefiles for libgloss.
<br>> Please see attached another patch.
<br>>
<br>> Best regards
<br>>
<br>> Conny
<br>>
</div><br>Patch applied without change to generated files which I generated here.
<br><br>-- Jeff J.
<br><p>From forum: <a href="http://old.nabble.com/Sourceware---newlib-list-f12241.html" embed="fixTarget[12241]" target="_top" >Sourceware - newlib list</a></p>
tag:old.nabble.com,2006:post-26817240
Re: Infineon xc16x support
2009-12-16T11:42:37Z
2009-12-16T11:42:37Z
Conny Marco Menebröcker-3
On Tuesday 15 December 2009 20:35:07 Jeff Johnston wrote:
<div class='shrinkable-quote'><div class='shrinkable-quote'><br>> On 15/12/09 01:48 PM, Conny Marco Menebröcker wrote:
<br>> > On Thursday 10 December 2009 18:22:19 Jeff Johnston wrote:
<br>> >> On 04/12/09 12:34 PM, Conny Marco Menebröcker wrote:
<br>> >>> On Sunday 15 November 2009 10:38:52 Conny Marco Menebröcker wrote:
<br>> >>>> Hi,
<br>> >>>>
<br>> >>>> sorry my first patch file was defect.
<br>> >>>> I've got problems sending my patch as atachment. The last mails got
<br>> >>>> all lost, without any debounce mail. So please donload the file:
<br>> >>>>
<br>> >>>> <a href="http://www.menebroecker-web.de/wp-content/uploads/2009/11/newlib_xc16x" target="_top" rel="nofollow">http://www.menebroecker-web.de/wp-content/uploads/2009/11/newlib_xc16x</a><br>> >>>>.t ar. gz
<br>> >>>>
<br>> >>>> Thanks and best regards,
<br>> >>>> Conny
<br>> >>>
<br>> >>> Hi,
<br>> >>>
<br>> >>> please review my patch.
<br>> >>>
<br>> >>> Best regards,
<br>> >>>
<br>> >>> Conny
<br>> >>
<br>> >> Patch has been committed with the following changes:
<br>> >>
<br>> >> putchar.c has been moved to libc/machine/xc16x and its prototype has
<br>> >> been changed to accept an int rather than a char, per ANSI.
<br>> >>
<br>> >> puts.c has also been moved libc/machine/xc16x.
<br>> >>
<br>> >> You should understand that the shared putchar macro in stdio.h will get
<br>> >> invoked by any user including stdio.h unless they surround the function
<br>> >> call with parentheses or #undef the macro. It calls putc() which
<br>> >> eventually will end up using your write syscall in libgloss. I'm not
<br>> >> sure why you chose to override this particular function by itself other
<br>> >> than a possible performance improvement or experiment, but be aware of
<br>> >> the previous information. If it was only meant as an experiment, feel
<br>> >> free to request it being removed.
<br>> >>
<br>> >> I regenerated the autotool files locally.
<br>> >>
<br>> >> Regards,
<br>> >>
<br>> >> -- Jeff J.
<br>> >
<br>> > Hi Jeff,
<br>> >
<br>> > thank you for commiting my patch. But there is a typing error in
<br>> > makefile.am. Please see attached my patch. This time I used
<br>> > automake-1.11, so I think you can use my patch without regenerating the
<br>> > autotool files.
<br>> >
<br>> > As I wrote in my first email, I just reworked the patch from Shrirang
<br>> > Khishti. So I am not sure why he overrides the putchar function. But I
<br>> > will work on it in the next days.
<br>> >
<br>> > Best regards
<br>> >
<br>> > Conny
<br>>
<br>> Typo fixed and file regenerated. I usually regenerate the files myself
<br>> to avoid inconsistencies between autoconf/automake releases.
<br>>
<br>> -- Jeff J.
<br>>
</div>Hi Jeff,
</div>
<br>Sorry, but I did some mistakes in the configure and makefiles for libgloss.
<br>Please see attached another patch.
<br><br>Best regards
<br><br>Conny
<br><br><br /> <div class="small"><br/><img src="http://old.nabble.com/images/icon_attachment.gif" > <strong>xc16x_libgloss.tar.gz</strong> (30K) <a href="http://old.nabble.com/attachment/26817240/0/xc16x_libgloss.tar.gz" target="_top">Download Attachment</a></div><p>From forum: <a href="http://old.nabble.com/Sourceware---newlib-list-f12241.html" embed="fixTarget[12241]" target="_top" >Sourceware - newlib list</a></p>
tag:old.nabble.com,2006:post-26817216
Re: Mixing function pointers and regular functions with the _EXFUN macro
2009-12-16T11:41:12Z
2009-12-16T11:41:12Z
Jeff Johnston
Jerker,
<br><br>Leave the original _EXPARM macro alone and create a new macro: _EXFNPTR
<br>which you can define as you have changed _EXPARM. Use the new macro in
<br>your patch and please post the finished patch "here" and not in the bug.
<br> I am going to close bugzillas from now on immediately.
<br><br>If you can do this by tomorrow afternoon, I'll get the patch in for the
<br>snapshot.
<br><br>-- Jeff J.
<br><br>On 14/12/09 06:53 PM, Howland Craig D (Craig) wrote:
<div class='shrinkable-quote'><br>> A thought related not to the goal of this patch, but to a detail of how
<br>> it is done.
<br>>
<br>> The stated intent of the _EXFUN macro is to be used for defining function
<br>> parameters. (2000-09-06 ChangeLog entry says "New macro for defining a
<br>> function parameter.") The proposal assumes a more general intent, and
<br>> the patch accordingly uses it for purposes other than this. For example
<br>> (the diff coming in the middle of the struct __sFILE definition in
<br>> libc/sys/reent.h):
<br>>
<br>> - _READ_WRITE_RETURN_TYPE _EXFUN((*_read),(struct _reent *, _PTR,
<br>> + _READ_WRITE_RETURN_TYPE _EXPARM((_read),(struct _reent *, _PTR,
<br>>
<br>> I have thought of two objections to using _EXPARM outside of function
<br>> parameter lists--both of which relate to maintenance, not to proper function.
<br>>
<br>> First, the name _EXPARM does not make sense in this context--in a
<br>> structure, for example, what sense does it make to have an "external
<br>> parameter" member? (A result of extending the use beyond its original
<br>> intent, which speaks only to lack of perfect foresight in the original
<br>> wording, and not to the goal of this patch.)
<br>>
<br>> Secondly, using it in this context removes the * from in front of the
<br>> function pointer name, which makes it much less obvious that a function
<br>> pointer is the item in question--a bit of a step backwards. That is,
<br>> with the * there (e.g. *_read of the present form), it only takes a glance
<br>> to see it is a pointer. Without the *, it takes a partially-informed
<br>> guess--or a-priori knowledge--that a function pointer is the subject.
<br>>
<br>> Both of these objections could be eliminated by changing the name of
<br>> the macro. Given that a major reason for using the macro at all is that
<br>> the _cdecl stuff needs to be brought in, a name keeping EX at the front
<br>> is probably best. So instead of _EXPARM(), something like
<br>> _EXFUNCPTR(), _EXFUNCP(), _EXFP(),
<br>> _EXFPTR(), _EXFNPTR(), _EXFTNPTR(), etc.
<br>> (I don't think that any of these are ideal, but they are much more clear
<br>> than _EXPARM.)
<br>>
<br>> For the sake of a starting point for discussion, I suggest that _EXPARM
<br>> should be changed to _EXFUNCPTR. (This could be considered independently
<br>> of this patch, of course, but it probably makes sense to tie them
<br>> together.) The intended use of the macro would be for function pointers
<br>> used in parameter lists and in structure declarations--the two cases
<br>> for which it is being used in the proposed patch.
<br>>
<br>> Craig
<br>>
<br>> -----Original Message-----
<br>> From: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26817216&i=0" target="_top" rel="nofollow">newlib-owner@...</a> [mailto:<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26817216&i=1" target="_top" rel="nofollow">newlib-owner@...</a>] On Behalf Of Jerker Bäck
<br>> Sent: Friday, December 11, 2009 8:08 AM
<br>> To: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26817216&i=2" target="_top" rel="nofollow">newlib@...</a>
<br>> Cc: 'Dave Korn'; <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26817216&i=3" target="_top" rel="nofollow">jjohnstn@...</a>
<br>> Subject: Mixing function pointers and regular functions with the _EXFUN macro
<br>>
<br>> ...
<br>>
<br>> I'm assuming that the _EXPARM macro (_ansi.h) is intended to be used for
<br>> function pointers. In current newlib both function pointers and regular
<br>> functions are declared with the _EXFUN macro. That is OK (although not very
<br>> articulate), unless the __CYGWIN__ macro is defined and activates the
<br>> __cdecl function modifier keyword.
<br>>
<br>> The proposed patch change function pointer declaration to use the _EXPARM
<br>> macro instead of the _EXFUN macro. It also change the order (syntax) of the
<br>> __cdecl keyword in the _EXPARM macro.
<br>>
<br>> ...
<br>> Cheers
<br>> Jerker B
<br>>
<br>>
</div><br><p>From forum: <a href="http://old.nabble.com/Sourceware---newlib-list-f12241.html" embed="fixTarget[12241]" target="_top" >Sourceware - newlib list</a></p>
tag:old.nabble.com,2006:post-26817104
Re: errno's needed by rtems marked as linux extensions
2009-12-16T11:34:16Z
2009-12-16T11:34:16Z
Jeff Johnston
A patch has been made to move the 3 errnos into the general list.
<br><br><br>2009-12-16 Jeff Johnston <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26817104&i=0" target="_top" rel="nofollow">jjohnstn@...</a>>
<br><br> * libc/include/sys/errno.h: Move EHOSTDOWN, EPFNOSUPPORT,
<br> and ETOOMANYREFS into general list as they are referenced
<br> by OpenGroup and needed by RTEMS.
<br><br>-- Jeff J.
<br><br>On 16/12/09 01:12 PM, Joel Sherrill wrote:
<div class='shrinkable-quote'><br>> Hi,
<br>>
<br>> RTEMS TCP/IP code will not compile against the newlib
<br>> head.
<br>>
<br>> I posted earlier this year about errno's that had
<br>> been marked as Linux specified which are really not.
<br>> I found 6 errnos originally but the two others
<br>> on the original list were part of a longer string so
<br>> showed up via grep but were not really used.
<br>>
<br>> ========= EBADRQC (RTEMS code we can change)
<br>> cpukit/libnetworking/lib/ftpfs.c
<br>> ========= EPFNOSUPPORT (used in Sun RPC/XDR)
<br>> cpukit/librpc/src/rpc/bindresvport.c
<br>> cpukit/librpc/src/rpc/clnt_generic.c
<br>> ========= EHOSTDOWN (used in BSD TCP/IP stack)
<br>> cpukit/libnetworking/netinet/ip_input.c
<br>> cpukit/libnetworking/netinet/tcp_subr.c
<br>> cpukit/libnetworking/nfs/bootp_subr.c
<br>> cpukit/libnetworking/net/if_ethersubr.c
<br>> ========= ETOOMANYREFS (BSD TCP/IP stack)
<br>> cpukit/libnetworking/netinet/ip_output.c
<br>>
<br>>
<br>> So EBADRQC can be changed on our site. That code
<br>> is specific to RTEMS and we can changed that to EINVAL.
<br>>
<br>> So that leaves EPFNOSUPPORT, EHOSTDOWN, and ETOOMANYREFS.
<br>>
<br>> EHOSTDOWN is defined in OpenGroup. The other two I don't know.
<br>>
<br>> In general, the "Linux specific patch" marked some BSD
<br>> and OpenGroup errnos as Linux specific. That covers
<br>> the 3 we care about.
<br>>
<br>> IMO EHOSTDOWN should just be enabled. It is incorrect
<br>> to mark is as Linux specific.
<br>>
<br>> The other two are from BSD. What to do about them is
<br>> up to you. They are NOT proprietary to RTEMS.
<br>>
<br>> When I looked originally, I found these OpenGroup references
<br>>
<br>>> Are there any relevant standards?
<br>>>
<br>>> + EHOSTDOWN is from
<br>>> <a href="http://www.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_10.html" target="_top" rel="nofollow">http://www.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_10.html</a><br>>>
<br>>> so it is probably really not Linux specific anyway.
<br>>>
<br>>> + Every errno in this list appears in the Open Group test suite.
<br>>>
<br>>> <a href="http://tetworks.opengroup.org/tet//sample_binaries/3.3/tet3.3-bin-linux2-dist.cpio.Z" target="_top" rel="nofollow">http://tetworks.opengroup.org/tet//sample_binaries/3.3/tet3.3-bin-linux2-dist.cpio.Z</a><br>>>
<br>>> I was unable to uncompress this so don't know what that means.
<br>>> I didn't see any obvious references to them at opengroup.org in
<br>>> a standards page in my search.
<br>>>
<br>>> It would be interesting to see if other errnos marked
<br>>> Linux extensions are also used by *BSD but the set above
<br>>> are the problems for RTEMS. We cannot build RTEMS with
<br>>> newlib cvs without those defined.
<br>>
</div><br><p>From forum: <a href="http://old.nabble.com/Sourceware---newlib-list-f12241.html" embed="fixTarget[12241]" target="_top" >Sourceware - newlib list</a></p>
tag:old.nabble.com,2006:post-26816296
Re: RTEMS patch sweep 3
2009-12-16T10:45:08Z
2009-12-16T10:45:08Z
Jeff Johnston
On 16/12/09 12:53 PM, Ralf Corsepius wrote:
<div class='shrinkable-quote'><br>> On 12/16/2009 06:50 PM, Ralf Corsepius wrote:
<br>>> Hi,
<br>>>
<br>>> ... and another one.
<br>>>
<br>>> This patch aims at making some parts of newlib more posix compliant.
<br>>>
<br>>> One part is #ifdef'ed __rtems__, because it relies on (POSIX) types
<br>>> which (AFAICT) newlib currently are only supplies for RTEMS (blksize_t,
<br>>> blkcnt_t) and because we haven't tested it in other configurations but
<br>>> in RTEMS configurations.
<br>>>
<br>>> Ralf
<br>>
<br>> Oops, fingers faster than brains - The attachment containing the patch
<br>> was missing ;)
<br>>
<br>> Ralf
</div><br>Shouldn't the added #endif be after the long st_spare4[]? Otherwise,
<br>you are changing the struct for the #if before it which normally
<br>wouldn't have included this field.
<br><br>-- Jeff J.
<br><p>From forum: <a href="http://old.nabble.com/Sourceware---newlib-list-f12241.html" embed="fixTarget[12241]" target="_top" >Sourceware - newlib list</a></p>