[Info-vax] September 6, 2016 - new Roadmap and State of the Port updates now on VSI website

[Stephen Hoffman]

On 2016-09-08 19:44:17 +0000, David Froble said:

> Ok, I'll throw out an idea here.  Not saying it's a good idea, and I'm 
> sure Steve won't like it.  Well, pretty sure.
> 
> How about two C compilers on VMS?  One for VMS users, and one aimed at 
> porting needs.
> 
> I'd assume that they would be almost identical,so common code could be 
> used in the compilers.  Don't know how difficult this would be.  Most 
> likely a John Reagan question.

I've already suggested something roughly similar, though around a means 
of retiring the existing morass.    Akin to DEC C (ANSI C) replacing 
VAX C (K&R C) and the subsequent half-baked not-really no-deadline 
retirement of K&R C code.   More than a few folks here are still 
putting up with problems that ties directly back to the older language 
standards, because nobody's made them drag their sorry source code 
forward.   Unfortunately, that reflects badly on OpenVMS.

Though I'd prefer the replacement effort be aimed at the future of 
OpenVMS software development tools and particularly around moving 
existing C source code forward, and around more quickly adopting the 
most current versions of the tools and languages and standards.    
Around deprecating old code and problem areas, and scheduling and 
removing the old areas.   Around making OpenVMS one of the best C 
environments available.   The OpenVMS C compiler used to be one of the 
best compilers around in terms of diagnostics and the detection of 
subtle coding bugs.  It's still pretty good, but the progress that 
other C compilers have been making have rendered that comparison moot.

I'd prefer this work not simply involve porting open source C code around.

Move the whole environment forward, and make the whole environment 
easier to use and more competitive.

For those cases where C has to interface with OpenVMS, it'd be nice if 
the compiler were smarter about that, too, and (for instance) dealt 
with string descriptors much more directly (this as a language 
extension).

> Not saying leave either of them in the past.  Both should be kept 
> current, and mostly logical name free.  Just saying, if what's needed 
> for porting *ix snake oil just isn't compatable with more traditional 
> VMS users, then face up to the issue and address it in some workable 
> manner.

FWIW, the C run-time — as differentiated from the compiler — does have 
a means to translate a logical name via the getenv() call.   My 
problems with logical names are around the management and maintenance 
and related problems of using logical names as a configuration and 
control mechanism, and that's not something specific to C.





-- 
Pure Personal Opinion | HoffmanLabs LLC