X-Recipient: archive-cygwin AT delorie DOT com X-SWARE-Spam-Status: No, hits=-0.6 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: sourceware.org MIME-Version: 1.0 In-Reply-To: <4C654584.9090305@redhat.com> References: <20100812225838 DOT GB15724 AT ednor DOT casa DOT cgf DOT cx> <4C647D32 DOT 1090907 AT redhat DOT com> <4C654584 DOT 9090305 AT redhat DOT com> Date: Fri, 13 Aug 2010 12:39:46 -0300 Message-ID: Subject: Re: diff /usr/include/endian.orig.h /usr/include/endian.h > endian.h.diff From: Pedro Izecksohn To: cygwin AT cygwin DOT com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com --- Eric Blake wrote: > > Umm - did you copy straight from glibc's endian.h? =C2=A0That'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. =C2=A0How 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_BS= D. 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 =3D=3D __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 cod= er. 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