From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9447 invoked by alias); 22 Sep 2007 12:22:06 -0000 Received: (qmail 9432 invoked by uid 22791); 22 Sep 2007 12:22:05 -0000 X-Spam-Check-By: sourceware.org Received: from stelecom.gomel.by (HELO stelecom.gomel.by) (82.209.213.61) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 22 Sep 2007 12:22:00 +0000 Received: by stelecom.gomel.by (Postfix, from userid 501) id D68CEB018ACF; Sat, 22 Sep 2007 15:21:57 +0300 (EEST) Received: from localhost (unknown [82.209.208.115]) by stelecom.gomel.by (Postfix) with ESMTP id 0ED3AB0190E0; Sat, 22 Sep 2007 15:21:46 +0300 (EEST) Date: Sat, 22 Sep 2007 12:22:00 -0000 From: Sergei Gavrikov To: Grant Edwards Cc: ecos-discuss@sources.redhat.com Message-ID: <20070922122026.GA5875@ubuntu> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.13 (2006-08-11) X-IsSubscribed: yes Mailing-List: contact ecos-discuss-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@ecos.sourceware.org Subject: Re: [ECOS] CGY_SWAP16() seems broken to me. X-SW-Source: 2007-09/txt/msg00122.txt.bz2 On Sat, Sep 22, 2007 at 02:56:33AM +0000, Grant Edwards wrote: > unsigned u = CYG_SWAP16(0x1234); > > What would a reasonable person (who hasn't looked at > hal_endian.h) expect u to be? > > I certainly expected it to be 0x3412. > > But it's not. It's 0x123412. That is exists. I got same result #include #include #include #include int main (void) { printf ("HAL swap16(0x1234) = 0x%x\n", CYG_SWAP16 (0x1234)); printf ("NET swap16(0x1234) = 0x%x\n", swap16 (0x1234)); return 0; } HAL swap16(0x1234) = 0x123412 NET swap16(0x1234) = 0x3412 > IMO, that's just plain broken. ... I don't know. What do eCos experts think about? > Here's the definition from hal_endian.h: > > # define CYG_SWAP16(_x_) \ > ({ cyg_uint16 _x = (_x_); ((_x << 8) | (_x >> 8)); }) > > Why isn't it this? > > # define CYG_SWAP16(_x_) \ > ({ cyg_uint16 _x = (_x_); (cyg_uint16)((_x << 8) | (_x >> 8)); }) > > Why would anybody expect a macro named CYG_SWAP16() to return a > "24-bit value" when passed a "16-bit value"? Usually, they use yet masking in same macros. Good byteorder examples are net/bsd_tcpip/current/include/sys/endian.h net/tcpip/current/include/sys/endian.h It seems, that eCos HAL's CYG_SWAP16() either assumes what it will be to live in "16-bit world" or it assumes that will be a developers's care. I did find only 3 places where CYG_SWAP16() macro is used. For example, CYG_SWAP16() macro uses itself in the eCos drivers for 16-bit Ethernet controllers (cs8900a, ec555) "16-bit world". And I found that RedBoot's conf_endian_fixup() (fconfig.c) uses eCos HAL's CYG_SWAP16() "as is", because that was a "developer's care", there is there u16 = CYG_SWAP16(u16); but, not :-) unsigned u = CYG_SWAP16(0x1234); In any case, thank you for your report, we will be to know about. Sergei -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss