[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