7551 ficl: Implement uuid-to-string and uuid-from-string.

Review Request #253 — Created Nov. 8, 2016 and submitted

tsoome
illumos-gate
7551
de03b34...
general
7551 ficl: Implement uuid-to-string and uuid-from-string.

ok s" 5bb9070c-48f2-4911-e8cb-80325d1da0f4" uuid-from-string uuid-to-string type cr
5bb9070c-48f2-4911-e8cb-80325d1da0f4
ok 

Also tested on real loader:

smbios.system.product=VMware Virtual Platform           
smbios.system.serial=VMware-56 4d ed 79 df a9 40 e1-61 ac 8f 85 11 7b f5 59
smbios.system.uuid=79ed4d56-a9df-e140-61ac-8f85117bf559 
smbios.system.version=None                              
ok s" 79ed4d56-a9df-e140-61ac-8f85117bf559" uuid-from-string uuid-to-string type cr 
79ed4d56-a9df-e140-61ac-8f85117bf559
ok
  • 0
  • 0
  • 3
  • 0
  • 3
Description From Last Updated
tsoome
rm
  1. 
      
  2. usr/src/common/ficl/loader.c (Diff revision 1)
     
     
    uuids is not the clearest variable name. Can we make it clearer?
  3. usr/src/common/ficl/loader.c (Diff revision 1)
     
     
    It seems like uuids is trying to tell us how many bytes to read from uuidp. What are the expectations if uuidp is less than uuids. In the more case, we're covered and that makes semantic sense. What's the API supposed to be here?
  4. 
      
tsoome
tsoome
  1. 
      
  2. usr/src/common/ficl/loader.c (Diff revision 1)
     
     

    There are 2 types of strings used in forth, counted strings, which are represented as pascal string - first byte is the length and the rest is the string itself, and the limit is also obvious. Second variant is address and length, pointer and int pair, in comments its usually denoted as ( addr n ), stating also the stack layout, with rightmost side for stack top.

    So this implementation is expecting string ( addr n ) from stack and will put address of binary representation of uuid into the stack, so the full specification is ( addr n -- addr' ).

    As an general note, there is even no way to distinguish the data, as all words are 32 or 64 bit fields (depending on machine word), so while we certainly can make some inspection for the data (here we know the string length should be 36), in practice it does not matter too much because if there is wrong stack layout, all bets are off anyhow:)

    1. What I'm not sure of is whether it's expecting to say that I have a string which is n bytes long or I have a string that is *up to* n bytes long. From the code, it sounds like the latter, is that right?
    2. Actually the first, its string, n bytes long, as it is not "C" string with terminating '\0'. Which is why it needs to allocate local instance to create zero terminated string for uuid api. In this context, the \0 has no special meaning; essentially this notation is just telling us that we have memory area of n bytes (with whatever content).

    3. If that's the case, should we really be using strncpy? Shouldn't we just use bcopy to ensure that we get everything correct and if for some reason there's an embedded null, we don't lose part of the data?
    4. This is good point, will do.

  3. 
      
tsoome
tsoome
rm
  1. Ship It!
  2. 
      
xenol
  1. Ship It!
  2. 
      
richlowe
  1. Ship It!
  2. 
      
tsoome
Review request changed

Status: Closed (submitted)

Loading...