[Lazarus] strcat problem

David W Noon david.w.noon at googlemail.com
Thu Jun 23 21:40:52 CEST 2016

Hash: SHA1

On Thu, 23 Jun 2016 21:08:14 +0200, Koenraad Lelong
(lazarus2 at de-brouwerij.be) wrote about "Re: [Lazarus] strcat problem"
(in <576C339E.6020601 at de-brouwerij.be>):

> Op 23-06-16 om 16:58 schreef David W Noon:
>> [snip]
>>> cTekst:=#13'Now is the winter of our discontent'#13;
>> You need a trailing #0 byte on the end.
> The definition of cTekst : var cTekst : PChar;
> So the compiler knows cTekst is a 0-terminated string doesn't, it
> ?

The cTekst variable is actually a pointer.

It's the string literal that needs the trailing NUL byte.

Moreover, assigning to a pointer typically modifies the address,
rather than copying new text into the buffer. The idiomatic C function
for this is strcpy().

> And StrCat needs two parameters : PChar and PChar. So I think the 
> compiler knows the strings are zero-terminated.

I think both literals need a trailing NUL.

The compiler probably knows nothing about StrCat() besides that it
takes 2 pointers as parameters. It is the RTL that expects to receive
NUL-terminated strings as arguments.

> Besides, on my OpenSuse-box it works, or is that by chance ?

It could be that the data segment is initialized to binary zeroes on
the Intel/AMD processor and left as junk on the ARM processor. This
could be an artefact of the binutils on the different hardware
platforms, as the ARM binaries might be sparsely defined in the
executable, whereas the Intel binaries can be padded with zeroes.
- -- 

Dave  [RLU #314465]
david.w.noon at googlemail.com (David W Noon)

Version: GnuPG v2


More information about the Lazarus mailing list