On 28.09.2010, at 23:22, Ian MacArthur wrote:
> ... Here, at this point in the
> code, what we are trying to do is form a UUID on a WinXX system that
> does not have the UuidCreate() function available (probably because it
> does not have the Rpcrt4.dll available for some reason...)
...
> So, without any testing whatsoever, here's a guess; try this -
>
> // unsigned int a = (unsigned int)&t; // four more bytes
> union { void *pv; unsigned char a[sizeof(void*)]; } v;
> v.pv = (void *)(&t);
> // we will extract 4 more bytes from the address of t
> b[8] = v.a[0];
> b[9] = v.a[1];
> b[10] = v.a[2];
> b[11] = v.a[3];
I don't want to be nitpicking, but there are two points to
consider WRT randomness of these four bytes:
(1) This works as expected only on little-endian machines. On big
endian machines these bytes will either be (near) zero or close
to 0xffffffff (these will be the four high-order bytes of the
address). You can see in Greg's example that the pointer is
0x7fff86b85318 = 0x00007fff86b85318, and this would yield
b[8]=b[9]=0x00, b[10]=0x7f, b[11]=0xff. There may also be
implementations where all these four bytes will be 0xff. In
Greg's case, I assume that these four bytes would always have
this value.
(2) Even on little-endian machines, the current stack pointer may
always be at similar addresses, depending on the calling depth,
so that the 3rd and 4th bytes will probably always be identical.
---
That said, I can live with this because it is only the fallback
mechanism, only on Windows, and it concerns only four bytes.
Are there any current (or, for this case *older*) Windows
versions on big-endian machines at all?
And, to be honest, the existing code has the same issues...
Thus, I think it is okay to use, but we should be aware of this.
Unless someone has a better idea... ;-)
Albrecht
_______________________________________________
fltk mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk
