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

JohnF john at please.see.sig.for.email.com
Thu Feb 13 05:02:09 EST 2014


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?

>>as well let C link it. But all other things equal, when
>>writing C you're better advised to use standard C stuff
>>if possible.
> 
> Why?  decc$strcat() provides me with nothing that I get from STR$CONCAT().

-- 
John Forkosh  ( mailto:  j at f.com  where j=john and f=forkosh )



More information about the Info-vax mailing list