these fixed-width typedefs uintxx_t are mandated by the C99 standard, some compiler such as vc++ is not planning to support it, vc++ defines non-standard fixed-width integers like __int16.
On Fri, Feb 18, 2011 at 12:55 PM, Mike Frysinger <[email protected]> wrote: > On Thu, Feb 17, 2011 at 22:21, Zhang, Sonic wrote: >>-----Original Message----- >>>On Thu, Feb 17, 2011 at 05:16, >>><[email protected]> wrote: >>>> Added: trunk/arch/blackfin/mach-bf561/include/mach/icc.h (0 => 9620) >>>> >>>> +typedef unsigned char sm_unit_t; >>>> +typedef unsigned short sm_uint16_t; >>>> +typedef unsigned long sm_uint32_t; >>>> +typedef sm_uint32_t sm_address_t; >>> >>>what exactly is wrong with existing standard C types >>>(uintXX_t) ? why must you declare your own arbitrarily named types ? >> >> The ICC protocol is designed to be architecture, OS and Language indepenant. >> These protocol specific types are only used when access the data in message >> pipes. > > can you really name any OS that doesnt provide these types are > required by ISO C and will actually be used ? the language > independence is irrelevant as this is a C implementation. > > ignoring that, this logic has no relevance for the Linux environment. > Linux does have a sane environment and does provide these types. thus > there is no reason to force every arch to manually do: > typedef unsigned char sm_unit_t; > typedef unsigned char uint8_t; > typedef unsigned short sm_uint16_t; > typedef unsigned short uint16_t; > typedef unsigned long sm_uint32_t; > typedef unsigned long uint32_t; > > it would make more sense to say "we use the ISO C types xxx. if your > environment doesnt provide them because it doesnt follow the ISO C > spec, then simply define them yourself.". > -mike > _______________________________________________ Linux-kernel-commits mailing list [email protected] https://blackfin.uclinux.org/mailman/listinfo/linux-kernel-commits
