[Info-vax] C... the only winning move is not to play...

[JohnF]

VAXman- wrote:
> JohnF <john at please.see.sig.for.email.com> writes:
>> VAXman- wrote:
>>> JohnF <john at please.see.sig.for.email.com> writes:
>>>> VAXman- wrote:
>>>>> I've been at SUPERVISOR mode in a lot of my time working on
>>>>> a DCL debugger I've mentioned here a few times.
>>>>
>>>>If you don't mind me beating a dead horse (I seem to have
>>>>run out of little puppies to kick), I think dcl is what
>>>>all those str$functions we discussed were really written
>>>>for. That is, but for digital's desire to provide string
>>>>manipulation in dcl, they never would have bothered with
>>>>that str$library. The C headers and stuff were more of an
>>>>afterthought, i.e., as long as the library's there, might
>>> 
>>> Not even close.  There's no STR$anything in DCL.  STR$ANALYZE_SDESC and 
>>> STR$COPY_DX exist in the CLI interface (CLI$ routines) but there NO STR$
>>> WHATSOEVER in DCL itself.
>>
>>Yeah, yeah, so they're f$lexical_functions in dcl.
>>I was guessing f$,str$'s are basically just different
>>names for the same entry points in the rtl library.
>>So I could be wrong about all that, but why would, say,
>>str$element not be f$element?
> 
> Because it's not.
Okay, thanks for the correction (if not clarification).

> While similar in function, it's not implemented by passing 
> F$element arguments to STR$ELEMENT.  If that's what you believe,
> then believe that decc$strcat invokes STR$CONCAT. ;)

I'm trying to str$ing together some witty remark about
believing a fundamentalist interpretation of the bible
versus a fundamentalist interpretation of vms internals,
but it's not coming to me.
-- 
John Forkosh  ( mailto:  j at f.com  where j=john and f=forkosh )