Announcement

Collapse
No announcement yet.

Are these two things the same thing??

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

  • David Clarke
    replied
    Thanks everybody!!

    Leave a comment:


  • Michael Mattias
    replied
    In my experience, assigning values to fixed length strings (including UDT members) does NOT add a null when to assignment is made using LSET RSET CSET or TYPE SET; however, any assignments made using the assignment operator "=" will do so, truncating the string value if necessary.
    That was in error and I cannot edit it so here it is with the error highlighted..

    In my experience, assigning values to fixed length null-terminated strings (including UDT members) does NOT add a null when to assignment is made using LSET RSET CSET or TYPE SET; however, any assignments made using the assignment operator "=" will do so, truncating the string value if necessary.

    Fixed-length null terminated strings are PB data types ASCIIZ and WSTRINGZ (or altenate names for same).

    Sorry for any inconvenience.

    Leave a comment:


  • Stuart McLachlan
    replied
    Originally posted by Michael Mattias View Post
    In my experience, assigning values to fixed length strings (including UDT members) does NOT add a null when to assignment is made using LSET RSET CSET or TYPE SET; however, any assignments made using the assignment operator "=" will do so, truncating the string value if necessary..
    That's not correct.
    Assigning a value with "=" to a STRING * 32 does NOT add a NULL or truncate the string value. (Even if it is filled with NULLS!).
    '
    Code:
    #COMPILE EXE
    #DIM ALL
    FUNCTION PBMAIN() AS LONG
       LOCAL s  AS STRING  * 32
       s = "123456789"
       ? USING$("len=#  sizeof=#  asc=# (&)", LEN(s),SIZEOF(s),ASC(s),s) + $CR
       s = "ABC"
       ? USING$("len=#  sizeof=#  asc=# (&)", LEN(s),SIZEOF(s),ASC(s),s) + $CR
       s = NUL$(20)
       ' "? s" will truncated the displayed string but the length will not change!!
       'Note the missing closing ")"
       ? USING$("len=#  sizeof=#  asc=# (&)", LEN(s),SIZEOF(s),ASC(s),s) + $CR
       s = "XYZ"
       ? USING$("len=#  sizeof=#  asc=# (&)", LEN(s),SIZEOF(s),ASC(s),s) + $CR
       s = "DEF" & CHR$(0)
       ? USING$("len=#  sizeof=#  asc=# (&)", LEN(s),SIZEOF(s),ASC(s),s) + $CR
    END FUNCTION
    '

    Leave a comment:


  • Stuart McLachlan
    replied
    Originally posted by Dale Yarker View Post
    The subject of David's last question was about WSTRINGZ

    ...LSET, CSET and RSET do not function on WSTRINGZ nor STRINGZ.
    .
    Ashley, they do work

    But they work on the LEN of the string in the STRINGZ, not on the SIZEOF it (just like they do on fixed and variable length STRINGs.
    '
    Code:
    #COMPILE EXE
    #DIM ALL
    FUNCTION PBMAIN() AS LONG
       LOCAL sz AS STRINGZ * 32
       sz = "123456789"  'set string length
       LSET sz = "ABC"
       ? USING$("len=#  sizeof=#  asc=# (&)", LEN(sz),SIZEOF(sz),ASC(sz),sz) + $CR
       RSET sz = "ABC"
       ? USING$("len=#  sizeof=#  asc=# (&)", LEN(sz),SIZEOF(sz),ASC(sz),sz) + $CR
       CSET sz = "ABC"
       ? USING$("len=#  sizeof=#  asc=# (&)", LEN(sz),SIZEOF(sz),ASC(sz),sz) + $CR
    END FUNCTION
    '

    Leave a comment:


  • Dale Yarker
    replied
    The subject of David's last question was about WSTRINGZ

    It is true nulls do not get put in fixed length strings. LSET, CSET and RSET do not function on WSTRINGZ nor STRINGZ.

    LSET, CSET and RSET do pad with spaces to position the characters.

    Nothing to do with how null(s) get into "Z" strings.

    Leave a comment:


  • Michael Mattias
    replied
    In my experience, assigning values to fixed length strings (including UDT members) does NOT add a null when to assignment is made using LSET RSET CSET or TYPE SET; however, any assignments made using the assignment operator "=" will do so, truncating the string value if necessary.

    In what SHOULDbe needless to say, any pseudo-assignment using direct memory access - pointer variables, MEMORY COPY|FILL|SWAP - does not respect any "data type" of any kind either as a source or destination.

    Leave a comment:


  • Mike Doty
    replied
    Here is building the alphabet as a wstringz
    Notice the sizeof(wsz) stays the same, but the len changes
    If string never used ASC(wsz) = -1 and len = 0
    Looped 27 times instead of 26 so the first iteration does not assign a character to wsz
    Code:
    FUNCTION PBMAIN AS LONG
     LOCAL c   AS LONG
     LOCAL wsz AS WSTRINGZ * 27
     LOCAL s  AS STRING
     FOR c = 1 TO 27
      s+=USING$("c=# len=#  sizeof=#  asc=# (&)",c, LEN(wsz),SIZEOF(wsz),ASC(wsz),wsz) + $CR
      wsz+= CHR$(c+64)
     NEXT position
     ? s
    END FUNCTION
    Attached Files

    Leave a comment:


  • David Clarke
    replied
    Thanks Dale!

    Leave a comment:


  • Dale Yarker
    replied
    LOCAL wszAlgId AS WSTRINGZ *3
    wszAlgId = "AB"
    When defining a STRINGZ or a WSTRINGZ the last character is always a nul. So the user can use one character less than defined. If user string is two, or more, characters shorter then a nul is put after that last character automatically. This is one of the better descriptions in help, and very basic knowledge of BASIC.

    Leave a comment:


  • David Clarke
    replied
    You are exactly right Stuart.

    Why don't have to append chr$(0) to the wszAlgId? Are WSTRINGZ *32 always right filled with nul automatically?

    So... if I have:

    LOCAL wszAlgId AS WSTRINGZ *2
    wszAlgId = "AB"

    Is the null there automatically? or should it have been


    LOCAL wszAlgId AS WSTRINGZ *3
    wszAlgId = "AB"

    or

    LOCAL wszAlgId AS WSTRINGZ *3
    wszAlgId = "AB"+chr$$(0)


    Thanks!




    Leave a comment:


  • Stuart McLachlan
    replied
    Looks like you are referring to this from David's HMAC code in the Source Code form:

    BCryptOpenAlgorithmProvider( hHashAlg, "SHA1"$$, $$Nul, 0)

    In this case, BcryptOpenAlgorithmProvider is defined in PBWIn's includes as:
    DECLARE FUNCTION BCryptOpenAlgorithmProvider LIB "BCrypt.dll" _
    ALIAS "BCryptOpenAlgorithmProvider" (phAlgorithm AS DWORD, _
    pszAlgId AS WSTRINGZ, pszImplementation AS WSTRINGZ, _
    BYVAL dwFlags AS DWORD) AS LONG


    In this case, I'd assume that the compiler is converting the wide string literal "SHA1"$$ into the required WSTRINGZ behind the scenes before passing it to the function.
    (Personally, I'd be reluctant to rely on that behaviour and would create a WSTRINGZ variable to pass to the function.)

    Leave a comment:


  • David Clarke
    replied
    Thanks Stuart!

    Leave a comment:


  • Stuart McLachlan
    replied
    No.
    Neither
    Neither.

    All of the methods of adding something to the end a dynamic string are just ugly kludges for development environments that do not have built in Null Terminated Strings.

    If you want a null terminated wide string (WSTRINGZ), then your second option is the "correct" way to do it:
    LOCAL wszAlgId AS WSTRINGZ *5
    wszAlgId = "SHA1"


    Notes:
    1. I use a "wsz" prefix for WSTRINGZ to differntiated them from STRINGZ.
    2. Just because your string contains 4 characters, doesn't mean it has to be dimensioned as "*5", that's just the minimum size you need to hold "SHA1".
    LOCAL wszAlgId AS WSTRINGZ *32
    wszAlgId = "SHA1"

    gives you exactly the same value in wszAlgID and it allows you to replace SHA1 with a longer value elsewhere if needed.


    Leave a comment:


  • David Clarke
    started a topic Are these two things the same thing??

    Are these two things the same thing??

    Is "SHA1"$$ THE SAME AS

    LOCAL SzAlgId AS WSTRINGZ *5
    szAlgId = "SHA1"


    Should I be doing this:

    szAlgId = "SHA1" + CHR$(0) OR should it be szAlgId = "SHA1" + CHR$$(0)

    OR

    szAlgId = "MD5" + $NUL OR should it be szAlgId = "MD5" + $$NUL



Working...
X