[Info-vax] Calling standards, was: Re: Byte range locking - was Re: Oracle on VMS

[VAXman- at SendSpamHere.ORG]

In article <o175ok$2f0$1 at Iltempo.Update.UU.SE>, Johnny Billquist <bqt at softjar.se> writes:
>On 2016-11-23 18:09, Bill Gunshannon wrote:
>> On 11/23/16 11:36 AM, Johnny Billquist wrote:
>>> On 2016-11-23 16:54, Bill Gunshannon wrote:
>>>> On 11/23/16 4:06 AM, Johnny Billquist wrote:
>>>>> The C standard library use NUL-terminated strings, which (as we all
>>>>> know) have serious security problems, and god knows what else.
>>>>
>>>> Why do people insist on perpetuating the notion that this is a C
>>>> security problem.  C merely continued a practice that predated it
>>>> probably to maintain compatability with earlier code.
>>>
>>> It *is* a C security problem. That does not imply that it isn't a
>>> problem elsewhere as well, but trying to deny that this is a problem in
>>> C is silly. And it certainly does not imply that the problem only
>>> appeared with C. But it still is a problem in C...
>>
>> Of course it's a C problem.  But people seem to think that C caused it.
>> C merely chose to not violate an existing practice.  It would not
>> surprise me to find out that the .ASCIZ directive directly influenced
>> the choice to use null terminated strings in C.  But I guess we'll
>> never know.
>
>I doubt that anything in MACRO-11 in any way reflected on anything in C 
>or vice versa.
>
>Using NUL as a terminator was, as you mention, not unheard of. RT-11 
>does it. So does other systems. So, having MACRO-11 capable of creating 
>such strings is no surprise.
>
>Having C strings being terminated by NUL is also no big thing. But C and 
>Unix took their cues from other sources than DEC. Multics, BCPL, B... 
>There are many things to look at.
>
>>>> The PDP-11 Macro Directive .PRINT takes a null terminated string
>>>> as its only argument.  I suspect the VAX had the same and it
>>>> probably still exists in MACRO but I don't have my manual handy to
>>>> verify that.
>>>
>>> The *RT-11* Macro Directive .PRINT takes a null terminated string. Not
>>> PDP-11 MACRO in general. Try that on RSX, and you'll just get an error
>>> when assembling... :-)
>>>
>>
>> True.  I just looked in my RSTS manual and the RSX executive doesn't
>> have .ANYTHING directives at all.  Now I have to go look at some of
>> my other manuals and see just who else used null terminated strings.
>> UNIVAC-1100 did not.  It, too, had descriptors.  I have a number of
>> other assembler manuals be interesting to know just how many used
>> null termination as a common method.  I know it was fairly common
>> in Z80 code i worked with even before a C compiler became common.
>
>In most processors, using a NUL to indicate the end of a string makes it 
>efficient to write the code. So you'll probably see it on almost any 
>architecture where people want to deal with dynamic length strings.
>
>The other alternative is to keep a count, but that uses more memory, and 
>in some cases adds a bit of complexity, which people often try to avoid 
>(programmers being lazy and all).

Memory is cheap!  Considering other coding practices today that bloat code,
a byte count of a string is pale by comparison.


>But Unix, as well as RSX and VMS, do not have any OS interfaces that use 
>NUL terminated strings. Library functions on the other hand might...
>
>	Johnny
>
-- 
VAXman- A Bored Certified VMS Kernel Mode Hacker    VAXman(at)TMESIS(dot)ORG

I speak to machines with the voice of humanity.