X-Recipient: archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status: No, hits=-3.5 required=5.0 	tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_HELO_PASS,SPF_PASS,UNPARSEABLE_RELAY
X-Spam-Check-By: sourceware.org
To: cygwin AT cygwin DOT com
From: Eric Blake <ebb9 AT byu DOT net>
Subject:  Re: "Incompatible" typedefs
Date: Wed, 4 Feb 2009 18:46:00 +0000 (UTC)
Lines: 75
Message-ID:  <loom.20090204T183338-593@post.gmane.org>
References:  <1233680809 DOT 17414 DOT 1298297091 AT webmail DOT messagingengine DOT com> <20090203171556 DOT GB12192 AT ednor DOT casa DOT cgf DOT cx> <4989511F DOT 4040200 AT cwilson DOT fastmail DOT fm> <4989AA1C DOT 70300 AT gmail DOT com> <4989CBF8 DOT 1000209 AT cwilson DOT fastmail DOT fm>
Mime-Version:  1.0
Content-Type:  text/plain; charset=utf-8
Content-Transfer-Encoding:  8bit
User-Agent: Loom/3.14 (http://gmane.org/)
X-IsSubscribed: yes
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

Charles Wilson <cygwin <at> cwilson.fastmail.fm> writes:

> But, at the risk of extending this thread -- I do have a question. Is
> there really a difference between
> 
> short    vs.    short int
> long     vs.    long int
> unsigned vs.    unsigned int
> signed   vs.    signed int

No difference in any of those examples; however, I personally like the 
forms 'short int', 'long int', 'unsigned int', and 'int'.

> (etc, other combinations of modifiers with and without 'int')

The difference you are running into is the fact that 'int' and 'long int' (or 
alternately spelled, 'int' and 'long') are distinct types, even if they both 
occupy 32 bits and are both signed.  Likewise, 'unsigned long int' 
and 'unsigned int' (or alternately spelled, 'unsigned long' and 'unsigned') are 
distinct types, even if both occupy 32 bits and are both unsigned.  It is this 
difference that is tripping up 1.5 users, because the headers are using 
distinct types where they shouldn't be.  Also, 'signed int' and 'int' are 
identical, but 'char', 'unsigned char', and 'signed char' are three distinct 
types.

> Your argument seems to imply that there is. I always thought that the
> 'int' was implied when only the size (or signedness) was specified, and
> that the types were exactly identical. No? Reference, please?

How about C99 6.2.5 Types:

| There are five standard signed integer types, designated as signed char,
| short int, int, long int, and long long int. (These and other types may be
| designated in several additional ways, as described in 6.7.2.)

| For each of the signed integer types, there is a corresponding (but
| different) unsigned integer type (designated with the keyword unsigned)
| that uses the same amount of storage (including sign information) and has
| the same alignment requirements. The type _Bool and the unsigned integer
| types that correspond to the standard signed integer types are the standard
| unsigned integer types.

and 6.7.2 Type specifiers:

| Each list of type specifiers shall be one of the following sets (delimited
| by commas, when there is more than one set on a line); the type specifiers
| may occur in any order

| — char
| — signed char
| — unsigned char
| — short, signed short, short int, or signed short int
| — unsigned short, or unsigned short int
| — int, signed, or signed int
| — unsigned, or unsigned int
| — long, signed long, long int, or signed long int
| — unsigned long, or unsigned long int
| — long long, signed long long, long long int, or signed long long int
| — unsigned long long, or unsigned long long int

And with this knowledge, you then get to play with what gcc means by

>> typedef unsigned int u_int16_t __attribute__ ((__mode__ (__HI__)));
>> typedef unsigned short int uint16_t;

They are based on two different base types (unsigned int vs. unsigned short 
int), but the presence of __attribute__ means that you are outside the realm of 
C99, so it is up to the compiler whether u_int16_t is effectively the same 
class as 'unsigned short int' or whether it behaves more like an 'unsigned int' 
truncated to 16 bits.  And that's where I don't know the right answer.

-- 
Eric Blake




--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/