Why typedef Sint64 SDL_FingerID?

Hi,
What was the motivation to typedef SDL_FingerID (and SDL_TouchID) as Sint64? I don’t possess that much fingers…
At that it disturbs SDL_Log etc.

wboe

2012/12/7 wboe <w.boeke at upcmail.nl>

**
Hi,
What was the motivation to typedef SDL_FingerID (and SDL_TouchID) as
Sint64? I don’t possess that much fingers…
At that it disturbs SDL_Log etc.

wboe

You don’t know where evolution will takes us, it’s better to be prepared,
after all we don’t want for the public to blame us for a "Y2K of fingers"
when the mutants start showing up.

Seriously though, it’s because those ids can be (IIRC) actual memory
pointers to internal structures.–
Gabriel.

1 Like

But memory pointers should be intptr_t, not int64_t (128-bit address
spaces seem more likely than one may think even without enough RAM to
fill the 64-bit range, if one considers all the ways in which the
address space could be used).

Then again pointers should never be casted to integers for starters,
in my opinion :stuck_out_tongue:

2012/12/7 Gabriel Jacobo :>

2012/12/7 wboe <w.boeke at upcmail.nl>

Hi,
What was the motivation to typedef SDL_FingerID (and SDL_TouchID) as
Sint64? I don’t possess that much fingers…
At that it disturbs SDL_Log etc.

wboe

You don’t know where evolution will takes us, it’s better to be prepared,
after all we don’t want for the public to blame us for a "Y2K of fingers"
when the mutants start showing up.

Seriously though, it’s because those ids can be (IIRC) actual memory
pointers to internal structures.


Gabriel.


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

But memory pointers should be intptr_t, not int64_t (128-bit address
spaces seem more likely than one may think even without enough RAM to
fill the 64-bit range, if one considers all the ways in which the
address space could be used).

I don’t know if I fear most a future with 64 fingers people or a future
with operative systems that needing more than 2^64 bytes :)On Fri, Dec 7, 2012 at 2:34 PM, Sik the hedgehog <sik.the.hedgehog at gmail.com wrote:


Bye,
Gabry

To be fair, 64 fingers may be doable with a big screen actually, just
get multiple people together. Also you could take it further and use
physical stuff that can be detected by the touch screen, could be
handy for stuff similar to board games or the like. You could VERY
easily surpass the 64 limit that way.

And 128-bit address spaces would be more likely than you think.

2012/12/7 Gabriele Greco <gabriele.greco at darts.it>:>

On Fri, Dec 7, 2012 at 2:34 PM, Sik the hedgehog <@Sik_the_hedgehog> wrote:

But memory pointers should be intptr_t, not int64_t (128-bit address
spaces seem more likely than one may think even without enough RAM to
fill the 64-bit range, if one considers all the ways in which the
address space could be used).

I don’t know if I fear most a future with 64 fingers people or a future with
operative systems that needing more than 2^64 bytes :slight_smile:


Bye,
Gabry


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Message-ID:
<CAKDfes=xRhYOp0Y=GNiNwEDQQDmDxod1R-WqZFM7L2zfLg22yQ at mail.gmail.com>
Content-Type: text/plain; charset=“iso-8859-1”

2012/12/7 wboe <w.boeke at upcmail.nl>

**
Hi,
What was the motivation to typedef SDL_FingerID (and SDL_TouchID) as
Sint64? I don’t possess that much fingers…
At that it disturbs SDL_Log etc.

wboe

You don’t know where evolution will takes us, it’s better to be prepared,
after all we don’t want for the public to blame us for a "Y2K of fingers"
when the mutants start showing up.

Seriously though, it’s because those ids can be (IIRC) actual memory
pointers to internal structures.

In the case of active styluses, you could also find that the
individual styluses are assigned unique ids at the factory, and 64
bits should hopefully be (more than) enough space to eliminate the
possibility of winding up with a duplicate id.> Date: Fri, 7 Dec 2012 10:18:55 -0300

From: Gabriel Jacobo
To: SDL Development List
Subject: Re: [SDL] Why typedef Sint64 SDL_FingerID?

