This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Supporting Data Types "ushort_t" and "uchar_t"


Dave Korn <dave.korn.cygwin <at> googlemail.com> writes:

> Declaring a typedef
> that is exactly the same as a builtin type (as opposed to one that has 
different
> semantics, even though it is defined in terms of the internal types) is fairly
> silly.  "unsigned char" is every bit as hardware agnostic as "uchar_t", it's
> pointless.

Not _entirely_ pointless.  There are some things that you can do with one-word 
typedefs that you can't do with multi-token primitive types, such as this gem 
from gnulib's test-alignof.c:

typedef long double longdouble;

#define CHECK(type) \
  typedef struct { char slot1; type slot2; } type##_helper; \
  verify (alignof_slot (type) == offsetof (type##_helper, slot2)); \
  const int type##_slot_alignment = alignof_slot (type); \
  const int type##_type_alignment = alignof_type (type);

>   I would suggest you guys just avoid the use of these misbegotten aliases in
> your code...

This statement is still true - portable code should not rely on an unspecified 
typedef.

-- 
Eric Blake



--
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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]