+1, against type casting for this
On Wed, May 19, 2010 at 12:31 PM, Bryan Call <bc...@yahoo-inc.com> wrote:
> On 05/19/2010 09:14 AM, John Plevyak wrote:
>
>> Yes we will change INXXX_MAX etc.
>>
>> Unfortunately int64 is not standard. So we have a couple alternatives.
>>
>> 1) use nonstandard types where
>>
>> typedef long long int int64;
>> typedef int int32;
>> typedef short int16;
>> typedef char int8;
>>
>> etc.
>>
>> which work on every system and which permit seamless printf
>> using %lld and %d. This is the way we do it now.
>>
>>
>>
>
> +1 - This is the lesser of the evils...
>
> Only because there is no other way to get *printf() from complaining
> without using macros or type casting.
>
>
> 2. use "standard" types and cast all printf/scanf calls:
>>
>> printf("x = %lld", *(long long int*)&my_standard_uint64_t_var)
>>
>> 3. use the "standard" types and the "standard" macros:
>>
>> printf("x = " PRIi64, my_standard_uint64_t_var)
>>
>> however, it should be noted that this doesn't work for strings which are
>> not constants, are read from a configuration file or input by the
>> user, computed etc.
>>
>> I think that 1 is the least of the evils. 2 is dangerous and ugly
>> and 3 is ugly and a pain, and potentially complex as it might mean
>> rewriting printf/scanf strings on the fly and this standard is
>> relatively recent which means that lots of older systems don't support
>> it which means including the headers ourselves. MS Studio didn't
>> support it until the 2010 version for example.
>>
>>
>> On 5/19/2010 8:16 AM, Leif Hedstrom wrote:
>>
>>
>>> On 05/19/2010 08:23 AM, John Plevyak wrote:
>>>
>>>
>>>> I propose that we change
>>>>
>>>> ink64 -> int64
>>>> inku64 -> uint64
>>>> ink32 -> int32
>>>> inku32 -> uint32
>>>> ink16 -> int16
>>>> inku16 -> uint16
>>>> ink8 -> int8
>>>> inku8 -> uint8
>>>>
>>>> because
>>>>
>>>> 1) we decided to move from ink -> ts
>>>> 2) tsu64 doesn't scan like an integer
>>>> 3) int64_t is long on linux which is incompatible with %lld the
>>>> only standard and universally compatible way to read/write a
>>>> 64-bit number
>>>> 4) int64 is similar but not the same as ink64_t and it scans well
>>>> 5) I tried it and it works!
>>>>
>>>>
>>>>
>>> Would this be a name change only (in our ink_port.h file)? Or do we pull
>>> in int64 etc from some standard (ANSI / POSIX include file)? My stdint.h
>>> only has the int64_t etc. definitions.
>>>
>>> Also, if we do this, shouldn't we also change
>>>
>>> #define INKU64_MAX (18446744073709551615ULL)
>>> #define INK64_MAX (9223372036854775807LL)
>>> #define INK64_MIN (-INK64_MAX -1LL)
>>> #define INKU32_MAX (4294967295U)
>>> #define INK32_MAX (2147483647)
>>> #define INK32_MIN (-2147483647-1)
>>>
>>>
>>> I believe there are similar defines available in stdint.h. (Fwiw, my
>>> 64-bit changes in the HttpSM uses INK64_MAX in various places).
>>>
>>> That much said, +1 on eliminating our own INK defines, and use standard
>>> definitions.
>>>
>>> -- leif
>>>
>>>
>>
>>
>
>
>