Date: Fri, 7 Dec 2012 10:34:18 -0300
From: Sik the hedgehog <sik.the.hedgehog at gmail.com>
To: SDL Development List
Subject: Re: [SDL] Why typedef Sint64 SDL_FingerID?
Message-ID:
<CAEyBR+XudeaxHPW=9E4tKvr-7PW53Kh59AVUNwXtjipxAou9Mg at mail.gmail.com>
Content-Type: text/plain; charset=UTF-8

Then again pointers should never be casted to integers for starters,
in my opinion :stuck_out_tongue:

Certainly not for ordinary usage, but for process-unique id numbers
and situations where you want a ‘generic value’ facility (such as an
improved setjmp()/longjmp() ) casting does make sense.

ESPECIALLY for process-unique ids. There’s no other way to get them
that’s quite as convenient as casting from a relevant address. It
doesn’t even require any specialized infrastructure.

Hi,
I have the feeling that 3 kind of uses are mixed up in the foregoing discussions about SDL_FingerID:
used as a number indicating one finger
used as a pointer disguised as a Sint64
used as a bit array of 64 bits, indicating the state of maximum 64 fingers

As Hamlet said: “Where’s the truth to be found?”

wboe

The lady in pink has chosen Door Number 2! Harvey, tell her what she’s won!On Sat, Dec 8, 2012 at 1:16 AM, wboe <w.boeke at upcmail.nl> wrote:

**
Hi,
I have the feeling that 3 kind of uses are mixed up in the foregoing
discussions about SDL_FingerID:
used as a number indicating one finger
used as a pointer disguised as a Sint64
used as a bit array of 64 bits, indicating the state of maximum 64 fingers

As Hamlet said: “Where’s the truth to be found?”

wboe


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

That’s the most random message I’ve ever seen in this list.

2012/12/8 Sam Lantinga :> The lady in pink has chosen Door Number 2! Harvey, tell her what she’s won!

On Sat, Dec 8, 2012 at 1:16 AM, wboe <w.boeke at upcmail.nl> wrote:

Hi,
I have the feeling that 3 kind of uses are mixed up in the foregoing
discussions about SDL_FingerID:
used as a number indicating one finger
used as a pointer disguised as a Sint64
used as a bit array of 64 bits, indicating the state of maximum 64 fingers

As Hamlet said: “Where’s the truth to be found?”

wboe


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Tse tse …
16000+ views and still no answer to a simple question.javascript:emoticon(’[Crying or Very sad]’)

2012/12/10 wboe <w.boeke at upcmail.nl>

**
Tse tse …
16000+ views and still no answer to a simple question.javascript:emoticon(’[image:
Crying or Very sad]’)


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

You already got the answer (twice, I believe), SDL_FingerID is a type
casted pointer to an internal structure.–
Gabriel.

Which doesn’t explain why isn’t it a pointer in the first place.

2012/12/10 Gabriel Jacobo >

2012/12/10 wboe <w.boeke at upcmail.nl>

Tse tse …
16000+ views and still no answer to a simple
question.javascript:emoticon(’’)


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

You already got the answer (twice, I believe), SDL_FingerID is a type
casted pointer to an internal structure.


Gabriel.


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

2012/12/10 Sik the hedgehog <sik.the.hedgehog at gmail.com>

Which doesn’t explain why isn’t it a pointer in the first place.

2012/12/10 Gabriel Jacobo <@Gabriel_Jacobo>

2012/12/10 wboe <w.boeke at upcmail.nl>

Tse tse …
16000+ views and still no answer to a simple
question.javascript:emoticon(’’)


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

You already got the answer (twice, I believe), SDL_FingerID is a type
casted pointer to an internal structure.

I think (my own opinion, may not be even remotely correct), that it’s due
to a encapsulation philosophy. You don’t want people accessing that
internal structure externally, so while you provide the pointer to the end
user to make it easy to look it up internally later on (instead of keeping
an additional table of finger number -> finger structure), you don’t want
to give the end user the wrong idea to use this as a pointer to a structure
or typecast this to a pointer back again, it just works as a unique
identifier that only makes sense to SDL internally. To you the end user it
may just be a random number.–
Gabriel.

Then we get 128-bit pointers some day and it breaks :confused: I’d personally
just make an opaque structure (i.e. a typedef to a struct, without any
definition of said struct), then if the user modifies the structure
somehow it’ll be because the user really is asking for trouble.

