Re: diff /usr/include/endian.orig.h /usr/include/endian.h > endian.h.diff
On Aug 19 19:31, Pedro Izecksohn wrote: > ChangeLog entry: > > 2010-08-19 Pedro Izecksohn > > * endian.h [_BSD_SOURCE || ! _POSIX_SOURCE] (htobe16, htobe32) > (htobe64, be16toh, be32toh, be64toh, htole16, htole32, htole64) > (le16toh, le32toh, le64toh): Macros defined. > > I modified endian.h again: Thanks. On second thought I redefined _BSD_SOURCE to __USE_BSD and disabled it, same as a few lines above. Patch applied. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: diff /usr/include/endian.orig.h /usr/include/endian.h > endian.h.diff
ChangeLog entry: 2010-08-19 Pedro Izecksohn * endian.h [_BSD_SOURCE || ! _POSIX_SOURCE] (htobe16, htobe32) (htobe64, be16toh, be32toh, be64toh, htole16, htole32, htole64) (le16toh, le32toh, le64toh): Macros defined. I modified endian.h again: *** /usr/include/endian.orig.h Mon Apr 12 14:09:58 2010 --- /usr/include/endian.h Thu Aug 19 19:03:20 2010 *** *** 36,40 #elif __BYTE_ORDER == __BIG_ENDIAN # define __LONG_LONG_PAIR(HI, LO) HI, LO #endif - #endif /*_ENDIAN_H_*/ --- 36,86 #elif __BYTE_ORDER == __BIG_ENDIAN # define __LONG_LONG_PAIR(HI, LO) HI, LO #endif + #if defined _BSD_SOURCE || ! defined _POSIX_SOURCE + + #include + + #if __BYTE_ORDER == __LITTLE_ENDIAN + + #define htobe16(x) bswap_16(x) + #define htobe32(x) bswap_32(x) + #define htobe64(x) bswap_64(x) + + #define be16toh(x) bswap_16(x) + #define be32toh(x) bswap_32(x) + #define be64toh(x) bswap_64(x) + + #define htole16(x) (x) + #define htole32(x) (x) + #define htole64(x) (x) + + #define le16toh(x) (x) + #define le32toh(x) (x) + #define le64toh(x) (x) + + #endif /*__BYTE_ORDER == __LITTLE_ENDIAN*/ + + #if __BYTE_ORDER == __BIG_ENDIAN + + #define htobe16(x) (x) + #define htobe32(x) (x) + #define htobe64(x) (x) + + #define be16toh(x) (x) + #define be32toh(x) (x) + #define be64toh(x) (x) + + #define htole16(x) bswap_16(x) + #define htole32(x) bswap_32(x) + #define htole64(x) bswap_64(x) + + #define le16toh(x) bswap_16(x) + #define le32toh(x) bswap_32(x) + #define le64toh(x) bswap_64(x) + + #endif /*__BYTE_ORDER == __BIG_ENDIAN*/ + + #endif /*_BSD_SOURCE*/ + + #endif /*_ENDIAN_H_*/ -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: diff /usr/include/endian.orig.h /usr/include/endian.h > endian.h.diff
On Aug 17 22:44, Pedro Izecksohn wrote: > --- Corinna Vinschen wrote: > > > > For this patch, given that it is just a bunch of rather obvious > > defines, I don't think we have to treat the patch as significant. > > I do not think that these macros are obvious. I think that I was > there when these macros were first implemented at 1987: I talked with > the programmer who was paid by the Correios to port everything from > the mainframe to the Apple II. I was a stenchy kid with his father, > that asked the employee what he was doing. When I asked about other > possibilities of endianness, the programmer answered about the PDP. > The programmer explained about BSD being a flavor of Unix. That talk > changed my life. > > > However, please don't use _BSD_SOURCE. The newlib/Cygwin headers are > > not set up like the Linux headers and the big bunch of definitions from > > /usr/include/features.h are not available so far. The _BSD_SOURCE > > define is not honored or set anywhere right now. > > > > What you can do is to use _POSIX_SOURCE. So, if you're going to use > > #ifndef _POSIX_SOURCE instead, and if you're creating a ChangeLog entry > > in the correct ChangeLog entry format (see the ChangeLog file), then > > I guess we can check it in. > > Would you agree with: > > #if defined _BSD_SOURCE || ! defined _POSIX_SOURCE Ok. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: diff /usr/include/endian.orig.h /usr/include/endian.h > endian.h.diff
--- Corinna Vinschen wrote: > > For this patch, given that it is just a bunch of rather obvious > defines, I don't think we have to treat the patch as significant. I do not think that these macros are obvious. I think that I was there when these macros were first implemented at 1987: I talked with the programmer who was paid by the Correios to port everything from the mainframe to the Apple II. I was a stenchy kid with his father, that asked the employee what he was doing. When I asked about other possibilities of endianness, the programmer answered about the PDP. The programmer explained about BSD being a flavor of Unix. That talk changed my life. > However, please don't use _BSD_SOURCE. The newlib/Cygwin headers are > not set up like the Linux headers and the big bunch of definitions from > /usr/include/features.h are not available so far. The _BSD_SOURCE > define is not honored or set anywhere right now. > > What you can do is to use _POSIX_SOURCE. So, if you're going to use > #ifndef _POSIX_SOURCE instead, and if you're creating a ChangeLog entry > in the correct ChangeLog entry format (see the ChangeLog file), then > I guess we can check it in. Would you agree with: #if defined _BSD_SOURCE || ! defined _POSIX_SOURCE ? -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: diff /usr/include/endian.orig.h /usr/include/endian.h > endian.h.diff
Pedro, first of all, did you read http://cygwin.com/contrib.html? Especially the "Before you get started" section. For this patch, given that it is just a bunch of rather obvious defines, I don't think we have to treat the patch as significant. However, please don't use _BSD_SOURCE. The newlib/Cygwin headers are not set up like the Linux headers and the big bunch of definitions from /usr/include/features.h are not available so far. The _BSD_SOURCE define is not honored or set anywhere right now. What you can do is to use _POSIX_SOURCE. So, if you're going to use #ifndef _POSIX_SOURCE instead, and if you're creating a ChangeLog entry in the correct ChangeLog entry format (see the ChangeLog file), then I guess we can check it in. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: diff /usr/include/endian.orig.h /usr/include/endian.h > endian.h.diff
As this thread went nowhere, I searched for the BSD code: http://svn.freebsd.org/viewvc/base/stable/8/sys/sys/endian.h?revision=199583&view=markup It uses x to represent the variable as I did; but it also casts the variable. I think that casting is not desirable because I like to see warnings. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: diff /usr/include/endian.orig.h /usr/include/endian.h > endian.h.diff
--- I wrote: >> The x glyph represents the different ways to represent the same number: >> ... >> I thought to use (i) of integer, but its glyph does not remember the >> proverb about Rome. --- Corinna Vinschen asked: > You mean "What have the Romans ever done for us?" "All roads lead to Rome." Answering the question asked by Eric Blake: Why do you need these macros? Binary endianness conversion is faster than ASCII conversion. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: diff /usr/include/endian.orig.h /usr/include/endian.h > endian.h.diff
On Aug 13 19:11, Pedro Izecksohn wrote: > I thought to use (i) of integer, but its glyph does not remember the > proverb about Rome. You mean "What have the Romans ever done for us?" Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: diff /usr/include/endian.orig.h /usr/include/endian.h > endian.h.diff
> Umm - did you copy straight from glibc's endian.h? That's a no-no; > cygwin generally doesn't want to borrow LGPL sources to avoid any > licensing questions (borrowing from BSD is okay, on the other hand). > You would have to implement things from scratch from a documentation > page, or copy from a less-questionable source, rather than using glibc's > implementation. > > I'm stopping right here, so I don't risk tainting myself. How about you > instead describe which macros you are missing, so someone can do a > clean-room implementation of those macros. After sleep I remembered the error that I posted first, that proves that I did not copy from glibc: + #ifdef _BSD_SOURCE + #if __BYTE_ORDER == __LITTLE_ENDIAN + + #include If I would have copied from glibc this out-of-order code would be as it must be. And regarding the many (x) I can explain them: I could use any acceptable character, but I chose x for 2 reasons: 1) I, and probably most of you, learned equations at school using x and y, to draw the points along the axes; 2) The x glyph represents the different ways to represent the same number: As a child, I once asked an Unix sysadmin that used a real TTY: "-You are telling me that are two different ways to order the 4 bytes of a number. But I can imagine many more ways to represent the same number. For example: 1324 or 1423. ?" I thought to use (i) of integer, but its glyph does not remember the proverb about Rome. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: diff /usr/include/endian.orig.h /usr/include/endian.h > endian.h.diff
--- Eric Blake wrote: > > Umm - did you copy straight from glibc's endian.h? That's a no-no; > cygwin generally doesn't want to borrow LGPL sources to avoid any > licensing questions (borrowing from BSD is okay, on the other hand). > You would have to implement things from scratch from a documentation > page, or copy from a less-questionable source, rather than using glibc's > implementation. > > I'm stopping right here, so I don't risk tainting myself. How about you > instead describe which macros you are missing, so someone can do a > clean-room implementation of those macros. I did not copy my code from glibc's endian.h: I wrote my code yesterday, while on Windows Vista for 32 bits using joe on Cygwin and notepad. Now I'm using Ubuntu for x86-64. I'm also surprised that glibc's code is similar to mine: glibc's folks wrote: #ifdef __USE_BSD /* Conversion interfaces. */ # include I wrote: #ifdef _BSD_SOURCE #include The man 3 page, from Linux and from the web, does not tell about __USE_BSD. The next line is equal, probably because the glibc's guy who wrote it also was using x86-32. If I would be using Ubuntu for x86-64 yesterday I would have written the opposite. #if __BYTE_ORDER == __LITTLE_ENDIAN If you want, to swap the order of my macros is very easy. Then glibc continues, interleaving be with le, and a pair of hto with another pair of toh: # define htobe16(x) __bswap_16 (x) # define htole16(x) (x) # define be16toh(x) __bswap_16 (x) # define le16toh(x) (x) It is very different from what I wrote. I interleaved the types: #define htobe16(x) bswap_16(x) #define htobe32(x) bswap_32(x) #define htobe64(x) bswap_64(x) To use bswap to implement hto and toh macros is the most intelligent approach. Fortunately, glibc's __bswap_16 differs from Cygwin's bswap_16. Also: glibc's style is different from mine: They use a space between the # and the define. After writing this message I'm proud that I'm as smart as the glibc's coder. I need the 64 bits macros only. I wrote the other macros for completeness. In my project, that can not be disclosed now, I use the arpa/inet.h macros for the smaller types. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: diff /usr/include/endian.orig.h /usr/include/endian.h > endian.h.diff
On 08/12/2010 06:35 PM, Pedro Izecksohn wrote: > --- I wrote: >> Defines macros for to convert the endianness of 16, 32 and 64 bits >> integer types. >> >> diff -c /usr/include/endian.orig.h /usr/include/endian.h > > My previous diff is wrong. The right one follows: OK, that documents _what_ your changes are, but not _why_ you are making them. Mentioning that you are adding macros that are present in a Linux installation's endian.h would have been nice (for example, that you made your changes by reading 'man htobe16' on Linux). > + #ifdef _BSD_SOURCE > + > + #include > + > + #if __BYTE_ORDER == __LITTLE_ENDIAN Umm - did you copy straight from glibc's endian.h? That's a no-no; cygwin generally doesn't want to borrow LGPL sources to avoid any licensing questions (borrowing from BSD is okay, on the other hand). You would have to implement things from scratch from a documentation page, or copy from a less-questionable source, rather than using glibc's implementation. I'm stopping right here, so I don't risk tainting myself. How about you instead describe which macros you are missing, so someone can do a clean-room implementation of those macros. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: diff /usr/include/endian.orig.h /usr/include/endian.h > endian.h.diff
--- I wrote: > Defines macros for to convert the endianness of 16, 32 and 64 bits > integer types. > > diff -c /usr/include/endian.orig.h /usr/include/endian.h My previous diff is wrong. The right one follows: *** /usr/include/endian.orig.h Mon Apr 12 14:09:58 2010 --- /usr/include/endian.h Thu Aug 12 21:28:01 2010 *** *** 36,40 #elif __BYTE_ORDER == __BIG_ENDIAN # define __LONG_LONG_PAIR(HI, LO) HI, LO #endif - #endif /*_ENDIAN_H_*/ --- 36,83 #elif __BYTE_ORDER == __BIG_ENDIAN # define __LONG_LONG_PAIR(HI, LO) HI, LO #endif + #ifdef _BSD_SOURCE + + #include + + #if __BYTE_ORDER == __LITTLE_ENDIAN + + #define htobe16(x) bswap_16(x) + #define htobe32(x) bswap_32(x) + #define htobe64(x) bswap_64(x) + + #define be16toh(x) bswap_16(x) + #define be32toh(x) bswap_32(x) + #define be64toh(x) bswap_64(x) + + #define htole16(x) (x) + #define htole32(x) (x) + #define htole64(x) (x) + + #define le16toh(x) (x) + #define le32toh(x) (x) + #define le64toh(x) (x) + + #else /* __BYTE_ORDER == __BIG_ENDIAN */ + + #define htobe16(x) (x) + #define htobe32(x) (x) + #define htobe64(x) (x) + + #define be16toh(x) (x) + #define be32toh(x) (x) + #define be64toh(x) (x) + + #define htole16(x) bswap_16(x) + #define htole32(x) bswap_32(x) + #define htole64(x) bswap_64(x) + + #define le16toh(x) bswap_16(x) + #define le32toh(x) bswap_32(x) + #define le64toh(x) bswap_64(x) + + #endif + #endif /*_BSD_SOURCE*/ + + #endif /*_ENDIAN_H_*/ -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: diff /usr/include/endian.orig.h /usr/include/endian.h > endian.h.diff
--- Eric Blake wrote: > Christopher Faylor wrote: >> I wrote: >>> I hope this list accepts attachments. >> >> It does but the list mind-reading gizmo is on the fritz. > > Translation - a ChangeLog entry justifying your changes, a diff in > unified or context format (-u or -c) rather than the default ed format, > and attaching the patch inline with a text/plain MIME type instead of > base64 encoded, are all necessary before anyone is likely to act on your > proposed patch. Defines macros for to convert the endianness of 16, 32 and 64 bits integer types. diff -c /usr/include/endian.orig.h /usr/include/endian.h *** /usr/include/endian.orig.h Mon Apr 12 14:09:58 2010 --- /usr/include/endian.h Thu Aug 12 19:40:20 2010 *** *** 36,40 #elif __BYTE_ORDER == __BIG_ENDIAN # define __LONG_LONG_PAIR(HI, LO) HI, LO #endif - #endif /*_ENDIAN_H_*/ --- 36,82 #elif __BYTE_ORDER == __BIG_ENDIAN # define __LONG_LONG_PAIR(HI, LO) HI, LO #endif + #ifdef _BSD_SOURCE + #if __BYTE_ORDER == __LITTLE_ENDIAN + + #include + + #define htobe16(x) bswap_16(x) + #define htobe32(x) bswap_32(x) + #define htobe64(x) bswap_64(x) + + #define be16toh(x) bswap_16(x) + #define be32toh(x) bswap_32(x) + #define be64toh(x) bswap_64(x) + + #define htole16(x) (x) + #define htole32(x) (x) + #define htole64(x) (x) + + #define le16toh(x) (x) + #define le32toh(x) (x) + #define le64toh(x) (x) + + #else /* __BYTE_ORDER == __BIG_ENDIAN */ + + #define htobe16(x) (x) + #define htobe32(x) (x) + #define htobe64(x) (x) + + #define be16toh(x) (x) + #define be32toh(x) (x) + #define be64toh(x) (x) + + #define htole16(x) bswap_16(x) + #define htole32(x) bswap_32(x) + #define htole64(x) bswap_64(x) + + #define le16toh(x) bswap_16(x) + #define le32toh(x) bswap_32(x) + #define le64toh(x) bswap_64(x) + + #endif + #endif /*_BSD_SOURCE*/ + + #endif /*_ENDIAN_H_*/ -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: diff /usr/include/endian.orig.h /usr/include/endian.h > endian.h.diff
On 08/12/2010 04:58 PM, Christopher Faylor wrote: > On Thu, Aug 12, 2010 at 07:56:31PM -0300, Pedro Izecksohn wrote: >> I hope this list accepts attachments. > > It does but the list mind-reading gizmo is on the fritz. Translation - a ChangeLog entry justifying your changes, a diff in unified or context format (-u or -c) rather than the default ed format, and attaching the patch inline with a text/plain MIME type instead of base64 encoded, are all necessary before anyone is likely to act on your proposed patch. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: diff /usr/include/endian.orig.h /usr/include/endian.h > endian.h.diff
On Thu, Aug 12, 2010 at 07:56:31PM -0300, Pedro Izecksohn wrote: > I hope this list accepts attachments. It does but the list mind-reading gizmo is on the fritz. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
diff /usr/include/endian.orig.h /usr/include/endian.h > endian.h.diff
I hope this list accepts attachments. endian.h.diff Description: Binary data -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
