so what is the best practice, can workaround it likes following:

#ifndef  __BIT_TYPES_DEFINED__
  typedef unsigned char uint8_t;
  typedef unsigned short uint16_t;
  typedef unsigned long uint32_t;
#else
  /* use std fixed-width defines */
#endif

On Fri, Feb 18, 2011 at 2:13 PM, real mz <[email protected]> wrote:
> 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

Reply via email to