Basically: typedef struct Foobar* SDL_FingerID; (the real definition
would be in one of the source files and not available to the user in
any way)

For now I’d suggest treating that type as 100% opaque…

2012/12/10 Gabriel Jacobo :>

2012/12/10 Sik the hedgehog <@Sik_the_hedgehog>

Which doesn’t explain why isn’t it a pointer in the first place.

2012/12/10 Gabriel Jacobo

2012/12/10 wboe <w.boeke at upcmail.nl>

Tse tse …
16000+ views and still no answer to a simple
question.javascript:emoticon(’’)


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

You already got the answer (twice, I believe), SDL_FingerID is a type
casted pointer to an internal structure.

I think (my own opinion, may not be even remotely correct), that it’s due to
a encapsulation philosophy. You don’t want people accessing that internal
structure externally, so while you provide the pointer to the end user to
make it easy to look it up internally later on (instead of keeping an
additional table of finger number -> finger structure), you don’t want to
give the end user the wrong idea to use this as a pointer to a structure or
typecast this to a pointer back again, it just works as a unique identifier
that only makes sense to SDL internally. To you the end user it may just be
a random number.


Gabriel.


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

2012/12/10 Sik the hedgehog <sik.the.hedgehog at gmail.com>

Then we get 128-bit pointers some day and it breaks :confused: I’d personally
just make an opaque structure (i.e. a typedef to a struct, without any
definition of said struct), then if the user modifies the structure
somehow it’ll be because the user really is asking for trouble.

Basically: typedef struct Foobar* SDL_FingerID; (the real definition
would be in one of the source files and not available to the user in
any way)

For now I’d suggest treating that type as 100% opaque…

Also, IIRC on Android SDL_FingerID (or TouchID, one of those) is the actual
finger number and not a pointer.

When trying to wrap different architectures and design philosophies, some
leaky abstractions are bound to happen, I guess… patches welcome? :)–
Gabriel.

Can we all agree that this is a mess at least? :stuck_out_tongue: I think we should
just take a look at all the platforms and see what they do and then
determine what to do.

In the worst case the pointer to opaque structure is probably going to
work everywhere, since at worst you could just make a struct that just
contains an ID (atomic values in SDL are stored that way actually).

2012/12/10 Gabriel Jacobo :>

2012/12/10 Sik the hedgehog <@Sik_the_hedgehog>

Then we get 128-bit pointers some day and it breaks :confused: I’d personally
just make an opaque structure (i.e. a typedef to a struct, without any
definition of said struct), then if the user modifies the structure
somehow it’ll be because the user really is asking for trouble.

Basically: typedef struct Foobar* SDL_FingerID; (the real definition
would be in one of the source files and not available to the user in
any way)

For now I’d suggest treating that type as 100% opaque…

Also, IIRC on Android SDL_FingerID (or TouchID, one of those) is the actual
finger number and not a pointer.

When trying to wrap different architectures and design philosophies, some
leaky abstractions are bound to happen, I guess… patches welcome? :slight_smile:


Gabriel.


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

You already got the answer (twice, I believe), SDL_FingerID is a type casted pointer to an internal structure.

Gabriel.

