02.07.2012 7:22, Adriano dos Santos Fernandes wrote:
>> Do we have any idea how many people are running Firebird 2.5.x successfully
>> on big-endian platforms?
>
> This is another question to decide about fix the function or create new
> ones.
I doubt we can know for sure, but their relative amo
Hi Adriano,
> > As for CHAR_TO_UUID and UUID_TO_CHAR: since the 16-char string and the
> > 36-char string (should) have the same order, these two functions could be
> > made dead simple by eliminating the unnecessary steps that convert it to an
> > FB_GUID struct and back again.
> >
>
> Sure, t
02.07.2012 4:51, Paul Vinkenoog wrote:
> Do we have any idea how many people are running Firebird 2.5.x successfully
> on big-endian platforms?
I'd say that this number is about zero, taking into account all reported in
tracker
crashes and other problems on MacOS.
--
WBR, SD.
-
On 01-07-2012 23:40, Paul Vinkenoog wrote:
>> So, all in all, our five UUID functions are all flawed on at least one type
>> of platform. But it's not hard to get them right, with code that is even
>> simpler than what we have now (and without the need for the '2' functions).
>
> As for CHAR_TO_
Adriano wrote:
> I'd still prefer someone testing this
> (http://pastebin.com/raw.php?i=t2eREynZ) on big-endian anre reporting
> the result. I guess the functions are wrong but symmetric on big-endian.
>
> If they are symmetric, we should better create the new functions.
Do we have any idea how m
> So, all in all, our five UUID functions are all flawed on at least one type
> of platform. But it's not hard to get them right, with code that is even
> simpler than what we have now (and without the need for the '2' functions).
As for CHAR_TO_UUID and UUID_TO_CHAR: since the 16-char string an
On 01-07-2012 23:13, Paul Vinkenoog wrote:
> On big-endian machines, UUID_TO_CHAR2 should work fine, because big-endian
> host order is the same as network order (and also "natural" order, the way we
> write our binary, octal, decimal and hexadecimal numbers).
All your analysis seems right for m
[Warning: rather long. But useful, I hope.]
Adriano wrote:
> Can someone look at StringToGuid/GuidToString and confirm that they are
> broken for big-endian (the code branch when legacy == false)?
Unfortunately, I don't have access to a big-endian machine. But the code of
those functions is fla
On 30-06-2012 03:53, Dmitry Yemanov wrote:
> 29.06.2012 19:27, Paul Vinkenoog wrote:
>
>>> - Case for UUID_TO_CHAR will not be changed as this will be backward
>>> incompatible. So we live with it, everyone could use LOWER.
>>
>> Too bad, I would personally have preferred to see it changed. But I
29.06.2012 19:27, Paul Vinkenoog wrote:
>> - Case for UUID_TO_CHAR will not be changed as this will be backward
>> incompatible. So we live with it, everyone could use LOWER.
>
> Too bad, I would personally have preferred to see it changed. But I realise
> that this could break some existing code
On 29/06/2012 12:27, Paul Vinkenoog wrote:
> Too bad, I would personally have preferred to see it changed. But I realise
> that this could break some existing code. Maybe a convenience function
> UUID_TO_LOCHAR would be nice?
>
Well, maybe the *2 routines will be necessary anyway. :-(
Can someon
Adriano wrote:
> > That's right, the problem is in GEN_UUID, not in the conversion functions.
> >
> >
> Thanks for catch this up. I believe you're correct, like I was too, but
> fooled on all the noise of this thread.
Yes, when I re-read the December thread yesterday, I noticed that you were of
On 28/06/2012 14:02, Paul Vinkenoog wrote:
> People, this thread (from Dec 2011) was never properly concluded.
>
>>> On Thu, 15 Dec 2011 15:14:20 -0200, Adriano dos Santos Fernandes
>>> wrote:
There is no UUID "binary representation" in the RFC. There it's just a
formated string.
>>> Ye
I wrote:
> - Fix GEN_UUID by making GenerateGuid() return the time-high-and-version word
> in network order. That's all it takes!
On second thought, it's probably better to do the host-to-network conversion in
evlGenUuid(). After all, GenerateGuid() fills an FB_GUID. This is a C struct
which i
Hello Adriano,
> Can you say, with less words and more examples, what's wrong and why?
>
> I mean, please run the current code and dump some commands, results and
> explanations here.
With the current 2.5.2 snapshot:
SQL> set term #;
SQL> execute block
CON> returns (uuid char(16) character set o
Paul,
Can you say, with less words and more examples, what's wrong and why?
I mean, please run the current code and dump some commands, results and
explanations here.
I didn't ignored Mark's saying "It also explicitly says that bytes
should be in network byte order (aka big-endian)" and my code
People, this thread (from Dec 2011) was never properly concluded.
> > On Thu, 15 Dec 2011 15:14:20 -0200, Adriano dos Santos Fernandes
> > wrote:
> >> There is no UUID "binary representation" in the RFC. There it's just a
> >> formated string.
> > Yes there is a binary representation defined in
On Fri, 16 Dec 2011 09:08:12 +0100, Mark Rotteveel wrote:
> Yes there is a binary representation defined in
> http://www.ietf.org/rfc/rfc4122.txt in section 4.1.2. It also explicitly
> says that bytes should be in network byte order (aka big-endian).
Exactly.
So the problem with our UUID functio
On 16/12/2011 06:08, Mark Rotteveel wrote:
> On Thu, 15 Dec 2011 15:14:20 -0200, Adriano dos Santos Fernandes
> wrote:
>> There is no UUID "binary representation" in the RFC. There it's just a
>> formated string.
> Yes there is a binary representation defined in
> http://www.ietf.org/rfc/rfc4122.
On Thu, 15 Dec 2011 15:14:20 -0200, Adriano dos Santos Fernandes
wrote:
> There is no UUID "binary representation" in the RFC. There it's just a
> formated string.
Yes there is a binary representation defined in
http://www.ietf.org/rfc/rfc4122.txt in section 4.1.2. It also explicitly
says that b
On 15/12/2011 16:46, Leyne, Sean wrote:
Note that in Windows, we generate UUIDs with a WinAPI function so it
generates correct numbers, but in POSIX we just generate random data.
>
>> For Windows users this binary representation is also wrong now, cause
>> reserved bits is not docume
> >> Note that in Windows, we generate UUIDs with a WinAPI function so it
> >> generates correct numbers, but in POSIX we just generate random data.
> >>
> For Windows users this binary representation is also wrong now, cause
> reserved bits is not documented in it.
You wrote that the WinAPI fu
On 15/12/2011 15:04, Leyne, Sean wrote:
> Adriano,
>
>> CORE-3238 is the problem related to UUIDs version and reserved bytes which
>> we're not respecting.
>>
>> Note that in Windows, we generate UUIDs with a WinAPI function so it
>> generates correct numbers, but in POSIX we just generate random d
Adriano,
> CORE-3238 is the problem related to UUIDs version and reserved bytes which
> we're not respecting.
>
> Note that in Windows, we generate UUIDs with a WinAPI function so it
> generates correct numbers, but in POSIX we just generate random data.
>
> 1) So from a POV, we may say our GEN_
All,
CORE-3238 is the problem related to UUIDs version and reserved bytes
which we're not respecting.
Note that in Windows, we generate UUIDs with a WinAPI function so it
generates correct numbers, but in POSIX we just generate random data.
1) So from a POV, we may say our GEN_UUID is correct
25 matches
Mail list logo
