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

[Tobias Pape]

On 26.01.2017, at 21:20, Igor Stasenko <siguctua at gmail.com> wrote:

> +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*)

You mean uintptr_t?

https://en.wikipedia.org/wiki/C_data_types#Fixed-width_integer_types

C11 says:

7.20.1.4 Integer types capable of holding object pointers

1 The following type designates a signed integer type with the property that any valid pointer to void can be converted to this type, then converted back to pointer to void, and the result will compare equal to the original pointer:

intptr_t

The following type designates an unsigned integer type with the property that any valid pointer to void can be converted to this type, then converted back to pointer to void, and the result will compare equal to the original pointer:

uintptr_t

These types are optional.


> that would solve so many problems and make thing so much easier..
> 
> 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.. 
> 
> 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.
> 
> 
> 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.