[Vm-dev] Sometimes it's too easy, part II

[Nicolas Cellier]

2017-01-26 21:20 GMT+01:00 Igor Stasenko <siguctua at gmail.com>:

>
> +1
>
> with C i was always wondering, why C standard does not provides
> an unsigned integer type which size strictly corresponds to size of
> pointer type, e.g.
> sizeof(some standard uint) == sizeof(void*)
> that would solve so many problems and make thing so much easier..
>
>
In C99, there is intptr_t (and all the accompanying MACROS for printf/scanf
formats, maximum value etc...)



> instead they had this:
> http://www.gnu.org/software/libc/manual/html_node/
> Important-Data-Types.html
> Data Type: *ptrdiff_t*
>
> This is the signed integer type of the result of subtracting two pointers.
> For example, with the declaration char *p1, *p2;, the expression p2 - p1 is
> of type ptrdiff_t. This will probably be one of the standard signed
> integer types (short int, int or long int), but might be a nonstandard
> type that exists only for this purpose.
>
> it is easy to see, that sizeof(ptrdiff_t) should be _at least_ the
> sizeof(void*), else it won't be able to cover all possible values when
> taking difference between two pointers..
> alas, it is signed.. and alas, nothing says that it cannot be _more_ than
> size of pointer in memory.. simply because you can always fit values that
> take 32 bits into 64-bit value holder..
>

Technically you should only compare pointers that points to parts of a same
structure or array (or byte just after the end of an array), otherwise it's
UB.
I guess this should apply to ptrdiff_t, in which case ptrdiff_t should be
as long as a size_t, except it is signed.


>
> One could say, that there's size_t that could be used as a unsigned
> alternative to ptrdiff_t,
> unfortunately, ISO gives no guarantees that its size corresponds to
> pointer size.
>
>
size_t does not necessarily fit intptr_t indeed, use the right type.


>
> Btw,look what i found :)
> https://gcc.gnu.org/onlinedocs/gcc/Integer-Overflow-Builtins.html#
> Integer-Overflow-Builtins
>
> that could be useful for implementing small-int arithmetics in plain C..
> unfortunately this is extension, and don't shoot for  proposing to use
> non-standard C herecy :)
>
>
> On 26 January 2017 at 21:37, John McIntosh <johnmci at smalltalkconsulting.
> com> wrote:
>
>>
>> +1
>>
>> Sent from my iPhone
>>
>> > On Jan 26, 2017, at 10:58, David T. Lewis <lewis at mail.msen.com> wrote:
>> >
>> >
>> > +1
>> >
>> > Dave
>> >
>> >>
>> >> Surely since we’re concerned about (ab)use of signed values for
>> pointers
>> >> to words we ought to define a ‘proper’ sqOop thing and use that
>> >> instead of a slightly cleaned up derivative of how the Slang default
>> was
>> >> left as ‘int’ twenty years ago?
>> >>
>> >> Yes, any change means a bunch of work to do but isn’t that always the
>> >> price to improve things?
>> >>
>> >> tim
>> >> --
>> >> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
>> >> Strange OpCodes: LB: connect Line-voltage to BITNET
>> >>
>> >>
>> >>
>> >
>> >
>>
>>
>
>
> --
> Best regards,
> Igor Stasenko.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20170126/061dafb8/attachment.html>