Announcement

Collapse
No announcement yet.

Guid

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Guid

    I"m not clear about this ..

    $MyGUID = GUID$("{01234567-89AB-CDEF-FEDC-BA9876543210}")

    I have to put in a human-readable GUID as an argument in order to return a GUID? If I already have the GUID, why do I need GUID$?

    What does GUID$ do to the argument? And how is the returned value different than the binary equivalent of the hexadecimal GUID argument string?

  • #2
    You are just assigning it to a global string.
    From the manual...
    The return string may be assigned to a dynamic string, or a fixed-length string of at least 16 bytes, or (typically) a GUID variable. See DIM for more information on creating GUID variables.
    $MyGUID is the nonhuman readable 16 byte version. You will need to do this to make it human readable again...
    ? GUIDTXT$($MyGUID)

    Comment


    • #3
      At 16 bytes, the binary form of a GUID has to be a string, though nonhuman readable.
      GUID$() gives a new binary GUID.
      GUID$({hextxt$}) converts human readable hex to binary.
      GUIDTXT$() converts binary to human readable

      Cheers,
      Dale

      Comment


      • #4
        Jim just did it again. An inaccurate answer edited after a correct answer is posted.
        Dale

        Comment


        • #5
          You are just assigning it to a global string.
          And the string does not have to be GLOBAL.
          Dale

          Comment


          • #6
            So Jim's 2nd version is inaccurate in a different way.

            He complains that edit allowed time should be longer, he is the reason it should be shorter.
            Dale

            Comment


            • #7
              As I've said many times. Slow typist.

              Comment


              • #8
                Originally posted by Gary Beene View Post
                I"m not clear about this ..

                $MyGUID = GUID$("{01234567-89AB-CDEF-FEDC-BA9876543210}")

                I have to put in a human-readable GUID as an argument in order to return a GUID?
                Yes

                If I already have the GUID, why do I need GUID$?
                Because without it, you don't have the 16 byte GUID, you only have a 38 byte string that "looks like" a GUID. i.e. is a human readable representation of the bytes that are in the GUID.

                What does GUID$ do to the argument?
                It turns that 38 byte "GUID looking" string into an actual 16 byte GUID
                .
                And how is the returned value different than the binary equivalent of the hexadecimal GUID argument string?
                It's not different. It IS the binary equivalent of the hex string. But remember, the hex string is NOT a GUID, it's just a readable representation of the GUID

                Comment


                • #9
                  As I've said many times. Slow typist.
                  So you put any old garbage, then go fix it when caught?

                  Type as slow as you want for correct answer, then hit Post Reply.
                  Dale

                  Comment


                  • #10
                    There was nothing wrong with what I had originally. If you cannot keep up then maybe you should move on.
                    Version 1
                    You are assigning it to a string.
                    Version 2
                    You are assigning it to a global string.
                    Version 3
                    You are assigning it to a global string.
                    From the manual...
                    The return string may be assigned to a dynamic string, or a fixed-length string of at least 16 bytes, or (typically) a GUID variable. See DIM for more information on creating GUID variables.
                    Version 4
                    You are assigning it to a global string.
                    From the manual...
                    The return string may be assigned to a dynamic string, or a fixed-length string of at least 16 bytes, or (typically) a GUID variable. See DIM for more information on creating GUID variables.
                    $MyGUID is the nonhuman readable 16 byte version. You will need to do this to make it human readable again...
                    ? GUIDTXT$($MyGUID)

                    Comment


                    • #11
                      Originally posted by Jim Fritts View Post
                      You are just assigning it to a global string.
                      From the manual...


                      $MyGUID is the nonhuman readable 16 byte version. You will need to do this to make it human readable again...
                      ? GUIDTXT$($MyGUID)
                      It's not a "version". it is the GUID. The human readable string is not a "version" , it is a representation which is a totally different concept (just as the string "FF" is NOT the number 255)

                      Thinkng that the 16 byte GUID string and the 38 byte human representation are both "versions of the GUID" is where Gary's (and many other people's) confusion arises.

                      Comment


                      • #12
                        Version represents the iterations of my post. I showed the changes so Dale could keep up with the logical methods I displayed.

                        Comment


                        • #13
                          Originally posted by Jim Fritts View Post
                          Version represents the iterations of my post. I showed the changes so Dale could keep up with the logical methods I displayed.
                          I was referring to your misuse of the word "version" in your last edit of post #2, not your use of it in post #10 .

                          I would have thought that was obvious from the quote in post #11

                          Comment


                          • #14
                            Originally posted by Jim Fritts View Post
                            Version represents the iterations of my post. I showed the changes so Dale could keep up with the logical methods I displayed.
                            None of which are actually accurate or pertinent to Gary's questions
                            (see post #8)

                            Comment


                            • #15
                              Yes, that thread went off in another direction very fast!

                              This might be a better way to ask my question.

                              If the GUID is simply a big unique number, how is GUID$(thenumber) different than Hex$(thenumber)? Other than formatting ...

                              Is the only point of having a hex string GUID$ is so that folks don't have to record/write an integer number with more digits than the hex number?

                              Comment


                              • #16
                                Originally posted by Gary Beene View Post
                                If the GUID is simply a big unique number, how is GUID$(thenumber) different than Hex$(thenumber)? Other than formatting ...

                                Is the only point of having a hex string GUID$ is so that folks don't have to record/write an integer number with more digits than the hex number?
                                Let me try to rephrase what I said earlier.

                                Stop thinking of a GUID as a number!

                                A GUID is not a "big unique number". It is a "big unique string of bits". (128 bits to be exact).

                                Where it needs to be communicated to humans or transferred over a text only medium, a GUID is represented by a human readable string in a specific format - groups of hexadecimal numbers, which represent groups of bits, divided by dashes. Note that what hex characters are used to represent the groups of bits is dictated by the RFC. It is not necessarily the way in which numbers are represented by bits in a particular environment (think big v little endian storage and different numbers of bits in each group).


                                That string is NOT the GUID and is NOT a number. It's just a text representation of the GUID.

                                To quote the authoritative RFC 4122:
                                The internal representation of a UUID is a specific sequence of bits in memory, as described in Section 4. To accurately represent a UUID as a URN, it is necessary to convert the bit sequence to a string representation.
                                For all the gory details of how a GUID i built and how its text repreentation is derived, see the RFC: https://www.ietf.org/rfc/rfc4122.txt

                                Bottom Line:
                                GUID$(thetext) converts the 38 character text representation of the GUID into the "string" of 128 bit which is the actual GUID.

                                Comment


                                • #17
                                  Howdy, Stuart!

                                  And thanks for the additional comments.

                                  To keep that discussion going, despite your comment, it's easy to find hundreds of examples where sites describe a GUID as a 128-bit number. So how do I reconcile the many references of a GUID as a number?


                                  A universally unique identifier (UUID) is a 128-bit number ...

                                  GUID (or UUID) is an acronym for 'Globally Unique Identifier' (or 'Universally Unique Identifier'). It is a 128-bit integer number...

                                  A unique 128-bit number that is...

                                  Using a pseudo-random 128-bit number, ...

                                  The form GUID (Globally Unique Identifier) is a 128-bit integer number ...
                                  I understand your point that a GUID is a 128-bit sequence of bits. Calling it either a String or a Number seems an arbitrary point of view, one demonstrated by the use of "number" in the literature.

                                  Looking at the RFC, however, it is clear that GUID content includes time-stamp information, so it is not the intention of the RFC to simply create large number.

                                  It seems that given the appropriate functions, code could treat the GUID as either.

                                  Comment


                                  • #18
                                    And, Stuart,

                                    This seems disingenuous ....

                                    That string is NOT the GUID
                                    The hex string "0A" is just text, representing the number 10. The hex string is NOT the number, but we still say that "0A is the number 10".

                                    The same seems true for a GUID. The 32-character hexadecimal string is just text, but we still say that the string represents a number resulting from interpreting the 128 bits of the GUID. Ok, I know you don't describe a GUID as a number, but I am seeing it often described that way elsewhere.

                                    I'm clear on the idea that a GUID is 128 bits of information. But it is not obvious that calling it a number is incorrect, to the extent that the number can accurately specify the 128 bits of information.

                                    Comment


                                    • #19
                                      Originally posted by Gary Beene View Post
                                      Howdy, Stuart!

                                      And thanks for the additional comments.

                                      To keep that discussion going, despite your comment, it's easy to find hundreds of examples where sites describe a GUID as a 128-bit number. So how do I reconcile the many references of a GUID as a number?
                                      They are all reflecting the same misconception. Read the RFC. That's the only place you will get the definitive answer.

                                      Looking at the RFC, however, it is clear that GUID content includes time-stamp information, so it is not the intention of the RFC to simply create large number.
                                      Exactly, and that answers you first question

                                      t seems that given the appropriate functions, code could treat the GUID as either.
                                      Code could treat that string of bits as a number, but two machines which use different endian interpretation would see it as two different numbers. Which sort of defeats the purpose of a universal unique identifier.
                                      Note that the RFC specifies that bits are translated to hexadecimal characters by taking bytes in "network byte order" i..e. (big endian) when building the human readable representation. Since Windows is little endian, if you convert the human readable representation of the GUID to a "large number" based on the hexadecimal digits, you will get a completely different GUID. (It's similar to the situation in a recent thread where someone had to swap bytes in a large data feed to get the desired result).

                                      Bottom line once again: A GUID is a string of 128 bits. The human readable representation of the GUD is a 38 character string of formatted hexadecimal digits which DO NOT translate directly into the bits in the GUID..


                                      Comment


                                      • #20
                                        Originally posted by Gary Beene View Post
                                        And, Stuart,

                                        This seems disingenuous ....

                                        The hex string "0A" is just text, representing the number 10. The hex string is NOT the number, but we still say that "0A is the number 10".

                                        The same seems true for a GUID. The 32-character hexadecimal string is just text, but we still say that the string represents a number resulting from interpreting the 128 bits of the GUID. Ok, I know you don't describe a GUID as a number, but I am seeing it often described that way elsewhere.

                                        I'm clear on the idea that a GUID is 128 bits of information. But it is not obvious that calling it a number is incorrect, to the extent that the number can accurately specify the 128 bits of information.
                                        There is nothing disingenuous about it.

                                        See above concerning byte order. Which is the larger number "DDCC" or "CCDD"? It depends inter alia on the byte order used to store the number. (Endianness)
                                        What number does "DDCC" represent?
                                        It is 56780 on your Windows PC . But to a big endian computer or any operations using "network byte order" it is 52445.
                                        What number does "CCDD" represent?
                                        Exactly the oppossite:
                                        It s 52445 on your Windows PC. It is 5790 on a big-endian system

                                        Bottom line again:
                                        The string "89AB" in your first post is NOT the number 35243. It is just ONE specified representation of a string of bits.
                                        The bit sequence your PC uses to represent the Hexadecimal value of &H89AB" is NOT the same as the bit sequence in the GUID which that string of hex characters represent.

                                        Comment

                                        Working...
                                        X