STRPTR and NUL

[Roger Garstang]

This is a weird question I never had to ask before because I usually used ASCIIZ strings which always had NULL characters appended, but as I was looking at some of FF's generated functions I noticed on some occasions that STRPTR was given to a function expecting a NULL terminated string.  As far as I knew variable length strings didn't automatically append NULL characters, but these functions work fine.

PB Help says variable length strings use the Win32 OLE string engine, so when the pointer is passed is it NULL terminated then?  If that is the case, then there isn't much point in ASCIIZ other than their fixed length...which aside from speed and ease of access is to me a disadvantage.

[George Bleck]

One benefit of ASCIIZ strings is that they pre-allocate space, so when you declare it you also reserve the space up-front.  OLE strings are created dynamically so you need do to a =SPACE$(x) prior to passing it as a buffer to a function using BYVAL STRPTR.

P.S. OLE strings have an implicit ending NUL so it will work with BYVAL STRPTR nicely as you noticed.  The only problem is that if the function changes the length of the string the OLE string will still be the same length but you will need to do an EXTRACT$ up to the first NUL to get the new/proper string.

[Roger Garstang]

Thanks George, that explained it.  So, Variable length strings just have the NULL that isn't included in the string size unless a different length string with a NULL is stored in it and then I need to Extract up to it.


I don't think I use any functions with variable strings that would change the size.  When I return values to a string I usually always use ASCIIZ, but now I at least know I can send values with variable strings.  That is something PB should document in the Variable Length String help or at least in the STRPTR function since it is the function used to get the handle to the data.  I imagine that is the first thing people will run into in switching to FF since DDT hides it all.