Using BYTE PTR & strings

[Bern Ertl]

I just finished reading Timm's source code thread for string compression
/decompression. I was wondering about the use of BYTE PTRs and strings
(not ASCIIZ). In the source code posted, there are loops which:

pBytePtr = STRPTR( sSomeString)
WHILE @pBytePtr
   INCR pBytePtr
WEND

What happens when the pointer reaches the end of the string? Are regular,
variable length strings also null terminated? How do those loops terminate
at the end of the string?



------------------
Bernard Ertl

[Michael Mattias]

When you use pointers this way, YOU are responsible for exiting the loop when you have processed the correct number of characters.

With an ASCIIZ string, the correct number of characters is LEN(asciizstring). (Maybe minus 1).

PB and Windows will exit the loop for you only with a GPF for a protection exception.

MCM

[Bern Ertl]

Michael, that's what I thought. I just wanted to make sure.



------------------
Bernard Ertl

[Greg Turgeon]

Bern--
   
Yes.  All dynamic strings are automatically terminated with 
a zero byte.  So "WHILE @pBytePtr" and "while @pBytePtr <> 0" 
are equivalent.  This also means that a function that 
expects an ASCIIZ string as a parameter can be called with 
byval strptr(t$) instead. 
   
It's one of those much appreciated but often overlooked 
features of the compilers.

------------------
-- Greg
[email protected]

[Bern Ertl]

Wow! That's NOT what I thought! The PB docs should mention that
somewhere! I'm just beginning to imagine all the LEN() functions
I can eliminate from my code.....

Thanks Greg!



------------------
Bernard Ertl

[Tom Hanlin]

I believe the automatic NUL termination of STRING values is a side-effect of the
current Windows OLE string engine. It's probably safe to rely on, but I'd be more
inclined to use LEN() and skip the guessing games with accidental features.

------------------
Tom Hanlin
PowerBASIC Staff

[Fred Oxenby]

Originally posted by Greg Turgeon:

Bern--
Yes.  All dynamic strings are automatically terminated with 
a zero byte.  So "WHILE @pBytePtr" and "while @pBytePtr <> 0" 
are equivalent.  This also means that a function that 
expects an ASCIIZ string as a parameter can be called with 
byval strptr(t$) instead. 
   
It's one of those much appreciated but often overlooked 
features of the compilers.

Hrmmmm
Someone is in for a big surprise...


------------------
Fred
mailto:[email protected][email protected]</A>
http://www.oxenby.se

[Bern Ertl]

Tom,

This is all a big gray area for me, so forgive me if these
questions are frivolous. Is the memory allocation for dynamic
strings (by the Win OLE engine) in the same memory area that PB
allocates for variables (GLOBAL, STATIC or DYNAMIC)? Is there
a danger that PB might allocate the memory space of that NULL
byte on the dynamic string for a PB variable? Or, is it possible
that the OLE engine would reallocate the byte for that NULL?

If not, does anyone know if the M$ compilers (VB, VC, etc.) use
the same OLE string engine to allocate their (ASCIIZ?) strings?
Do they rely on the NULL allocation?

I'm assuming that the OLE engine works the same on all versions of
32 bit Windows. I would very much like to rely on this behavior if
it appears safe. It would definately help improve a critical section
of my code if I could eliminate several thousand (million?) calls to
LEN().

Fred, what are you insinuating? If you know something pertinent
about this, please let me know!



------------------
Bernard Ertl

[keith d. shelton]

If all dynamic strings are terminated with a null byte then how
would you code a string command to a printer or hardware dongle
that requires nulls in the string? Or how would you have a string
that contains one or two nulls.
Keith Shelton

------------------

[Tom Hanlin]

Bern, I am not quite clear what you're asking. However, I gather that you're
concerned about the possibility of the string's NUL terminator being overwritten.
This should not be an issue.

Keith, a NUL in a dynamic string does not indicate the end of the string. Rather,
the OLE string engine apparently adds a NUL to the end of each string. So, there
is a NUL terminator in addition to any NULs that may be part of the string.


------------------
Tom Hanlin
PowerBASIC Staff

[Greg Turgeon]

 [quote]Someone is in for a big surprise...[/quote]
   
Meaning what?
   
Tom--
   
My understanding of this issue goes way back and involves 
communication not conducted here.  If anything since then
has changed, I haven't heard about it.  If something related 
to this issue has changed, I'm probably not the only person 
who would appreciate clarification.

[This message has been edited by Greg Turgeon (edited March 22, 2001).]

[Fred Oxenby]

Greg, I only compared your answer, explicit stating that you were
talking about Asciiz-strings, with Bern's original question about
dynamic-strings.
As Tom more directly pointed out, NULL can be part of dynamic strings
and does not signal end of string.
Sorry if my posting made someone confused

Originally posted by Bern Ertl:
I just finished reading Timm's source code thread for string compression
/decompression. I was wondering about the use of BYTE PTRs and strings
(not ASCIIZ).

------------------
Fred
mailto:[email protected][email protected]</A>
http://www.oxenby.se

[Greg Turgeon]

 [quote]As Tom more directly pointed out, NULL can be part 
of dynamic strings and does not signal end of 
string.[/quote] 
   
Of course.  Relying on the zero byte as a string terminator 
is reliable only if you know something about the data 
contained in the string.  (I.e., it doesn't contain CHR$(0).)
Returning to Bern's original question, string compression 
that relies on a zero byte terminator will be reliable only 
if the target string doesn't itself contain a zero byte.
   
On a related note, at least one of the sample routines 
distributed with PBDLL and PBCC illustrates relying on the 
zero byte as a string terminator.  (See CAPFIRST.BAS.)  
Adding a clarifying note to this file might be a good idea 
for anyone with a minute to spare.

------------------
-- Greg
[email protected]

[Bern Ertl]

Tom, yes, that was the gist of my queries. I just want to make sure that
neither PB, nor Windows will reuse that memory space in allocating memory
for some other purpose. It is not clear what protections may or may not
exist for that byte since LEN() doesn't indicate that it was allocated.

My second question was an attempt to discern whether or not M$ has "locked"
itself into maintaining this behavior....

Fred, I think you misread Greg's post. He was talking about dynamic
strings, not ASCIIZ. He mentioned ASCIIZ as a case in point.



------------------
Bernard Ertl

[Tom Hanlin]

Microsoft has never been known to lock itself into maintaining any behavior,
which may be a concern. More important, I think, is the way that relying on
obscure implementation features makes code harder to understand and less
portable. I'd guess that it's safe enough to rely on the automatic NUL
terminator at the moment. I personally wouldn't feel good about doing so,
but that's my own preference.

------------------
Tom Hanlin
PowerBASIC Staff