"R.Wieser"  writes:

> Pascal,
>
>> In case you didn't notice, the terminating null is not stored
>
> Really ?    Good luck with "printf" -ing such a non-terminated string than.
> :-)
>
>> or transmitted to external devices.
>
> Wrong.    See below.
>
>> When you display the string on a screen, print it in a printer, transmit
>> it to
>> a remote terminal, etc, the null byte should not be displayed, printed
>
> While you are right there, seeing it or not is a whole other matter.
>
>> transmitted.
>
> Good luck with determining where one string ends and the next one starts I
> would say. :-)
>
> And by the way: The "nul" character was used as a short delay for the, long
> ago, mechanical(!) teletypes (no handshaking, no hold-off or buffering
> facilities) as a short delay - so that the stream of send characters could
> be continuous but the TTY had a chance to actually return is carriage and
> progres a line before type the next actual character.
>
> And yes, once upon a time I had such a device. :-)

Indeed, null introduced a delay, due to the time needed to transmit it.
But it was entirely ignored (had to be), by the receiving device.

To separate your strings, you would use the US (Unit Separator) ASCII
code, or transmit a binary length first.


--
__Pascal J. Bourguignon__
http://www.informatimago.com

--- SoupGate-Win32 v1.05