X-Recipient: archive-cygwin@delorie.com X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00,SARE_MSGID_LONG40,SPF_PASS X-Spam-Check-By: sourceware.org MIME-Version: 1.0 In-Reply-To: <4A82D5CD.1020604@comcast.net> References: <4A82CBB1.30507@comcast.net> <20090812141530.GA14016@calimero.vinschen.de> <4A82CF78.4050504@comcast.net> <4A82D5CD.1020604@comcast.net> Date: Wed, 12 Aug 2009 10:51:05 -0400 Message-ID: Subject: Re: Supporting Data Types "ushort_t" and "uchar_t" From: "Mark J. Reed" To: cygwin@cygwin.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Delivered-To: mailing list cygwin@cygwin.com On Wed, Aug 12, 2009 at 10:46 AM, Larry Adams wrote: > My concern is that the "*_t" typedefs are supposed to be hardware architecture > agnostic, and there must have been some reason, other than "geeze everything > else is that way, so why not do those two" to have done this for Solaris. An understandable concern, though I'm having trouble imagining any scenario where a sensible definition of "ushort_t" and "uchar_t" would be anything other than "unsigned short" and "unsigned char". -- Mark J. Reed -- 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