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

[VAXman- at SendSpamHere.ORG]

In article <ldi571$po6$1 at reader1.panix.com>, JohnF <john at please.see.sig.for.email.com> writes:
>VAXman- wrote:
>> In article <ldg4ab$rf8$1 at reader1.panix.com>, 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.  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. ;)


-- 
VAXman- A Bored Certified VMS Kernel Mode Hacker    VAXman(at)TMESIS(dot)ORG

Well I speak to machines with the voice of humanity.