Thanks Gabriel, but I’m afraid I don’t agree. If I look at testgesture.c in the test/ directory, line 279:
SDL_Log(“Finger: %“PRIs64” down - x: %i, y: %i”,
event.tfinger.fingerId, …

After preprocessing this is similar to:
SDL_Log(“Finger: %lld down - x: %i, y: %i”,
event.tfinger.fingerId, …

So fingerId is treated as a long long integer, and indeed is displayed as 0, 1, 2 etc.

2012/12/10 wboe <w.boeke at upcmail.nl>

**

Quote:

You already got the answer (twice, I believe), SDL_FingerID is a type
casted pointer to an internal structure.

Gabriel.

Thanks Gabriel, but I’m afraid I don’t agree. If I look at testgesture.c
in the test/ directory, line 279:
SDL_Log(“Finger: %“PRIs64” down - x: %i, y: %i”,
event.tfinger.fingerId, …

After preprocessing this is similar to:
SDL_Log(“Finger: %lld down - x: %i, y: %i”,
event.tfinger.fingerId, …

So fingerId is treated as a long long integer, and indeed is displayed as
0, 1, 2 etc.


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

You guys should take a look at the source code, it’s quite self explanatory.

From SDL_uikitview.m

UITouch touch = (UITouch)[enumerator nextObject];

#ifdef IPHONE_TOUCH_EFFICIENT_DANGEROUS
// FIXME: TODO: Using touch as the fingerId is potentially dangerous
// It is also much more efficient than storing the UITouch pointer
// and comparing it to the incoming event.
SDL_SendFingerDown(touchId, (SDL_FingerID)touch,
SDL_TRUE, locationInView.x, locationInView.y,
1);
#else

So, here SDL_FingerID = pointer to UITouch structure.

On Android (possibly other platforms), the touch code receives a finger
number that starts from zero, so in Android SDL_FingerID is the actual
finger number.–
Gabriel.

wboe,

You have to remember the cross-platform nature of SDL to understand why the
finger is a Sint64. On some platforms, you literally get a finger index/id
for each touch, so having an integer makes sense, and I don’t see the
technology handling 64 fingers any time soon. For the platforms that do
use internal structures, Sam/Ryan/whomever had to decide if it was better
to use some sort of union with an open pointer available to the dev, or do
some casting with the Sint64. They obviously chose the route of casting
because it can all be done safely internally so the touch api is the same
across all platforms.

For those worried about have 128 bit numbers, that’s ridiculous. 64 bit
technology for everyday use is still fairly young. The processor bits
usually only changes when we reach some sort of limit in RAM, and do you
know the max amount of RAM 64 bit can handle? 128GB - that’s more than any
current computer has enough RAM slots for, and I suspect that’s not going
to change for at least a few years, therefore it will be highly unlikely
that within SDL 2.x’s lifespan we’ll need to support 128 bit computing.
Bringing that back to touch devices, it is extremely unlikely that for
index-based touch events that you will ever have more than 64 fingers at
once - if you think one day there will be some sort of common-use
table/surface for roughly 6 people to use simultaneously with both hands, I
don’t see a reasonable use case for that.

I also don’t see a weighing reason why any dev should go back through the
touch events and change it to a pointer. The Sint64 works quite well for
all supported platforms.

To explain Sam’s response, he is essentially saying there were multiple
ways (“doors”) that are all logically correct to take, and they chose to
use Sint64 rather than pointers or some sort of custom SDL structure.

-Alex

If the ID is a pointer or an incremental index, then it’s not limited to 64
touches. The future is fingerful.

Jonny DOn Mon, Dec 10, 2012 at 9:33 AM, Alex Barry <alex.barry at gmail.com> wrote:

wboe,

You have to remember the cross-platform nature of SDL to understand why
the finger is a Sint64. On some platforms, you literally get a finger
index/id for each touch, so having an integer makes sense, and I don’t see
the technology handling 64 fingers any time soon. For the platforms that
do use internal structures, Sam/Ryan/whomever had to decide if it was
better to use some sort of union with an open pointer available to the dev,
or do some casting with the Sint64. They obviously chose the route of
casting because it can all be done safely internally so the touch api is
the same across all platforms.

For those worried about have 128 bit numbers, that’s ridiculous. 64 bit
technology for everyday use is still fairly young. The processor bits
usually only changes when we reach some sort of limit in RAM, and do you
know the max amount of RAM 64 bit can handle? 128GB - that’s more than any
current computer has enough RAM slots for, and I suspect that’s not going
to change for at least a few years, therefore it will be highly unlikely
that within SDL 2.x’s lifespan we’ll need to support 128 bit computing.
Bringing that back to touch devices, it is extremely unlikely that for
index-based touch events that you will ever have more than 64 fingers at
once - if you think one day there will be some sort of common-use
table/surface for roughly 6 people to use simultaneously with both hands, I
don’t see a reasonable use case for that.

I also don’t see a weighing reason why any dev should go back through the
touch events and change it to a pointer. The Sint64 works quite well for
all supported platforms.

To explain Sam’s response, he is essentially saying there were multiple
ways (“doors”) that are all logically correct to take, and they chose to
use Sint64 rather than pointers or some sort of custom SDL structure.

-Alex


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org