VAX Macro to C conversion

[and...@feeandl.com]

Hello world,

We have a pile of now quite ancient VAX MACRO code that forms part of our OpenVMS business software which we now run on Itanium. Historically we needed the performance benefits that MACRO gave us, but these days we still have performance needs, but with today's hardware we are confident that a higher level language such as C should still give the performance we need and also be easier for our non-native VMS devs to deal with.

Poking around looking for a way to move this MACRO to something slightly easier to read and manage the first hit we got was a package called XTRAN. On the surface it seems that it might be a good fit for us.

Just wondering what you folks know of this tool, or even others that might be worth our looking at.

Thanks in advance,

Andrew

[Robert A. Brooks]

On 6/23/2019 10:35 PM, and...@feeandl.com wrote:

> Just wondering what you folks know of this tool, or even others that might be
> worth our looking at.

Never heard of the tool.

How much carnal knowledge of the calling standard does your code have?

We (VSI VMS engineering) have MACRO code that we know would pretty much be
impossible to port to any other language (I'm thinking of the host-based
shadowing driver). It would need to be a complete rewrite.

I suspect John Reagan will be by with more insightful (and likely inciteful)
questions.

--
-- Rob

[Michael Moroney]

"Robert A. Brooks" <FIRST...@vmssoftware.com> writes:

>On 6/23/2019 10:35 PM, and...@feeandl.com wrote:

>> Just wondering what you folks know of this tool, or even others that might be
>> worth our looking at.

>Never heard of the tool.

>How much carnal knowledge of the calling standard does your code have?

>We (VSI VMS engineering) have MACRO code that we know would pretty much be
>impossible to port to any other language (I'm thinking of the host-based
>shadowing driver). It would need to be a complete rewrite.

Watch your language! Sh*d*w*ng is a 4 letter word! There may be children reading
this! I need garlic, crosses and a wooden stake now! And daylight!! And a silver
bullet! Oh wait, that's for Bliss-32 code, isn't it.

And besides, without sh*d*w*ng in Macro, how will John Reagan test versions
of the macro compiler to insane limits?

Seriously, I have not heard of any automated Macro to anything else translater.
In addition to VMS Engineering usefulness, it could have been useful at my last
line of work, which involved modernization of one or two hundred thousand lines
of VAX Macro code (not counting the data*), some of which was itself generated by
a PDP-11 Macro-11 to VAX Macro-32 converter).

(*) yes that is correct. Some of the data was generated in the form of Macro calls
with parameters, assembled/compiled with Macro-32, $ LINKed/NOHEADER into binary
files which were used as data by the main monster. These data files changed anywhere
from weekly to almost never.

[Ben Lambert]

On Sunday, 23 June 2019 20:27:41 UTC-7, Michael Moroney wrote:
> "Robert A. Brooks" writes:

For those that are intrigued, info on the product in question can be found here:

http://www.xtran-llc.com/xtran.html#reengrg

Including examples of VAX MACRO to C here:

http://www.xtran-llc.com/vxmcee.html

[and...@feeandl.com]

On Monday, June 24, 2019 at 12:55:40 PM UTC+10, Robert A. Brooks wrote:
>
> Never heard of the tool.
>

See the link from Ben below, that's the tool I was talking about.

> How much carnal knowledge of the calling standard does your code have?
>

Very good question.
Still getting my head around it all after only a few short months here so unable to provide a definitive answer, but I take your point. Depending on how MACROy our code is, simply "translating" it to another language could be anywhere between "relatively straightforward" to "simply not gonna happen". My gut tells me that it ought to lean more towards the "relatively straightforward" end of the spectrum - although, having said that, our program pretty much runs 100% in memory due to some extremely tight timing requirements (no dbs or file i/o for us!!) so its not beyond the realms of probability that there could be some hairy MACRO doing some of that.

> We (VSI VMS engineering) have MACRO code that we know would pretty much be
> impossible to port to any other language (I'm thinking of the host-based
> shadowing driver). It would need to be a complete rewrite.
>

I am pretty sure that's a realm that we don't need to get involved in - you guys can have that all to yourself!

> I suspect John Reagan will be by with more insightful (and likely inciteful)
> questions.

Bring it on JR !

[and...@feeandl.com]

On Monday, June 24, 2019 at 1:27:41 PM UTC+10, Michael Moroney wrote:
> (*) yes that is correct. Some of the data was generated in the form of Macro calls
> with parameters, assembled/compiled with Macro-32, $ LINKed/NOHEADER into binary
> files which were used as data by the main monster. These data files changed anywhere
> from weekly to almost never.

OK, That's nuts :-)

[and...@feeandl.com]

Thanks Ben, that's the animal in question.
I should have put that in my post.

[Simon Clubley]

On 2019-06-23, Michael Moroney <mor...@world.std.spaamtrap.com> wrote:
> "Robert A. Brooks" <FIRST...@vmssoftware.com> writes:
>
>>We (VSI VMS engineering) have MACRO code that we know would pretty much be
>>impossible to port to any other language (I'm thinking of the host-based
>>shadowing driver). It would need to be a complete rewrite.
>
> Watch your language! Sh*d*w*ng is a 4 letter word! There may be children reading
> this! I need garlic, crosses and a wooden stake now! And daylight!! And a silver
> bullet! Oh wait, that's for Bliss-32 code, isn't it.
>
> And besides, without sh*d*w*ng in Macro, how will John Reagan test versions
> of the macro compiler to insane limits?
>

Perhaps John needs to up his bounties for Macro-32 to C conversions ? :-)

How much work would be involved in a rewrite of the shadowing code in C ?

If you ever need to make major changes to the shadowing code in the future,
perhaps such an effort might be worth it ?

You could end up with a nicely modular piece of code written to current
module based standards which sounds like it would be a lot easier to
change in the future (based on some previous comments about the shadowing
code).

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

[Michael Moroney]

Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:

>How much work would be involved in a rewrite of the shadowing code in C ?

$ dir/size/grand xf72_resd$:[shadowing*.src]*.mar;

Grand total of 12 directories, 55 files, 9878 blocks.
$

This is after an automated procedure removed about 400 blocks of unused code.

(there are some duplicates in the directory tree due to how the VMS build procedure
works, but still...)

>If you ever need to make major changes to the shadowing code in the future,
>perhaps such an effort might be worth it ?

>You could end up with a nicely modular piece of code written to current
>module based standards which sounds like it would be a lot easier to
>change in the future (based on some previous comments about the shadowing
>code).

And peace in the Middle East and ending world hunger are wonderful ideas!

Right now there are two of us at VSI who know (the horrors of) the shadowing
driver. It might take us a while to convert it, especially since right now, VSI
has better uses for us. I do dread the day in a couple years, after the new file
system is out, that customers start asking to use it with shadowing...

[Jan-Erik Söderholm]

Den 2019-06-24 kl. 15:59, skrev Michael Moroney:
> Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>
>> How much work would be involved in a rewrite of the shadowing code in C ?
>
> $ dir/size/grand xf72_resd$:[shadowing*.src]*.mar;
>
> Grand total of 12 directories, 55 files, 9878 blocks.
> $
>

And how many "Records searched:" from:

$ sea/stat/win=0 xf72_resd$:[shadowing*.src]*.mar; qwertyasdfgh

?

> This is after an automated procedure removed about 400 blocks of unused code.
>
> (there are some duplicates in the directory tree due to how the VMS build procedure
> works, but still...)
>
>> If you ever need to make major changes to the shadowing code in the future,
>> perhaps such an effort might be worth it ?
>
>> You could end up with a nicely modular piece of code written to current
>> module based standards which sounds like it would be a lot easier to
>> change in the future (based on some previous comments about the shadowing
>> code).
>
> And peace in the Middle East and ending world hunger are wonderful ideas!
>
> Right now there are two of us at VSI who know (the horrors of) the shadowing
> driver. It might take us a while to convert it, especially since right now, VSI
> has better uses for us. I do dread the day in a couple years, after the new file
> system is out, that customers start asking to use it with shadowing...
>

So the new file system will not support shadowing from the start?

[Michael Moroney]

=?UTF-8?Q?Jan-Erik_S=c3=b6derholm?= <jan-erik....@telia.com> writes:

>Den 2019-06-24 kl. 15:59, skrev Michael Moroney:
>> Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>>
>>> How much work would be involved in a rewrite of the shadowing code in C ?
>>
>> $ dir/size/grand xf72_resd$:[shadowing*.src]*.mar;
>>
>> Grand total of 12 directories, 55 files, 9878 blocks.
>> $
>>

>And how many "Records searched:" from:

>$ sea/stat/win=0 xf72_resd$:[shadowing*.src]*.mar; qwertyasdfgh

>?

$ sea/stat/win=0 xf72_resd$:[shadowing*.src]*.mar; qwertyasdfgh

Files searched: 55 Buffered I/O count: 217
Records searched: 159718 Direct I/O count: 130
Characters searched: 4639981 Page faults: 24
Records matched: 0 Elapsed CPU time: 0 00:00:00.45
Lines printed: 0 Elapsed time: 0 00:00:00.97
%SEARCH-I-NOMATCHES, no strings matched
$

>So the new file system will not support shadowing from the start?

The new file system will support disks > 2TB. Shadowing doesn't, and cannot
without a lot of work.

[Jan-Erik Söderholm]

Ah OK. Well, most environments today may have their storage on some large
SAN and in that case shadowing might not be as beneficial as when you are
having separate disks.

[Simon Clubley]

On 2019-06-24, Michael Moroney <mor...@world.std.spaamtrap.com> wrote:
>=?UTF-8?Q?Jan-Erik_S=c3=b6derholm?= <jan-erik....@telia.com> writes:
>
>>Den 2019-06-24 kl. 15:59, skrev Michael Moroney:
>>> Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>>>
>>>> How much work would be involved in a rewrite of the shadowing code in C ?
>>>
>>> $ dir/size/grand xf72_resd$:[shadowing*.src]*.mar;
>>>
>>> Grand total of 12 directories, 55 files, 9878 blocks.
>>> $
>>>

Thanks.

>
>>And how many "Records searched:" from:
>
>>$ sea/stat/win=0 xf72_resd$:[shadowing*.src]*.mar; qwertyasdfgh
>
>>?
>
> $ sea/stat/win=0 xf72_resd$:[shadowing*.src]*.mar; qwertyasdfgh
>
> Files searched: 55 Buffered I/O count: 217
> Records searched: 159718 Direct I/O count: 130
> Characters searched: 4639981 Page faults: 24
> Records matched: 0 Elapsed CPU time: 0 00:00:00.45
> Lines printed: 0 Elapsed time: 0 00:00:00.97
> %SEARCH-I-NOMATCHES, no strings matched
> $
>
>
>>So the new file system will not support shadowing from the start?
>
> The new file system will support disks > 2TB. Shadowing doesn't, and cannot
> without a lot of work.

Will shadowing work on the new file system if disk sizes are kept
at 2TB or smaller ?

If so, is it viable to convert the signed values to unsigned values
to at least get the maximum disk size supported up to 4TB ?

[Simon Clubley]

On 2019-06-24, Jan-Erik Söderholm <jan-erik....@telia.com> wrote:
>
> Ah OK. Well, most environments today may have their storage on some large
> SAN and in that case shadowing might not be as beneficial as when you are
> having separate disks.
>

How do the current crop of SANs compare to HBVS and VMS clusters when
it comes to disaster recovery in a multi-site fully active shared
everything situation when one site is suddenly lost ?

[Bob Gezelter]

Andrew,

There is MACRO and there is MACRO. Converting it to C is another question. The more important question is "Converting it to maintainable C". MACRO can be obscure, as coding tricks are often subtle. FORTRAN to C is easier, it is more a question of syntax.

A full, detailed inspection of the code base is in order.

- Bob Gezelter, http://www.rlgsc.com

[Michael Moroney]

Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:

>Will shadowing work on the new file system if disk sizes are kept
>at 2TB or smaller ?

It will need to be taught lots of things. Whether that will happen or not I
cannot say.

>If so, is it viable to convert the signed values to unsigned values
>to at least get the maximum disk size supported up to 4TB ?

A project to update many file system components, including shadowing, from 1TB to
2TB (not 2 to 4TB) capacity by making LBN/VPN references unsigned happened some time
ago.

[Dave Froble]

I'd guess, in such an environment, in Macro-32, that signed intergers
are not used. But what do I know.


--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: da...@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

[Simon Clubley]

On 2019-06-24, Michael Moroney <mor...@world.std.spaamtrap.com> wrote:

Oops, yes you are correct. :-(

I was thinking of the values involved in the 32-bit byte boundary
transitions (2GB to 4GB) for some stupid reason instead of the
32-bit block boundary transitions (1TB to 2TB). :-(

Sorry. :-)

[Simon Clubley]

Actually, there has traditionally been a problem with signed integers
used in some data structures where unsigned integers would be better.

The real problem here however was that I was stupidly thinking about
the values involved in the byte level boundaries (from 2GB to 4GB)
instead of the values involved in block level boundaries (from 1TB to 2TB).

[Stephen Hoffman]

Haven't used XTRAN, nor seen its output. I've heard apocryphal tales,
but no details. First heard of it from Keith Cayemberg, back some 15
years ago.

Source code conversion has been possible for quite some time.

But the output of most of the automated-conversion converted code
around has itself been somewhere less than maintainable.

And some Macro32 source code can be more complex than a translation
tool might permit. OpenVMS has some of that, as is being discussed
else-thread.

It's only been recently that automated refactoring of source code has
gotten pretty good, and whether that's even available here, or can work
with this particular C output?

One common path for these is to have developers convert each module as
any substantial modifications are required.


--
Pure Personal Opinion | HoffmanLabs LLC

[Stephen Hoffman]

On 2019-06-24 18:10:34 +0000, Dave Froble said:

> I'd guess, in such an environment, in Macro-32, that signed intergers
> are not used. But what do I know.

The Macro32 compiler does signed and unsigned just fine, and has
"instructions" for both.
The issue here is that VBNs and LBNs are typically stored as
longwords—all over the place in OpenVMS and in apps—and attempts to
reference VBN and LBN addresses past 32 bits / 2 TiB won't fit, and are
best suited for a quadword.
The 1 TiB to 2 TiB transition was fixing sign-handling. Not extending
the storage from longword to quadword.
This being a case of trying to fit 33 or 34 or 35 bits of storage
address data into an existing and 32-bit buffer.
The alternative approach here being a shift from the existing 512-byte
sectors into 4096 "Advanced Format" "4K native" storage sector sizes,
but that'll cause ripples elsewhere in OpenVMS and in app source code.
https://en.wikipedia.org/wiki/Advanced_Format
Welcome to compatibility.

[John Reagan]

There has been a discussion about using signed integers in the LLVM source with a limited exceptions for unsigned when discussion bitfields.

For the junior language lawyers in the crowd, go watch

https://www.youtube.com/watch?v=wvtFGa6XJDU

If that 6 minutes wasn't enough, then go spend an entire hour with

https://www.youtube.com/watch?v=yG1OZ69H_-o

(skip to 33:26 for a real fun bug)

I'll respond to the OP's questions next.

[John Reagan]

On Monday, June 24, 2019 at 1:48:07 AM UTC-4, Andrew Shaw wrote:

>
> > I suspect John Reagan will be by with more insightful (and likely inciteful)
> > questions.
>
> Bring it on JR !

You rang? [If you mention my name three times, I have to appear.]

I think you are asking two different questions:

#1) I'm looking for a conversion tool due to possible performance issues and programmer knowledge issues, have you heard of XTRAN?

#2) Does using VAX Macro-32 limit performance versus coding in C (or any other language)


#1) Conversion and XTRAN

Yes, I know XTRAN and Stephen Heffner. The compiler group talked with Stephen years about about a tool to convert stuff to C. I think the interest at the time was mainly with BLISS to C, but we also discussed Macro-32 to C and Pascal to C. XTRAN at the time only had limited success on the examples we provided. For Macro-32, the problem areas were routines that jumped into each other and trying to come up with some reasonable symbolization. For cross-jumpers, the generated C had routines with argument lists of (R0, R1, R2, R3, etc.). For naming of register-based variables, it was tricky some the code might have used R0 for a "length", then a "pointer", then a "length" again. In a well-written C program <insert joke here>, you would use three variables and let the compiler optimize it. I'm sure that XTRAN has matured in since then so you should confirm current behavior with them.

You'll have to decide whether you have well-written Macro-32 code (XTRAN tries to propagate comments) and you can spend the time to "clean up" the generated C code OR if you have horribly commented Macro-32 code with an obscure algorithm and you can spend lots more time to figure it all out and work in the C code.

#2) What does Macro-32 cost me?

For straight line code, the Macro compilers (AMACRO, IMACRO, and XMACRO) all generate reasonable dense code. We even spend effort to leverage the x86-64 condition code flags and indexed addressing modes.

On Alpha and Itanium, the compiler leverages GEM's instruction peepholer and scheduler. Given the internal design of LLVM at the "assembler interface", we are past LLVM's scheduler. However, I'd claim that with the internal design of current x86-64 chips has huge out of order windows (Ice Lake can have 352 in flight with 128 loads in flight and 72 stores in flight) that instruction level ordering isn't as important anymore. The chips seem to do it (ignoring all the side-channel Spectre-like data leakage) for us. There

On x86, we'll also be using memory locations to hold the Alpha register state but fast L1/L2 cache comes to the rescue. Even if you rewrote into C, LLVM will end up with some variables on the stack. Heck, in 32-bit mode, you only have 8 registers available (and some have predefined behavior) so 32-bit Linux and 32-bit Windows systems have been relying on fast cache for stack-based variables for ever.

What you really don't get for Macro-32 is higher level optimizations such as loop unrolling, hoisting expressions out of loops (Macro will attempt to hoist some address computations), routine inline expansion (Itanium has big call overhead, Alpha and x86 a small call overhead). Plus Macro is horrible if you are using floating point that originated on VAX. Modern clang/LLVM can do a good job at using parallel vector instructions where as XMACRO will not.

So we think that Macro-32 on x86-64 will be just as "reasonable" as it was in the past. There will be added memory loads/stores to manage the Alpha register vector (we are looking at some techniques to save repeated loads but deferring stores has implications for unwind and debug information) but looking back, it could have been worse. :)

[Andrew Shaw]

On Tuesday, June 25, 2019 at 3:47:17 AM UTC+10, Bob Gezelter wrote:

>
> Andrew,
>
> There is MACRO and there is MACRO. Converting it to C is another question. The more important question is "Converting it to maintainable C". MACRO can be obscure, as coding tricks are often subtle. FORTRAN to C is easier, it is more a question of syntax.
>
> A full, detailed inspection of the code base is in order.
>

Hi Bob,

Very true. I'm only quite new to this organisation (but not new to VMS !!) so am still getting my head around what we have here. I am a long way from being an expert in MACRO-32 so it will take me a bit of time to understand how big this problem is.

I expect that I can quite quickly get a handle on how much MACRO code there is, but as you point out the more interesting question is what sort of MACRO code is it? What clever tricks does it do? This is effort that I am going to need to spend and I certainly don't expect any tool to magically do all this for me and anything we do do will need to be tested to within a millimetere of its life (an inch won't be anywhere near close enough!!)

[Andrew Shaw]

On Tuesday, June 25, 2019 at 5:03:22 AM UTC+10, Stephen Hoffman wrote:

Hi Stephen,

>
> But the output of most of the automated-conversion converted code
> around has itself been somewhere less than maintainable.

I appreciate that this is a very real issue that we are going to have to address. Frankly I don't really see the point doing any conversion whether it be assisted by a tool or completely manual if the end result is difficult to maintain. In that scenario I'd be inclined to leave it where it is.

>
> And some Macro32 source code can be more complex than a translation
> tool might permit. OpenVMS has some of that, as is being discussed
> else-thread.
>

This is also true and for this I am going to have to do some deeper analysis of the code (as has been pointed out by others in here) in order to understand the subtleties of what is going on - hopefully get an understanding of why it was written in MACRO in the first place. Our system is a curious mix of languages - MACRO-32, C, FORTRAN and RATFOR forms the bulk of the system code. Recent ancilliary / supporting scripts have started appearing in PYTHON as well. As have many existing VMS systems today we have gone through the usual lifecycle of VAX --> ALPHA --> IA64. We do have some extremely time-sensitive requirements in certain aspects of our code (which all runs in memory) and my gut feel is that the MACRO code exists in an effort to streamline those time sensitive bits, but I need to deep dive into that more.

> One common path for these is to have developers convert each module as
> any substantial modifications are required.
>

This is the approach I am trying to get some momentum behind. Any time we need to lift the lid on any MACRO code we turn it into C. I guess here I am exploring what tools may exist to help us get that done, rather than just blindly let the tool do it for us. I'm not sure a wholesale migration of all MACRO code to C (or FORTRAN or something else) is necessarily a good approach. I'm a firm believer in the "If it ain't broke don't fix it" approach. And the code does work today. Its worked for close to 30 years.

[Stephen Hoffman]

On 2019-06-24 23:43:45 +0000, Andrew Shaw said:

> ...This is also true and for this I am going to have to do some deeper

> analysis of the code (as has been pointed out by others in here) in
> order to understand the subtleties of what is going on - hopefully get
> an understanding of why it was written in MACRO in the first place. Our
> system is a curious mix of languages - MACRO-32, C, FORTRAN and RATFOR

> forms the bulk of the system code...

The use of RATFOR here implies this is an older code-base and/or
long-established developers, but that combination of languages is
otherwise not particularly unusual.

It's fairly common to find that much of the existing Macro32 code can
be replaced with rather less C or C++ code, and/or by making calls to
now-available system service calls or features. Or a combination.

There's a lot of Macro32 around that largely exists for historical
reasons and organizational inertia. "It works" is a strong contributor
toward "doing nothing".

More than a little of the Macro32 was implemented as workarounds for
features or APIs that were then-missing, or for APIs that were not
easily callable.

Where folks get in trouble with Macro32 is when Macro32 was used for
the last few crumbs of system performance and/or of memory usage. Or
when the developers were too clever. Or a combination.

Whether separately or as a prolog to the source code conversions, I'd
look at adding instrumentation and debugging into the app, and at
enabling and cranking up the now-available compiler diagnostics. If
you've VAX C code lurking, switch that all over to C99.

Starting a source code conversion with latent bugs and/or insufficient
test coverage and/or poor telemetry and/or little or no documentation
(q.v. doxygen) is not fun. (n.b. I'm not aware of a doxygen port for
OpenVMS, but it does exist for most other platforms.)

[Andrew Shaw]

On Tuesday, June 25, 2019 at 7:07:42 AM UTC+10, John Reagan wrote:

> On Monday, June 24, 2019 at 1:48:07 AM UTC-4, Andrew Shaw wrote:
>
>
> You rang? [If you mention my name three times, I have to appear.]

I only mentioned it once - you're running ahead of schedule !!!

>
> I think you are asking two different questions:

I think that's probably an accurate read !

>
> #1) I'm looking for a conversion tool due to possible performance issues and programmer knowledge issues, have you heard of XTRAN?
>

I would modify this slightly to be: "I'm looking for a conversion tool due almost exclusively to programmer knowledge issues".

We have no performance issues (that I am aware of) today, even with the sub-second timing requirements that we have in many areas of our code. (That sub second is for new/changed data to travel across a continent of similar size to mainland USA, but with far less comms infrastructure) over the intywebs to update our in memory VMS hosts. This we manage to achieve. The concern I have is with our ability as a (mostly quite young) dev team to manage the Macro code which is unfamiliar to the vast majority of our team.

> #2) Does using VAX Macro-32 limit performance versus coding in C (or any other language)

I am actually pretty confident, as I hinted above, that we don't have any (that I have noticed yet) performance issue due to the fact that some of our code is MACRO. Again, being fairly new to this organisation I am obviously not intimate with the long history our system has had, but it did start life a couple of decades ago on a VAX of some description and since then has travelled the well worn path of VAX --> AXP --> IA64. Possibly onward to X86, that part of the future isn't clear yet, but I'm putting $5 down that says its gonna be on our radar sometime sooner than management are expecting !

From your comments here it is pretty clear to me that lots of good work has been done and is continuing to be done in the MACRO32 space and I have no fear of our code getting unusable in the near future. I am quite sure it will run happily for years to come without needing to be touched.

The situation I am trying to alleviate is that we now have a healthy development pipeline of work due to some regulatory changes in our industry in recent years and the opening up of the market that mean that we are going to need to be able to make enhancements to this MACRO code for the forseeable future. I guess this thread was me thinking out loud and wondering if we can make our lives easier by moving this code to something easier to understand and maintain.

The correct feedback has already come here along the lines of "Andrew, you need an understanding of your current MACRO code in order to assess the effort and risk of porting it versus leaving it alone and maintaining it in situ." That is good feedback and is obviously work I need to do. Realistically I wouldn't expect any tool to simply pick up our code and spit out perfectly structured and maintainable C (or FORTRAN or something else). I think the best I can hope for is that *if* our MACRO is reasonably simple and not overly clever, then I am hoping it is conceivable that a tool *might* be able to get us say 60% of the way there and we then follow that up with refactoring and rigorous testing etc.

Thanks for your feedback John - Insightful as always and not at all inciteful :-)

[Andrew Shaw]

On Tuesday, June 25, 2019 at 9:59:37 AM UTC+10, Stephen Hoffman wrote:
>
> The use of RATFOR here implies this is an older code-base and/or
> long-established developers, but that combination of languages is
> otherwise not particularly unusual.

This is definitely an older code-base rather than established devs. Probably been around since approx 1980 - ish. (Not at work now so can't confirm, but that's about right). All the original Devs are long gone. Current "veteran" has been on it for just shy of 20 years. Rest of us are 2-3 years or less here - I'm probably the longest serving VMS guy here now, most of the others are newcomers to this world.

>
> It's fairly common to find that much of the existing Macro32 code can
> be replaced with rather less C or C++ code, and/or by making calls to
> now-available system service calls or features. Or a combination.

This is a really good point and I like it. My gut tells me that a lot of our Macro will be doing just that. I suspect that a lot can be replaced with a fairly simple high level call nowadays that today's compilers can then optimise to their hearts content and we may wind up with code more efficient and quicker than the Macro. But at this stage that is purely guesswork and more digging is needed from me to either prove or disprove that.

>
> There's a lot of Macro32 around that largely exists for historical
> reasons and organizational inertia. "It works" is a strong contributor
> toward "doing nothing".

That's strong here. We know it works, we don't need to touch it, we don't want to mess with it - leave it alone.

>
> More than a little of the Macro32 was implemented as workarounds for
> features or APIs that were then-missing, or for APIs that were not
> easily callable.

Yup, see above comments. I suspect we have a fair bit of this.

>
> Where folks get in trouble with Macro32 is when Macro32 was used for
> the last few crumbs of system performance and/or of memory usage. Or
> when the developers were too clever. Or a combination.

I'm not going to say we don't have this, because I don't know yet.

>
> Whether separately or as a prolog to the source code conversions, I'd
> look at adding instrumentation and debugging into the app, and at
> enabling and cranking up the now-available compiler diagnostics. If
> you've VAX C code lurking, switch that all over to C99.

Another excellent suggestion and one my colleague and I arrived at separately in a conversation we had only this morning. I think there is some preliminary analysis that we can knock up which will help put a shape and size around this "problem". There is a chance some/a lot of our Macro code is now superceded and not used anymore and in that case I am trying to solve a problem I may not actually have. So I really do think trying to dimension it first is smart.

>
> Starting a source code conversion with latent bugs and/or insufficient
> test coverage and/or poor telemetry and/or little or no documentation
> (q.v. doxygen) is not fun. (n.b. I'm not aware of a doxygen port for
> OpenVMS, but it does exist for most other platforms.)
>

I wasn't aware of doxygen until now. My colleague was and suggested that if push came to shove we could potentially copy the code to a Windows or Linux machine somewhere and run doxygen over it from there. Not sure how feasible that is though - again, a bit more digging needed on my part.

[Bill Gunshannon]

On 6/24/19 7:59 PM, Stephen Hoffman wrote:
> On 2019-06-24 23:43:45 +0000, Andrew Shaw said:
>
>> ...This is also true and for this I am going to have to do some deeper
>> analysis of the code (as has been pointed out by others in here) in
>> order to understand the subtleties of what is going on - hopefully get
>> an understanding of why it was written in MACRO in the first place.
>> Our system is a curious mix of languages - MACRO-32, C, FORTRAN and
>> RATFOR forms the bulk of the system code...
>
> The use of RATFOR here implies this is an older code-base and/or
> long-established developers, but that combination of languages is
> otherwise not particularly unusual.

You thought RATFOR meant an older codebase than FORTRAN? :-)

>
> It's fairly common to find that much of the existing Macro32 code can be
> replaced with rather less C or C++ code, and/or by making calls to
> now-available system service calls or features.  Or a combination.
>
> There's a lot of Macro32 around that largely exists for historical
> reasons and organizational inertia.  "It works" is a strong contributor
> toward "doing nothing".
>
> More than a little of the Macro32 was implemented as workarounds for
> features or APIs that were then-missing, or for APIs that were not
> easily callable.
>
> Where folks get in trouble with Macro32 is when Macro32 was used for the
> last few crumbs of system performance and/or of memory usage.  Or when
> the developers were too clever. Or a combination.
>
> Whether separately or as a prolog to the source code conversions, I'd
> look at adding instrumentation and debugging into the app, and at
> enabling and cranking up the now-available compiler diagnostics.  If
> you've VAX C code lurking, switch that all over to C99.
>
> Starting a source code conversion with latent bugs and/or insufficient
> test coverage and/or poor telemetry and/or little or no documentation
> (q.v. doxygen) is not fun.  (n.b. I'm not aware of a doxygen port for
> OpenVMS, but it does exist for most other platforms.)
>

Do any of the VMS C Compilers have the equivalent of -S in most
Unix C Compilers? I would love to see a few simple programs
(starting with "Hello World") written in Macro, converted to C
and then compiled with the option to list the assembler just to
see how they compared. :-)

bill

[John Reagan]

On Tuesday, June 25, 2019 at 10:32:13 AM UTC-4, Bill Gunshannon wrote:

>
> Do any of the VMS C Compilers have the equivalent of -S in most
> Unix C Compilers? I would love to see a few simple programs
> (starting with "Hello World") written in Macro, converted to C
> and then compiled with the option to list the assembler just to
> see how they compared. :-)
>
> bill

Not currently. LLVM provides that feature and our current internal cross-compilers have a /SWITCH=ASSEMBLY qualifier that causes a ".s" file to be written instead of an ".obj" file. In theory, you should be able to turn around and assemble that file (using the LLVM llvm-mc tool) to get the identical ".obj" file. I did that a few times in the past month or so and it seemed to work.

However, on OpenVMS, ANALYZE/OBJECT/DISASSEMBLE is the equivalent of what objdump would give you on a Linux system. (There is also an llvm-objdump equivalent tool that we'll provide too). That just gives you the code but is lacking for static data initialization, etc. You have to get that from the Alpha or Itanium compiler listings.

[Stephen Hoffman]

On 2019-06-25 16:09:32 +0000, John Reagan said:

> On Tuesday, June 25, 2019 at 10:32:13 AM UTC-4, Bill Gunshannon wrote:
>>
>> Do any of the VMS C Compilers have the equivalent of -S in most Unix C
>> Compilers? I would love to see a few simple programs (starting with
>> "Hello World") written in Macro, converted to C and then compiled with
>> the option to list the assembler just to see how they compared.

The existing CC /SHOW=MACHINE_CODE support will provide a fair
approximation of the request here, at least for the purposes of
examining the generated code.

See pages 49 to 51 of the fine manual for details:
https://vmssoftware.com/docs/VSI_OpenVMS_BaseOS/5492_c_users_gd.pdf

> Not currently. LLVM provides that feature and our current internal
> cross-compilers have a /SWITCH=ASSEMBLY qualifier that causes a ".s"
> file to be written instead of an ".obj" file. In theory, you should be
> able to turn around and assemble that file (using the LLVM llvm-mc
> tool) to get the identical ".obj" file. I did that a few times in the
> past month or so and it seemed to work.

There are all sorts of interesting back-ends available for LLVM too,
and not the least of which is Emscripten.

> However, on OpenVMS, ANALYZE/OBJECT/DISASSEMBLE is the equivalent of
> what objdump would give you on a Linux system. (There is also an
> llvm-objdump equivalent tool that we'll provide too). That just gives
> you the code but is lacking for static data initialization, etc. You
> have to get that from the Alpha or Itanium compiler listings.

Is there an ANALYZE/IMAGE/DISASSEMBLE planned, too? objdump can
provide that with ELF executable files on some platforms. Otherwise
we're porting libbfd or efitools or bintools.



ps: Bill: most of the places I've encountered that were or are still
using Ratfor and the rest of FORTRAN 66-era FORTRAN "fun" are usually
still using F66 constructs, and haven't migrated or haven't completed a
migration forward to FORTRAN 77 and/or to Ratfiv (FORTRAN 77 era), or
preferably to more recent Fortran constructs. Migrating F66 and F77
source code to the now ~thirty year old F90, or to the less-old F95, or
preferably to Fortran-from-this-millennium if/when that's available can
be a tedious slog, too. But then I've occasionally misread the recent
FF7-related reboot chatter as F77 chatter, too. But then I re-read it
and remember that FF7 is one of many things far more interesting than
F77 and ~forty year old and oft-under-maintained FORTRAN code.

[Arne Vajhøj]

On 6/25/2019 12:09 PM, John Reagan wrote:
> On Tuesday, June 25, 2019 at 10:32:13 AM UTC-4, Bill Gunshannon wrote:
>> Do any of the VMS C Compilers have the equivalent of -S in most
>> Unix C Compilers? I would love to see a few simple programs
>> (starting with "Hello World") written in Macro, converted to C
>> and then compiled with the option to list the assembler just to
>> see how they compared. :-)

> Not currently. LLVM provides that feature and our current internal
> cross-compilers have a /SWITCH=ASSEMBLY qualifier that causes a ".s"
> file to be written instead of an ".obj" file. In theory, you should
> be able to turn around and assemble that file (using the LLVM llvm-mc
> tool) to get the identical ".obj" file. I did that a few times in
> the past month or so and it seemed to work.
> However, on OpenVMS, ANALYZE/OBJECT/DISASSEMBLE is the equivalent of
> what objdump would give you on a Linux system. (There is also an
> llvm-objdump equivalent tool that we'll provide too). That just
> gives you the code but is lacking for static data initialization,
> etc. You have to get that from the Alpha or Itanium compiler
> listings.

$ PAS/LIST/MACH ...

should reveal some things. Just not directly compilable.

Arne

[John Reagan]

On Tuesday, June 25, 2019 at 7:33:48 PM UTC-4, Stephen Hoffman wrote:

>
> Is there an ANALYZE/IMAGE/DISASSEMBLE planned, too? objdump can
> provide that with ELF executable files on some platforms. Otherwise
> we're porting libbfd or efitools or bintools.
>

Already done.

PASCAL$ type hw.pas
program hw(output);
begin
writeln('hello world');
end.
PASCAL$ pascal hw.pas
PASCAL$ anal/obj/disa hw.obj
Analyze/Disassemble Object File 25-JUN-2019 20:47:59.63 Page
1
WORK20:[JREAGAN]HW.OBJ;4
ANALYZ I01-73

HW Machine Code Listing 25-Jun-2019 20:47 VSI Pascal x86-64 X6.3
-001
01 HW

.section $CODE$, "ax", "progbits" # EXE,SHR
.align 16
Section size 87 bytes

ELF$TFRADR::
HW:
55 00000000: pushq %rbp
# 000001
E5 89 48 00000001: movq %rsp,%rbp
10 EC 83 48 00000004: subq $10,%rsp
00 00 00 00 00 00 00 01 B8 48 00000008: movq $0000000000000001,%rax
00 00 00 00 0D 8B 48 00000012: movq PAS$FV_OUTPUT@GOTPCREL(%rip),%rcx
00 00 00 00 00 00 00 0B BE 48 00000019: movq $000000000000000B,%rsi
00 00 00 00 15 8B 48 00000023: movq .L.sym1@GOTPCREL(%rip),%rdx
CF 89 48 0000002A: movq %rcx,%rdi
# 000003
F8 45 89 48 0000002D: movq %rax,-08(%rbp)
00 00 00 00 B8 00000031: movl $00000000,%eax
F0 4D 89 48 00000036: movq %rcx,-10(%rbp)
00 00 00 00 E8 0000003A: callq PAS$WRITE_STRING@PLT
F0 7D 8B 48 0000003F: movq -10(%rbp),%rdi
00 00 00 00 B8 00000043: movl $00000000,%eax
00 00 00 00 E8 00000048: callq PAS$WRITELN2@PLT
F8 45 8B 48 0000004D: movq -08(%rbp),%rax
# 000004
10 C4 83 48 00000051: addq $10,%rsp
5D 00000055: popq %rbp
C3 00000056: retq

and

PASCAL$ objdump --version
LLVM (http://llvm.org/):
LLVM version 3.4.2
DEBUG build with assertions.
Built May 9 2018 (14:34:01).
Default target: x86_64-pc-linux-gnu
Host CPU: (unknown)

Registered Targets:
x86 - 32-bit X86: Pentium-Pro and above
x86-64 - 64-bit X86: EM64T and AMD64

PASCAL$ objdump -d hw.obj

hw.obj: file format ELF64-x86-64

Disassembly of section .text:
.text:
Disassembly of section $CODE$:
HW:
0: 55 pushq %rbp
1: 48 89 e5 movq %rsp, %rbp
4: 48 83 ec 10 subq $16, %rsp
8: 48 b8 01 00 00 00 00 00 00 00 movabsq $1, %rax
12: 48 8b 0d 00 00 00 00 movq (%rip), %rcx
19: 48 be 0b 00 00 00 00 00 00 00 movabsq $11, %rsi
23: 48 8b 15 00 00 00 00 movq (%rip), %rdx
2a: 48 89 cf movq %rcx, %rdi
2d: 48 89 45 f8 movq %rax, -8(%rbp)
31: b8 00 00 00 00 movl $0, %eax
36: 48 89 4d f0 movq %rcx, -16(%rbp)
3a: e8 00 00 00 00 callq 0
3f: 48 8b 7d f0 movq -16(%rbp), %rdi
43: b8 00 00 00 00 movl $0, %eax
48: e8 00 00 00 00 callq 0
4d: 48 8b 45 f8 movq -8(%rbp), %rax
51: 48 83 c4 10 addq $16, %rsp
55: 5d popq %rbp
56: c3 ret

[hb]

On 6/26/19 1:33 AM, Stephen Hoffman wrote:
> Is there an ANALYZE/IMAGE/DISASSEMBLE planned, too?  objdump can provide
> that with ELF executable files on some platforms.  Otherwise we're
> porting libbfd or efitools or bintools.

Dunno what you expect. ANALYZE/IMAGE/SEGMENT=CODE disassembles the code
segments (similar to ANALYZE/OBJECT/SECTION=CODE).
ANALYZE/OBJECT/DISASSEMBLE uses the symbol table to symbolize the
disassembled sections. There are no symbols in main images and there may
not be any symbol in a shareable image. On Linux "objdump -d" of a main
"image" symbolizes the code SECTIONS, which overmap the code segments
using the symbol table. The VMS linker does not set up code sections in
an image.

[Stephen Hoffman]

On 2019-06-26 09:14:10 +0000, hb said:

> On 6/26/19 1:33 AM, Stephen Hoffman wrote:
>> Is there an ANALYZE/IMAGE/DISASSEMBLE planned, too?  objdump can
>> provide that with ELF executable files on some platforms.  Otherwise
>> we're porting libbfd or efitools or bintools.
>
> Dunno what you expect.

I don't expect Ghidra here, but it'd be nice.

[seasoned_geek]

On Monday, June 24, 2019 at 7:39:07 AM UTC-5, Simon Clubley wrote:
>
> How much work would be involved in a rewrite of the shadowing code in C ?
>

Careful there. You are forgetting the C compiler is roughly 2 decades behind in standards and capabilities.

[Michael Moroney]

Out-of-date C compilers would be the least of the problems with such a
rewrite.

[Simon Clubley]

Yes, but if you were implementing something like this from scratch
these days, you would use C instead of Macro-32 simply because of
all the major advantages C brings you, even with an old compiler.

And before all you Macro-32 lovers jump on me for that comment, :-)
remember that times change and for good reason.

I understand why huge amounts of VMS were written in Macro-32 back
in the 1970s and why it was probably the correct choice for that era.

It doesn't mean it's the right choice however if you were to do VMS
from scratch in the 21st century, or even if you were to do any new
significant additions to the existing VMS codebase.

[Dave Froble]

On 7/8/2019 8:58 PM, Simon Clubley wrote:
> On 2019-07-08, Michael Moroney <mor...@world.std.spaamtrap.com> wrote:
>> seasoned_geek <rol...@logikalsolutions.com> writes:
>>
>>> On Monday, June 24, 2019 at 7:39:07 AM UTC-5, Simon Clubley wrote:
>>>>
>>>> How much work would be involved in a rewrite of the shadowing code in C ?
>>>>
>>
>>> Careful there. You are forgetting the C compiler is roughly 2 decades behind in
>>> standards and capabilities.
>>
>> Out-of-date C compilers would be the least of the problems with such a
>> rewrite.
>
> Yes, but if you were implementing something like this from scratch
> these days, you would use C instead of Macro-32 simply because of
> all the major advantages C brings you, even with an old compiler.
>
> And before all you Macro-32 lovers jump on me for that comment, :-)
> remember that times change and for good reason.
>
> I understand why huge amounts of VMS were written in Macro-32 back
> in the 1970s and why it was probably the correct choice for that era.
>
> It doesn't mean it's the right choice however if you were to do VMS
> from scratch in the 21st century, or even if you were to do any new
> significant additions to the existing VMS codebase.
>
> Simon.
>

Macro-32 is an assembler on the VAX. On Alpha, itanic, and x86 is is a
compiled language, and not anything you'd want to use on the non-VAX
systems. Just ask John. It exists strictly for existing code.

However, if your target was a VAX, (not available anymore), it might be
a viable choice, or not.

[Michael Moroney]

Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:

>On 2019-07-08, Michael Moroney <mor...@world.std.spaamtrap.com> wrote:
>> seasoned_geek <rol...@logikalsolutions.com> writes:
>>
>>>On Monday, June 24, 2019 at 7:39:07 AM UTC-5, Simon Clubley wrote:
>>>>
>>>> How much work would be involved in a rewrite of the shadowing code in C ?
>>>>
>>
>>>Careful there. You are forgetting the C compiler is roughly 2 decades behind in
>>>standards and capabilities.
>>
>> Out-of-date C compilers would be the least of the problems with such a
>> rewrite.

>Yes, but if you were implementing something like this from scratch
>these days, you would use C instead of Macro-32 simply because of
>all the major advantages C brings you, even with an old compiler.

My comment was regarding how truly evil the Macro-32 shadowing code is, not the
merits of conversion of Macro to C or anything else.

New or significantly rewritten VMS code for x86 is almost always in C, with the
exception of extremely specific code is in x86 assembler like SWIS/interrupt code.

[Simon Clubley]

On 2019-07-08, Dave Froble <da...@tsoft-inc.com> wrote:
>
> Macro-32 is an assembler on the VAX. On Alpha, itanic, and x86 is is a
> compiled language, and not anything you'd want to use on the non-VAX
> systems. Just ask John. It exists strictly for existing code.
>

It's nothing to do with whether it's an assembler or a compiler.

It's to do with the fact that assembly language is so low level
and error prone even when compared to C.

> However, if your target was a VAX, (not available anymore), it might be
> a viable choice, or not.
>

These days, the only thing anyone uses assembly language for in
new code are the small segments which cannot be coded even in C.

[seasoned_geek]

On Monday, July 8, 2019 at 7:24:50 PM UTC-5, Michael Moroney wrote:
>
> Out-of-date C compilers would be the least of the problems with such a
> rewrite.

Not really, no. The current C compiler makes Macro-32 seem high level.

[John Reagan]

On Monday, July 8, 2019 at 11:12:43 PM UTC-4, Dave Froble wrote:
> On 7/8/2019 8:58 PM, Simon Clubley wrote:

> > On 2019-07-08, Michael Moroney <> wrote:

> >> seasoned_geek <> writes:
> >>
> >>> On Monday, June 24, 2019 at 7:39:07 AM UTC-5, Simon Clubley wrote:
> >>>>
> >>>> How much work would be involved in a rewrite of the shadowing code in C ?
> >>>>
> >>
> >>> Careful there. You are forgetting the C compiler is roughly 2 decades behind in
> >>> standards and capabilities.
> >>
> >> Out-of-date C compilers would be the least of the problems with such a
> >> rewrite.
> >
> > Yes, but if you were implementing something like this from scratch
> > these days, you would use C instead of Macro-32 simply because of
> > all the major advantages C brings you, even with an old compiler.
> >
> > And before all you Macro-32 lovers jump on me for that comment, :-)
> > remember that times change and for good reason.
> >
> > I understand why huge amounts of VMS were written in Macro-32 back
> > in the 1970s and why it was probably the correct choice for that era.
> >
> > It doesn't mean it's the right choice however if you were to do VMS
> > from scratch in the 21st century, or even if you were to do any new
> > significant additions to the existing VMS codebase.
> >
> > Simon.
> >
>
> Macro-32 is an assembler on the VAX. On Alpha, itanic, and x86 is is a
> compiled language, and not anything you'd want to use on the non-VAX
> systems. Just ask John. It exists strictly for existing code.
>

I wouldn't say that. The generated code from AMACRO and IMACRO is pretty reasonable. You don't get things like "inlining", "loop unrolling", and other higher level optimizations, but the actual code for each VAX instruction is pretty good. Currently for x86, I'd say I'm mostly pleased with the generated code but we have some ideas to improve it a little more before the 9.2 release.

[On Alpha/Itanium, we interface into GEM *BEFORE* the peephole optimizer. On x86/LLVM, the assembler interface is after any scheduling and there is no equivalent peephole optimizer to help remove things like "jumps to jumps" so we'll have to do that ourselves.]

[Dave Froble]

On 7/9/2019 3:08 AM, Simon Clubley wrote:
> On 2019-07-08, Dave Froble <da...@tsoft-inc.com> wrote:
>>
>> Macro-32 is an assembler on the VAX. On Alpha, itanic, and x86 is is a
>> compiled language, and not anything you'd want to use on the non-VAX
>> systems. Just ask John. It exists strictly for existing code.
>>
>
> It's nothing to do with whether it's an assembler or a compiler.
>
> It's to do with the fact that assembly language is so low level
> and error prone even when compared to C.

One might argue that "low level" maybe has less chance for errors.

One might also argue that C is rather prone to errors.

>> However, if your target was a VAX, (not available anymore), it might be
>> a viable choice, or not.
>>
>
> These days, the only thing anyone uses assembly language for in
> new code are the small segments which cannot be coded even in C.

"anyone" ??????

It is rather amusing when people state their personal opinions as
universal. Can I then claim Basic as the best language to use?

[John Reagan]

On Tuesday, July 9, 2019 at 12:15:48 AM UTC-4, Michael Moroney wrote:
> Simon Clubley <> writes:
>
> >On 2019-07-08, Michael Moroney <> wrote:

> >> seasoned_geek <> writes:
> >>
> >>>On Monday, June 24, 2019 at 7:39:07 AM UTC-5, Simon Clubley wrote:
> >>>>
> >>>> How much work would be involved in a rewrite of the shadowing code in C ?
> >>>>
> >>
> >>>Careful there. You are forgetting the C compiler is roughly 2 decades behind in
> >>>standards and capabilities.
> >>
> >> Out-of-date C compilers would be the least of the problems with such a
> >> rewrite.
>
> >Yes, but if you were implementing something like this from scratch
> >these days, you would use C instead of Macro-32 simply because of
> >all the major advantages C brings you, even with an old compiler.
>
> My comment was regarding how truly evil the Macro-32 shadowing code is, not the
> merits of conversion of Macro to C or anything else.
>
> New or significantly rewritten VMS code for x86 is almost always in C, with the
> exception of extremely specific code is in x86 assembler like SWIS/interrupt code.

The shadow driver has its own home-made "threading" package. Plus almost every routine can possible jump into the middle of another routine. So you can enter through the prologue of routine "A", jump into "B", conditionally jump into "C" and exit through one of several epilogues. The Macro compiler has to keep lots of breadcrumbs so the epilogues will restore the right values to the right registers. That would all be difficult to mechanically translate into C (or anything else). It would require algorithm changes. The current design is best suited for an "assembler-style" language that supports such things.

[Robert A. Brooks]

All this interest in the shadowing driver makes me want to do
the interpretive BLISS dance (the shadowing ACP is written in BLISS).

As Mike and John are well aware, we have no plans to investigate the
rewriting of the Shadowing driver into C.

While I do not speak for management, I can say with extreme
confidence that the shadowing driver will never be rewritten
in another language.

--

-- Rob

[Arne Vajhøj]

On 7/8/2019 11:13 PM, Dave Froble wrote:
> On 7/8/2019 8:58 PM, Simon Clubley wrote:
>> I understand why huge amounts of VMS were written in Macro-32 back
>> in the 1970s and why it was probably the correct choice for that era.
>>
>> It doesn't mean it's the right choice however if you were to do VMS
>> from scratch in the 21st century, or even if you were to do any new
>> significant additions to the existing VMS codebase.
>

> Macro-32 is an assembler on the VAX.  On Alpha, itanic, and x86 is is a
> compiled language, and not anything you'd want to use on the non-VAX
> systems.  Just ask John.  It exists strictly for existing code.
>
> However, if your target was a VAX, (not available anymore), it might be
> a viable choice, or not.

I am not sure that I will call writing new code on VAX for
viable no matter the language.

Arne

[Simon Clubley]

On 2019-07-09, Dave Froble <da...@tsoft-inc.com> wrote:
> On 7/9/2019 3:08 AM, Simon Clubley wrote:
>> On 2019-07-08, Dave Froble <da...@tsoft-inc.com> wrote:
>>>
>>> Macro-32 is an assembler on the VAX. On Alpha, itanic, and x86 is is a
>>> compiled language, and not anything you'd want to use on the non-VAX
>>> systems. Just ask John. It exists strictly for existing code.
>>>
>>
>> It's nothing to do with whether it's an assembler or a compiler.
>>
>> It's to do with the fact that assembly language is so low level
>> and error prone even when compared to C.
>
> One might argue that "low level" maybe has less chance for errors.
>

You are kidding right ?

> One might also argue that C is rather prone to errors.
>

Yes it is unfortunately and other languages have thankfully improved on it.

It doesn't change the fact that C, with all its well known flaws, is
still a more robust language than assembly language to write code in.

>>> However, if your target was a VAX, (not available anymore), it might be
>>> a viable choice, or not.
>>>
>>
>> These days, the only thing anyone uses assembly language for in
>> new code are the small segments which cannot be coded even in C.
>
> "anyone" ??????
>
> It is rather amusing when people state their personal opinions as
> universal. Can I then claim Basic as the best language to use?
>

The difference is that I can look at other operating systems to
back up that comment. You don't see major portions of a Unix/Linux
kernel being written in assembly language for example. Even VMS now
has new stuff being mainly written in C or better.

What you see is assembly language being used for small bits of
architecture specific code and C or better being used for the
rest of the kernel and user space code.

Oh and I didn't say that C was the best language to use as it most
certainly is not. What I said is that it's a better language than
assembly language to write new code in and that is true.

Any claim that Basic is the best language to use would have to show
how the language is being widely used to solve problems in all areas
of the computing world and how testing and analysis has shown that
it is better than all the other options out there.

Do you know of any such testing and analysis ?

[Dave Froble]

No fair! That was the question I was reserving for you if you made any
such claims.

:-(

[Bill Gunshannon]

On 7/9/19 3:08 AM, Simon Clubley wrote:
> On 2019-07-08, Dave Froble <da...@tsoft-inc.com> wrote:
>>
>> Macro-32 is an assembler on the VAX. On Alpha, itanic, and x86 is is a
>> compiled language, and not anything you'd want to use on the non-VAX
>> systems. Just ask John. It exists strictly for existing code.
>>
>
> It's nothing to do with whether it's an assembler or a compiler.

Both are merely semantics. Both are programs that take human
readable input and generate machine runable object code.

>
> It's to do with the fact that assembly language is so low level
> and error prone even when compared to C.

The current MACRO-32 compiler can not be low level by any stretch
of the imagination. I can not believe any VAX instruction would
map directly and with the same semantics with the instruction set
of the Alpha or the IA64. The same would be true for the x86-64.

>
>> However, if your target was a VAX, (not available anymore), it might be
>> a viable choice, or not.
>>
>
> These days, the only thing anyone uses assembly language for in
> new code are the small segments which cannot be coded even in C.

Except maybe in embedded systems I doubt any need for this still
exists. And in the embedded world they might write a lot more
in assembler. But I doubt it.

bill

[Bill Gunshannon]

On 7/9/19 9:04 AM, Dave Froble wrote:
> On 7/9/2019 3:08 AM, Simon Clubley wrote:
>> On 2019-07-08, Dave Froble <da...@tsoft-inc.com> wrote:
>>>
>>> Macro-32 is an assembler on the VAX.  On Alpha, itanic, and x86 is is a
>>> compiled language, and not anything you'd want to use on the non-VAX
>>> systems.  Just ask John.  It exists strictly for existing code.
>>>
>>
>> It's nothing to do with whether it's an assembler or a compiler.
>>
>> It's to do with the fact that assembly language is so low level
>> and error prone even when compared to C.
>
> One might argue that "low level" maybe has less chance for errors.

Like with other languages, it depends mostly on the abilities
of the programmer.

>
> One might also argue that C is rather prone to errors.

C is not prone to any more errors than any other language. See
previous statement.

>
>>> However, if your target was a VAX, (not available anymore), it might be
>>> a viable choice, or not.
>>>
>>
>> These days, the only thing anyone uses assembly language for in
>> new code are the small segments which cannot be coded even in C.
>
> "anyone" ??????
>
> It is rather amusing when people state their personal opinions as
> universal.  Can I then claim Basic as the best language to use?

You can claim anything you want. It won't make it reality.

bill

[Bill Gunshannon]

On 7/9/19 1:55 PM, Simon Clubley wrote:
> On 2019-07-09, Dave Froble <da...@tsoft-inc.com> wrote:
>> On 7/9/2019 3:08 AM, Simon Clubley wrote:
>>> On 2019-07-08, Dave Froble <da...@tsoft-inc.com> wrote:
>>>>
>>>> Macro-32 is an assembler on the VAX. On Alpha, itanic, and x86 is is a
>>>> compiled language, and not anything you'd want to use on the non-VAX
>>>> systems. Just ask John. It exists strictly for existing code.
>>>>
>>>
>>> It's nothing to do with whether it's an assembler or a compiler.
>>>
>>> It's to do with the fact that assembly language is so low level
>>> and error prone even when compared to C.
>>
>> One might argue that "low level" maybe has less chance for errors.
>>
>
> You are kidding right ?

No, I amn sure he actually believes that.

>
>> One might also argue that C is rather prone to errors.
>>
>
> Yes it is unfortunately and other languages have thankfully improved on it.

Hogwash. The language is just fine. It is not the language's
fault that idiots use it to develop code that is beyond their
abilities.

>
> It doesn't change the fact that C, with all its well known flaws, is
> still a more robust language than assembly language to write code in.

Choose the right tool for the job. It's not supposed to be
a competition to see which language can be mis-used the most.

>
>>>> However, if your target was a VAX, (not available anymore), it might be
>>>> a viable choice, or not.
>>>>
>>>
>>> These days, the only thing anyone uses assembly language for in
>>> new code are the small segments which cannot be coded even in C.
>>
>> "anyone" ??????
>>
>> It is rather amusing when people state their personal opinions as
>> universal. Can I then claim Basic as the best language to use?
>>
>
> The difference is that I can look at other operating systems to
> back up that comment. You don't see major portions of a Unix/Linux
> kernel being written in assembly language for example. Even VMS now
> has new stuff being mainly written in C or better.

Assembler was probably not needed at the time the original VMS
stuff was being developed but the people doing the work felt
most comfortable with it and it did fit the job.

>
> What you see is assembly language being used for small bits of
> architecture specific code and C or better being used for the
> rest of the kernel and user space code.

I have seen OSes written in things other than C or assembler.
PL/I, SPL, Pascal, even Fortran (and I am sure others but I
only mention the ones I know personally.)

>
> Oh and I didn't say that C was the best language to use as it most
> certainly is not. What I said is that it's a better language than
> assembly language to write new code in and that is true.

Maybe, but not necessarily.

>
> Any claim that Basic is the best language to use would have to show
> how the language is being widely used to solve problems in all areas
> of the computing world and how testing and analysis has shown that
> it is better than all the other options out there.
>
> Do you know of any such testing and analysis ?

I don't know of any other language suffering such ignominies.
In it's day BASIC was used for many of the things you expect
other languages to be used for. I expect that the same inertia
that keeps COBOL, Fortran, RPG, PL/I, etc . going strong would also
apply to BASIC in more places than you re likelt to be willing to
accept.

bill

[Arne Vajhøj]

On 7/9/2019 8:20 PM, Bill Gunshannon wrote:
> On 7/9/19 9:04 AM, Dave Froble wrote:
>> One might also argue that C is rather prone to errors.
>
> C is not prone to any more errors than any other language. See
> previous statement.

Languages are not equal when it comes to prevent errors.

And C is probably one of the worst in this regard among widely
used languages.

Characteristics like:
* no check on array indexes
* very flexible pointer arithmetic
* very flexible type casting
* allowing use of uninitialized variables
* no string type
* non type safe enum
* lots of old and bad design in standard RTL
* lots of undefined and implementation specific behavior
makes it much easier to write code that result in bad runtime
error than most other common languages of today.

Some of these characteristics may be very useful in certain
contexts. But that does not make them less likely to
result in errors.

Arne

[Simon Clubley]

On 2019-07-09, Bill Gunshannon <bill.gu...@gmail.com> wrote:
> On 7/9/19 3:08 AM, Simon Clubley wrote:
>>
>> It's to do with the fact that assembly language is so low level
>> and error prone even when compared to C.
>
> The current MACRO-32 compiler can not be low level by any stretch
> of the imagination. I can not believe any VAX instruction would
> map directly and with the same semantics with the instruction set
> of the Alpha or the IA64. The same would be true for the x86-64.
>

Who said anything about the compiler ?

I was talking about the language the user writes their code in and
Macro-32 is a far lower level and more error prone language than
even C is.

[Simon Clubley]

On 2019-07-09, Bill Gunshannon <bill.gu...@gmail.com> wrote:

> On 7/9/19 1:55 PM, Simon Clubley wrote:
>>
>> What you see is assembly language being used for small bits of
>> architecture specific code and C or better being used for the
>> rest of the kernel and user space code.
>
> I have seen OSes written in things other than C or assembler.
> PL/I, SPL, Pascal, even Fortran (and I am sure others but I
> only mention the ones I know personally.)
>

Hence the "or better" part of my comment. :-)

I would be happy if we saw more things being written in something like
Ada or a Wirth style language.

My wish doesn't change the fact that C is still a better language
than assembly language.

And yes, I've written code in lots of assembly languages (I like
the ARM ISA for example), C and C++, Ada/Wirth style languages, and
a good range of other languages. My opinions are based on actual
experience.

[Bill Gunshannon]

On 7/9/19 10:37 PM, Arne Vajhøj wrote:
> On 7/9/2019 8:20 PM, Bill Gunshannon wrote:
>> On 7/9/19 9:04 AM, Dave Froble wrote:
>>> One might also argue that C is rather prone to errors.
>>
>> C is not prone to any more errors than any other language. See
>> previous statement.
>
> Languages are not equal when it comes to prevent errors.
>
> And C is probably one of the worst in this regard among widely
> used languages.
>
> Characteristics like:
> * no check on array indexes

Programmer should know that going in.

By the way, same applies to COBOL.

> * very flexible pointer arithmetic

Programmer should know that going in.

What's wrong with that? All assemblers have pointer arithmetic.

> * very flexible type casting

Programmer should know that going in.

What's wrong with that? A very useful function. And easily done
in every assembler I have ever used.

> * allowing use of uninitialized variables

Programmer should know that going in. You mean like someone
here's beloved BASIC? :-)
So does Fortran.

> * no string type

So what? What's so great about a string type? Fortran
didn't have it until 77. Pascal didn't have it until UCSD.

> * non type safe enum
> * lots of old and bad design in standard RTL
> * lots of undefined and implementation specific behavior

Even Ada has that.

> makes it much easier to write code that result in bad runtime
> error than most other common languages of today.

Do I really need to go on? Stop blaming a language for the
incompetence of the programmer.

>
> Some of these characteristics may be very useful in certain
> contexts. But that does not make them less likely to
> result in errors.

If you ever worked with students you would have seen a lot of
errors in every language. As they become more qualified the
errors decrease. Yes, even in C.

bill

[Scott Dorsey]

Bill Gunshannon <bill.gu...@gmail.com> wrote:
>
>> * no string type
>
>So what? What's so great about a string type? Fortran
>didn't have it until 77. Pascal didn't have it until UCSD.

Some of Arne's complaints about C are kind of silly, but this is a really
huge one.

If you look at CERT advisories regarding security vulnerabilities in the
past few decades, you will see that the vast majority of them are the direct
consequence of poor management of null-terminated strings.

I know, the null-terminated string thing seemed like a good idea, and easy
to graft onto C, but in the end it has been a terrible, terrible plan and
has cost us greatly.
--scott

--
"C'est un Nagra. C'est suisse, et tres, tres precis."

[Bill Gunshannon]

1. Null Terminated Strings are not unique to C.
2. The competent programmer knows all of this in the first place
and should write his programs accordingly. Just because the
language doesn't range check automatically (COBOL doesn't
either, probably for the same reason) doesn't mean the
programmer can't or shouldn't.

Read my lips. It's not the language.

bill

[Bill Gunshannon]

I should also have mentioned that while Pascal did have range
checking UCSD Pascal added the ability to turn it off. And I
have worked on programs where this was required to get the job
done.

bill

[Dave Froble]

On 7/10/2019 9:34 AM, Bill Gunshannon wrote:
> On 7/9/19 10:37 PM, Arne Vajhøj wrote:
>> On 7/9/2019 8:20 PM, Bill Gunshannon wrote:
>>> On 7/9/19 9:04 AM, Dave Froble wrote:
>>>> One might also argue that C is rather prone to errors.
>>>
>>> C is not prone to any more errors than any other language. See
>>> previous statement.
>>
>> Languages are not equal when it comes to prevent errors.
>>
>> And C is probably one of the worst in this regard among widely
>> used languages.
>>
>> Characteristics like:
>> * no check on array indexes
>
> Programmer should know that going in.

Ok, let's stipulate that a programmer must know a bit about what he/she
is attempting, and be done with such replies, Ok?

> By the way, same applies to COBOL.
>
>> * very flexible pointer arithmetic
>
> Programmer should know that going in.
>
> What's wrong with that? All assemblers have pointer arithmetic.
>
>> * very flexible type casting
>
> Programmer should know that going in.
>
> What's wrong with that? A very useful function. And easily done
> in every assembler I have ever used.
>
>
>> * allowing use of uninitialized variables
>
> Programmer should know that going in. You mean like someone
> here's beloved BASIC? :-)

Damn right. If I want a variable initialized, I do so. And if it
should be a constant, I declare that.

> So does Fortran.
>
>> * no string type
>
> So what? What's so great about a string type? Fortran
> didn't have it until 77. Pascal didn't have it until UCSD.

Strings are vital in some applications. Perhaps not in number
crunching. Try a name and address without strings. Maybe you'll be
cleaver enough to use GPS coordinates for the address, but for the name?

Try writing a compiler without strings.

>> * non type safe enum
>> * lots of old and bad design in standard RTL
>> * lots of undefined and implementation specific behavior
>
> Even Ada has that.
>
>> makes it much easier to write code that result in bad runtime
>> error than most other common languages of today.
>
> Do I really need to go on? Stop blaming a language for the
> incompetence of the programmer.

Of course a programmer must be competent, but, why not make things easier?

>> Some of these characteristics may be very useful in certain
>> contexts. But that does not make them less likely to
>> result in errors.
>
> If you ever worked with students you would have seen a lot of
> errors in every language. As they become more qualified the
> errors decrease. Yes, even in C.
>
> bill
>
>

[Dave Froble]

A competent programmer may be competent because he/she picks the better
tools for the job. Applies to computer languages.

Progress is usually trying ideas, adopting those that work well, and
leaving behind those that don't work so well.

Yes, null terminated strings pre-date C. They were a poor idea then,
and a poorer idea today. Perhaps you still wish to use buggy whips?

> Read my lips. It's not the language.

Ok, then it's the programmer's fault for choosing a poor language.

No test should ever change data. Even when coded improperly.

[Simon Clubley]

On 2019-07-10, Bill Gunshannon <bill.gu...@gmail.com> wrote:
> On 7/9/19 10:37 PM, Arne Vajhøj wrote:
>> makes it much easier to write code that result in bad runtime
>> error than most other common languages of today.
>
> Do I really need to go on? Stop blaming a language for the
> incompetence of the programmer.
>

Do you also operate power tools without the appropriate safety guards ?

I hope you have sufficient quantity of QuikClot/Celox, CATs and trauma
bandages around if you do. :-)

[Simon Clubley]

On 2019-07-10, Scott Dorsey <klu...@panix.com> wrote:
>
> If you look at CERT advisories regarding security vulnerabilities in the
> past few decades, you will see that the vast majority of them are the direct
> consequence of poor management of null-terminated strings.
>
> I know, the null-terminated string thing seemed like a good idea, and easy
> to graft onto C, but in the end it has been a terrible, terrible plan and
> has cost us greatly.

This can also work the other way around.

Counted strings and descriptors can be harder to compromise, but
when you can compromise them, they can also be easier to exploit.

When I compromised DCL, I needed to insert the address of the
code to execute into the prompt string. This address appeared
as a stream of binary bytes in the prompt string, including
0x00 characters.

With a null terminated string, the copy would have stopped at the
first null. This is a known problem when trying to exploit some
types of buffer overflows and you have to use various techniques
to try and work around it.

However, as DCL uses either a counted string or descriptor (I don't
know which), the prompt string just got copied as-is, nulls and all,
and promptly overwrote the return address without me having to worry
about any of that.

[Scott Dorsey]

Bill Gunshannon <bill.gu...@gmail.com> wrote:
>On 7/10/19 10:06 AM, Scott Dorsey wrote:
>> Bill Gunshannon <bill.gu...@gmail.com> wrote:
>>>
>>>> * no string type
>>>
>>> So what? What's so great about a string type? Fortran
>>> didn't have it until 77. Pascal didn't have it until UCSD.
>>
>> Some of Arne's complaints about C are kind of silly, but this is a really
>> huge one.
>>
>> If you look at CERT advisories regarding security vulnerabilities in the
>> past few decades, you will see that the vast majority of them are the direct
>> consequence of poor management of null-terminated strings.
>>
>> I know, the null-terminated string thing seemed like a good idea, and easy
>> to graft onto C, but in the end it has been a terrible, terrible plan and
>> has cost us greatly.
>
>1. Null Terminated Strings are not unique to C.

Sadly this is true.

>2. The competent programmer knows all of this in the first place
> and should write his programs accordingly. Just because the
> language doesn't range check automatically (COBOL doesn't
> either, probably for the same reason) doesn't mean the
> programmer can't or shouldn't.
>
>Read my lips. It's not the language.

Languages are designed to make programmers more effective, not less.

[Arne Vajhøj]

Neither Fortran 77 nor UCSD Pascal are recent.

:-)

>> * non type safe enum
>> * lots of old and bad design in standard RTL
>> * lots of undefined and implementation specific behavior
>
> Even Ada has that.
>
>> makes it much easier to write code that result in bad runtime
>> error than most other common languages of today.
>
> Do I really need to go on?  Stop blaming a language for the
> incompetence of the programmer.

I think you are missing one of the most fundamental
aspects of programming.

Programmers are humans. Humans make mistakes.

It does not work like:

you tell programmers how the language works => they write error free code

It works like:

you tell programmers how the language works many times => they still
code with an average of 1 bug per N lines of code

N varies - the better programmer the higher N - the more complex
language the lower N.

But N is less than infinite for all programmers.

Some languages detect a lot of these bugs at compile
time (or at least ensure that they give a consistent exception
at runtime).

These languages result in fewer bugs coming out of development.

Other languages just allow the programmer to do anything. And
the result is exceptions (sometimes inconsistent exceptions) at runtime.

These languages result in more bugs coming out of development.

Most (probably all) languages have some unsafe characteristics.

But C/C++ got more than other common languages of today. Of the
languages mentioned in this thread then Macro-32 is probably the
only language more unsafe.

Unless you really need these unsafe characteristics (which may
indeed be the case for OS kernel code), then languages with
those should be avoided.

>> Some of these characteristics may be very useful in certain
>> contexts. But that does not make them less likely to
>> result in errors.
>
> If you ever worked with students you would have seen a lot of
> errors in every language.  As they become more qualified the
> errors decrease.  Yes, even in C.

True.

But the absolute level would still be higher in C than
is more safe aka more checking languages.

Arne

[Arne Vajhøj]

On 7/10/2019 10:50 AM, Bill Gunshannon wrote:

> On 7/10/19 10:06 AM, Scott Dorsey wrote:
>> Bill Gunshannon  <bill.gu...@gmail.com> wrote:
>>>> * no string type
>>>
>>> So what?  What's so great about a string type?  Fortran
>>> didn't have it until 77.  Pascal didn't have it until UCSD.
>>
>> Some of Arne's complaints about C are kind of silly, but this is a really
>> huge one.
>>
>> If you look at CERT advisories regarding security vulnerabilities in the
>> past few decades, you will see that the vast majority of them are the
>> direct
>> consequence of poor management of null-terminated strings.
>>
>> I know, the null-terminated string thing seemed like a good idea, and
>> easy
>> to graft onto C, but in the end it has been a terrible, terrible plan and
>> has cost us greatly.
>
> 1.  Null Terminated Strings are not unique to C.

True.

But most common languages today do have a string type that does not rely
on zero termination.

> 2.  The competent programmer knows all of this in the first place
>     and should write his programs accordingly.  Just because the
>     language doesn't range check automatically (COBOL doesn't
>     either, probably for the same reason) doesn't mean the
>     programmer can't  or shouldn't.

The programmer should.

Almost all programmers try to do it.

But no matter their good intentions, then sometimes they miss
something.

Arne

[Arne Vajhøj]

Lots of languages have abilities to turn off various
safety checks.

C# and Rust have a pretty cool way of doing that in limited scope.

That rarely causes problems if used selectively. Because if it is
only turned off at a specific place in the code for specific
reason, then that get a lot of attention.

Arne

[Bill Gunshannon]

On 7/10/19 11:40 AM, Dave Froble wrote:
> On 7/10/2019 9:34 AM, Bill Gunshannon wrote:
>>
>>> * no string type
>>
>> So what?  What's so great about a string type?  Fortran
>> didn't have it until 77.  Pascal didn't have it until UCSD.
>
> Strings are vital in some applications.  Perhaps not in number
> crunching.  Try a name and address without strings.  Maybe you'll be
> cleaver enough to use GPS coordinates for the address, but for the name?
>
> Try writing a compiler without strings.

Nobody said there shouldn't be strings. You are free to declare
any type pf string you want in C. null-terminated, descriptor,
counted, whatever you want. Decide what is best for your use
and create it. The programmer is tied to only one type of string.

>
>>> * non type safe enum
>>> * lots of old and bad design in standard RTL
>>> * lots of undefined and implementation specific behavior
>>
>> Even Ada has that.
>>
>>> makes it much easier to write code that result in bad runtime
>>> error than most other common languages of today.
>>
>> Do I really need to go on?  Stop blaming a language for the
>> incompetence of the programmer.
>
> Of course a programmer must be competent, but, why not make things easier?

Because frequently (most times) "making it easier" involves hamstringing
the programmer.

bill

[Bill Gunshannon]

On 7/10/19 1:21 PM, Simon Clubley wrote:
> On 2019-07-10, Bill Gunshannon <bill.gu...@gmail.com> wrote:
>> On 7/9/19 10:37 PM, Arne Vajhøj wrote:
>>> makes it much easier to write code that result in bad runtime
>>> error than most other common languages of today.
>>
>> Do I really need to go on? Stop blaming a language for the
>> incompetence of the programmer.
>>
>
> Do you also operate power tools without the appropriate safety guards ?

Sometimes. when the guard prevents me from doing a task that I need
to do.

>
> I hope you have sufficient quantity of QuikClot/Celox, CATs and trauma
> bandages around if you do. :-)

Don't need them. Removing a device that somebody else thought was for
safety (as opposed to protecting against stupidity) does not imply that
I put myself in danger or get hurt. Good analogy, actually. Do you
know why the slot on modern CD drives is so thin? To keep people from
sticking their finger in to the drive and getting pinched. (I think we
have Europe to thank for that idiocy). Funny, that. I knew enough
not to stick my finger in in the first place.

bill

[Bill Gunshannon]

And neither is C.

bill

[Arne Vajhøj]

True.

But while Fortran and Pascal fixed the problem, then C
did not.

Even C++ sort of fixed the problem. They added STL std::string.
Even though a lot of C++ code still use the C style null
terminated arrays.

Arne

[Arne Vajhøj]

On 7/10/2019 2:10 PM, Bill Gunshannon wrote:
> On 7/10/19 11:40 AM, Dave Froble wrote:
>> On 7/10/2019 9:34 AM, Bill Gunshannon wrote:
>>>
>>>> * no string type
>>>
>>> So what?  What's so great about a string type?  Fortran
>>> didn't have it until 77.  Pascal didn't have it until UCSD.
>>
>> Strings are vital in some applications.  Perhaps not in number
>> crunching.  Try a name and address without strings.  Maybe you'll be
>> cleaver enough to use GPS coordinates for the address, but for the name?
>>
>> Try writing a compiler without strings.
>
> Nobody said there shouldn't be strings.  You are free to declare
> any type pf string you want in C.  null-terminated, descriptor,
> counted, whatever you want.  Decide what is best for your use
> and create it.  The programmer is tied to only one type of string.

But then all the details of the handling fall on the
programmer.

Giving the programmer lots of extra opportunities to
get it wrong.

Arne

[Dave Froble]

On 7/10/2019 2:10 PM, Bill Gunshannon wrote:

Sorry Bill, I got to call BS on that.

As an example, yes, string descriptors can be used in C. But as far as
I know, which isn't much, the programmer must set up the descriptors.
However, in Basic, it's not required to declare a string, just use it,
and it's there. Now, how does this case of "easier" hamstring the
programmer?

[Dave Froble]

On 7/10/2019 2:14 PM, Bill Gunshannon wrote:
> On 7/10/19 1:21 PM, Simon Clubley wrote:
>> On 2019-07-10, Bill Gunshannon <bill.gu...@gmail.com> wrote:
>>> On 7/9/19 10:37 PM, Arne Vajhøj wrote:
>>>> makes it much easier to write code that result in bad runtime
>>>> error than most other common languages of today.
>>>
>>> Do I really need to go on? Stop blaming a language for the
>>> incompetence of the programmer.
>>>
>>
>> Do you also operate power tools without the appropriate safety guards ?
>
> Sometimes. when the guard prevents me from doing a task that I need
> to do.

Got to agree with Bill on this one. But when necessary, there is a lot
of thinking, and planning, and care taken. Key word, "necessary".

>> I hope you have sufficient quantity of QuikClot/Celox, CATs and trauma
>> bandages around if you do. :-)
>
> Don't need them. Removing a device that somebody else thought was for
> safety (as opposed to protecting against stupidity) does not imply that
> I put myself in danger or get hurt. Good analogy, actually. Do you
> know why the slot on modern CD drives is so thin? To keep people from
> sticking their finger in to the drive and getting pinched. (I think we
> have Europe to thank for that idiocy). Funny, that. I knew enough
> not to stick my finger in in the first place.

I enjoyed the story of someone calling up the PC company and asking for
a new coffee cup holder, since the one in the CD drive broke off.

Stupidity, ignorance, and Murphy. Always with us.

[Stephen Hoffman]

On 2019-07-10 14:06:12 +0000, Scott Dorsey said:

> If you look at CERT advisories regarding security vulnerabilities in
> the past few decades, you will see that the vast majority of them are
> the direct consequence of poor management of null-terminated strings.

Not just null strings cause problems.

I'll just leave this here....

https://github.com/minimaxir/big-list-of-naughty-strings


--
Pure Personal Opinion | HoffmanLabs LLC

[Bill Gunshannon]

Maybe we should just kill all the programmers!!

bill

[Bill Gunshannon]

If the string is defined in a certain way, like it is in BASIC,
your hamstrung if you want to use some other form of string. If
you wanted to pass a null-terminated string from BASIC to some
other language, how would you do it?

bill

[Bill Gunshannon]

And, as was discovered with Ada (as well as others) it doesn't
always work out that way.

bill

[Bill Gunshannon]

On 7/10/19 5:32 PM, Stephen Hoffman wrote:
> On 2019-07-10 14:06:12 +0000, Scott Dorsey said:
>
>> If you look at CERT advisories regarding security vulnerabilities in
>> the past few decades, you will see that the vast majority of them are
>> the direct consequence of poor management of null-terminated strings.
>
> Not just null strings cause problems.

That is quite true, but the major pastime here is attacking
C and it has null-terminated strings. :-)

>
> I'll just leave this here....
>
> https://github.com/minimaxir/big-list-of-naughty-strings
>
>

bill

[Bill Gunshannon]

On 7/10/19 2:20 PM, Arne Vajhøj wrote:
> On 7/10/2019 2:15 PM, Bill Gunshannon wrote:
>> On 7/10/19 1:57 PM, Arne Vajhøj wrote:
>>> On 7/10/2019 9:34 AM, Bill Gunshannon wrote:
>>>> On 7/9/19 10:37 PM, Arne Vajhøj wrote:
>>>>> * no string type
>>>>
>>>> So what?  What's so great about a string type?  Fortran
>>>> didn't have it until 77.  Pascal didn't have it until UCSD.
>>>
>>> Neither Fortran 77 nor UCSD Pascal are recent.
>>>
>>> :-)
>>
>> And neither is C.
>
> True.
>
> But while Fortran and Pascal fixed the problem, then C
> did not.

Actually, it did. A long time ago.
1983 PDP-11 Software Source Book -- Page 1395
1986 VAX Software Source Book -- Page 1155

The Safe C Compiler.
From Catalytix Corp.

OSes supported: RSTS, RSX, RT-11, ULTRIX-11, UNIX, ULTRIX-32, VMS.

It met with the same acceptance as OO COBOL.

Wonder where Donald French is today.

>
> Even C++ sort of fixed the problem. They added STL std::string.
> Even though a lot of C++ code still use the C style null
> terminated arrays.

Some of us don't consider C++ to have anything to do with
real C. :-)

bill

[Arne Vajhøj]

On 7/10/2019 8:20 PM, Bill Gunshannon wrote:
> On 7/10/19 5:22 PM, Dave Froble wrote:
>> On 7/10/2019 2:10 PM, Bill Gunshannon wrote:
>>> Because frequently (most times) "making it easier" involves hamstringing
>>> the programmer.

>> As an example, yes, string descriptors can be used in C.  But as far
>> as I know, which isn't much, the programmer must set up the
>> descriptors. However, in Basic, it's not required to declare a string,
>> just use it, and it's there.  Now, how does this case of "easier"
>> hamstring the programmer?
>
> If the string is defined in a certain way, like it is in BASIC,
> your hamstrung if you want to use some other form of string.  If
> you wanted to pass a null-terminated string from BASIC to some
> other language, how would you do it?

Calling from a language with one type of string to a language with
another type of string is possible if there are some interop
capabilities present.

In many VMS languages with a string type it is possible to make
a pass by reference and manual appending the nul byte to call C.

This is not nice code.

But luckily it is a relative rare thing to do compared to how
much string's are used in general.

Arne

[Arne Vajhøj]

On 7/10/2019 8:42 PM, Bill Gunshannon wrote:
> On 7/10/19 2:20 PM, Arne Vajhøj wrote:
>> On 7/10/2019 2:15 PM, Bill Gunshannon wrote:
>>> On 7/10/19 1:57 PM, Arne Vajhøj wrote:
>>>> On 7/10/2019 9:34 AM, Bill Gunshannon wrote:
>>>>> On 7/9/19 10:37 PM, Arne Vajhøj wrote:
>>>>>> * no string type
>>>>>
>>>>> So what?  What's so great about a string type?  Fortran
>>>>> didn't have it until 77.  Pascal didn't have it until UCSD.
>>>>
>>>> Neither Fortran 77 nor UCSD Pascal are recent.
>>>>
>>>> :-)
>>>
>>> And neither is C.
>>
>> True.
>>
>> But while Fortran and Pascal fixed the problem, then C
>> did not.
>
> Actually, it did.  A long time ago.
> 1983 PDP-11 Software Source Book -- Page 1395
> 1986 VAX Software Source Book -- Page 1155
>
> The Safe C Compiler.
> From Catalytix Corp.
>
> OSes supported: RSTS, RSX, RT-11, ULTRIX-11, UNIX, ULTRIX-32, VMS.

Did it have a string type?

>> Even C++ sort of fixed the problem. They added STL std::string.
>> Even though a lot of C++ code still use the C style null
>> terminated arrays.
>
> Some of us don't consider C++ to have anything to do with
> real  C.   :-)

Modern C++ is very different from C.

But C++ still have a lot of C compatibility baggage.

Arne

[Bill Gunshannon]

On 7/10/19 8:49 PM, Arne Vajhøj wrote:
> On 7/10/2019 8:42 PM, Bill Gunshannon wrote:
>> On 7/10/19 2:20 PM, Arne Vajhøj wrote:
>>> On 7/10/2019 2:15 PM, Bill Gunshannon wrote:
>>>> On 7/10/19 1:57 PM, Arne Vajhøj wrote:
>>>>> On 7/10/2019 9:34 AM, Bill Gunshannon wrote:
>>>>>> On 7/9/19 10:37 PM, Arne Vajhøj wrote:
>>>>>>> * no string type
>>>>>>
>>>>>> So what?  What's so great about a string type?  Fortran
>>>>>> didn't have it until 77.  Pascal didn't have it until UCSD.
>>>>>
>>>>> Neither Fortran 77 nor UCSD Pascal are recent.
>>>>>
>>>>> :-)
>>>>
>>>> And neither is C.
>>>
>>> True.
>>>
>>> But while Fortran and Pascal fixed the problem, then C
>>> did not.
>>
>> Actually, it did.  A long time ago.
>> 1983 PDP-11 Software Source Book -- Page 1395
>> 1986 VAX Software Source Book -- Page 1155
>>
>> The Safe C Compiler.
>>  From Catalytix Corp.
>>
>> OSes supported: RSTS, RSX, RT-11, ULTRIX-11, UNIX, ULTRIX-32, VMS.
>
> Did it have a string type?
>

I seriously doubt it as it then wouldn't have been C. :-)

"The language understood by the Safe C Compiler is identical
to that understood by the standard C compilers."

But, it had a lot of the checks people here keep arguing that C
needs. Array indexing, Stray Pointers, mismatched formal and
actual parameters, Misuse of string functions, etc.

And the industry rejected it completely. None of its features
ever showed up in C Compilers that followed.

So, tell me, why did none of these things find their way into
the VMS C Compilers?

bill

[Dave Froble]

I thought your name was Bill, not Alexander ....

[Dave Froble]

Piece of cake ...

Have a fixed length string as a buffer, set it equal to the string +
Chr$(0%), and pass it by the required method, By Ref, By Value, or even
By Desc.

Next ???

[VAXman-]

In article <qg56re$f2m$1...@dont-email.me>, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:

>On 2019-07-10, Bill Gunshannon <bill.gu...@gmail.com> wrote:
>> On 7/9/19 10:37 PM, Arne Vajhøj wrote:

>>> makes it much easier to write code that result in bad runtime
>>> error than most other common languages of today.
>>
>> Do I really need to go on? Stop blaming a language for the
>> incompetence of the programmer.
>>
>

>Do you also operate power tools without the appropriate safety guards ?

Occasionally, if the safety gets in the way of completing the task but I
exercise other safety procedures in lieu of the tool's. Therefore, if I
am inhibited by some language when attempting to complete a task, I turn
to a language (tool) to complete it.

>I hope you have sufficient quantity of QuikClot/Celox, CATs and trauma
>bandages around if you do. :-)

As a lifetime consumer of Coumadin, I'm not sure that there's anything I
could use to mitigate a severe accident.

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

I speak to machines with the voice of humanity.

[VAXman-]

In article <gondhd...@mid.individual.net>, Bill Gunshannon <bill.gu...@gmail.com> writes:
>On 7/10/19 2:21 PM, Arne Vajhøj wrote:

>Maybe we should just kill all the programmers!!

-- William Gunshannon Shakespeare! :P

[Bill Gunshannon]

On 7/11/19 7:13 AM, VAX...@SendSpamHere.ORG wrote:
> In article <gondhd...@mid.individual.net>, Bill Gunshannon <bill.gu...@gmail.com> writes:

>> On 7/10/19 2:21 PM, Arne Vajhøj wrote:
>>> On 7/10/2019 2:10 PM, Bill Gunshannon wrote:
>>>> On 7/10/19 11:40 AM, Dave Froble wrote:
>>>>> On 7/10/2019 9:34 AM, Bill Gunshannon wrote:
>>>>>>
>>>>>>> * no string type
>>>>>>

>>>>>> So what?  What's so great about a string type?  Fortran
>>>>>> didn't have it until 77.  Pascal didn't have it until UCSD.
>>>>>
>>>>> Strings are vital in some applications.  Perhaps not in number
>>>>> crunching.  Try a name and address without strings.  Maybe you'll be

>>>>> cleaver enough to use GPS coordinates for the address, but for the name?
>>>>>
>>>>> Try writing a compiler without strings.
>>>>

>>>> Nobody said there shouldn't be strings.  You are free to declare
>>>> any type pf string you want in C.  null-terminated, descriptor,
>>>> counted, whatever you want.  Decide what is best for your use
>>>> and create it.  The programmer is tied to only one type of string.

>>>
>>> But then all the details of the handling fall on the
>>> programmer.
>>>
>>> Giving the programmer lots of extra opportunities to
>>> get it wrong.
>>
>> Maybe we should just kill all the programmers!!
>
> -- William Gunshannon Shakespeare! :P
>

I wondered who would catch the reference. :-)

bill

[Bill Gunshannon]

And, as with so many other languages, that only works with one
particular version of the language.

bill

[Bill Gunshannon]

You know, makes one wonder. Why did ANSI change so much trivial
stuff when the modified K&R to create ANSI-C and not fix any of
these supposed shortcomings?

Why did VMS versions of C not fix any of this? There is nothing
in the language that prevents range checking or array boundaries.
Why do people continue to complain and yet no one "fixes" stuff
that was actually fixed over 40 years ago?

bill

[Dave Froble]

I consider DEC's various versions of Basic, Basic+, BP2, VAX Basic, DEC
Basic, and such to be Basic. All others are imitations. Your opinion
may be different.

Since I work mostly with VMS, that's my reality.

And for the above solution, it's a bit safer, but any dynamic string
will usually work.

[Simon Clubley]

On 2019-07-11, Bill Gunshannon <bill.gu...@gmail.com> wrote:
> On 7/10/19 9:00 PM, Bill Gunshannon wrote:
>>
>> "The language understood by the Safe C Compiler is identical
>>  to that understood by the standard C compilers."
>>
>> But, it had a lot of the checks people here keep arguing that C
>> needs.  Array indexing, Stray Pointers, mismatched formal and
>> actual parameters, Misuse of string functions, etc.
>>

What is the most recent C compiler you have used ?

All C compilers I know of complain about mismatched parameters
and gcc complains about mismatched format string arguments.

As for the other stuff, here's one example:

https://en.wikipedia.org/wiki/AddressSanitizer
http://clang.llvm.org/docs/AddressSanitizer.html
https://gcc.gnu.org/onlinedocs/gcc/Instrumentation-Options.html

>> And the industry rejected it completely.  None of its features
>> ever showed up in C Compilers that followed.
>>
>> So, tell me, why did none of these things find their way into
>> the VMS C Compilers?
>
> You know, makes one wonder. Why did ANSI change so much trivial
> stuff when the modified K&R to create ANSI-C and not fix any of
> these supposed shortcomings?
>
> Why did VMS versions of C not fix any of this? There is nothing
> in the language that prevents range checking or array boundaries.
> Why do people continue to complain and yet no one "fixes" stuff
> that was actually fixed over 40 years ago?
>

AddressSanitizer will hopefully work on x86-64 VMS as well.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

[Arne Vajhøj]

On 7/11/2019 1:43 PM, Simon Clubley wrote:
> On 2019-07-11, Bill Gunshannon <bill.gu...@gmail.com> wrote:
>> On 7/10/19 9:00 PM, Bill Gunshannon wrote:
>>>
>>> "The language understood by the Safe C Compiler is identical
>>>  to that understood by the standard C compilers."
>>>
>>> But, it had a lot of the checks people here keep arguing that C
>>> needs.  Array indexing, Stray Pointers, mismatched formal and
>>> actual parameters, Misuse of string functions, etc.
>
> What is the most recent C compiler you have used ?
>
> All C compilers I know of complain about mismatched parameters

Yes. I believe that is required by the C standard.

But same C standard has a little quirk.

void f()

does not mean "no parameters" - it means "any number of parameters",
which effectively disable the parameter check.

For the not C savvy then to get "no parameters" one has to use:

void f(void)

Note that I did not have this on my "problem list" as I really don't
think it is a common cause of problems. The only interesting point
is that C++ fixed it.

Arne

[Arne Vajhøj]

On 7/11/2019 10:21 AM, Bill Gunshannon wrote:
> On 7/10/19 9:00 PM, Bill Gunshannon wrote:
>> On 7/10/19 8:49 PM, Arne Vajhøj wrote:
>>> On 7/10/2019 8:42 PM, Bill Gunshannon wrote:
>>>> On 7/10/19 2:20 PM, Arne Vajhøj wrote:
>>>>> But while Fortran and Pascal fixed the problem, then C
>>>>> did not.
>>>>
>>>> Actually, it did.  A long time ago.
>>>> 1983 PDP-11 Software Source Book -- Page 1395
>>>> 1986 VAX Software Source Book -- Page 1155
>>>>
>>>> The Safe C Compiler.
>>>>  From Catalytix Corp.
>>>>
>>>> OSes supported: RSTS, RSX, RT-11, ULTRIX-11, UNIX, ULTRIX-32, VMS.
>>>
>>> Did it have a string type?
>>>
>>
>> I seriously doubt it as it then wouldn't have been C.  :-)

But that was what we were discussing for Fortran and Pascal.

>> "The language understood by the Safe C Compiler is identical
>>   to that understood by the standard C compilers."
>>
>> But, it had a lot of the checks people here keep arguing that C
>> needs.  Array indexing, Stray Pointers, mismatched formal and
>> actual parameters, Misuse of string functions, etc.
>>
>> And the industry rejected it completely.  None of its features
>> ever showed up in C Compilers that followed.
>>
>> So, tell me, why did none of these things find their way into
>> the VMS C Compilers?
>
> You know, makes one wonder.  Why did ANSI change so much trivial
> stuff when the modified K&R to create ANSI-C and not fix any of
> these supposed shortcomings?

If they had then C would have been much better for most applications
but worse for operating system kernels.

I have no idea what the ANSI/ISO people were thinking back in the
late 1980's.

But it seems quite plausible that the logic was "C does what
it does - those that want a more safe language should pick
another language".

> Why did VMS versions of C not fix any of this?  There is nothing
> in the language that prevents range checking or array boundaries.

They needed to be standard compliant.

I don't think it is possible/practical to make all required array,
pointer and array-pointer mix functionality in the standard
work with array range check.

Arne

[Arne Vajhøj]

On 7/11/2019 10:17 AM, Bill Gunshannon wrote:
> On 7/10/19 10:03 PM, Dave Froble wrote:
>> On 7/10/2019 8:20 PM, Bill Gunshannon wrote:
>>> If the string is defined in a certain way, like it is in BASIC,
>>> your hamstrung if you want to use some other form of string.  If
>>> you wanted to pass a null-terminated string from BASIC to some
>>> other language, how would you do it?

>> Have a fixed length string as a buffer, set it equal to the string +
>> Chr$(0%), and pass it by the required method, By Ref, By Value, or
>> even By Desc.

> And, as with so many other languages, that only works with one
> particular version of the language.

There is nothing unusual in language mixing being
platform specific.

If you want to call something from C on Windows
you will have to choose between __cdecl, __stdcall
and __fastcall.

Arne

[Bill Gunshannon]

On 7/11/19 1:43 PM, Simon Clubley wrote:
> On 2019-07-11, Bill Gunshannon <bill.gu...@gmail.com> wrote:
>> On 7/10/19 9:00 PM, Bill Gunshannon wrote:
>>>
>>> "The language understood by the Safe C Compiler is identical
>>>  to that understood by the standard C compilers."
>>>
>>> But, it had a lot of the checks people here keep arguing that C
>>> needs.  Array indexing, Stray Pointers, mismatched formal and
>>> actual parameters, Misuse of string functions, etc.
>>>
>
> What is the most recent C compiler you have used ?

How recent is the current version of GCC?

>
> All C compilers I know of complain about mismatched parameters
> and gcc complains about mismatched format string arguments.

That's what I meant about trivial additions by ANSI.

>
> As for the other stuff, here's one example:
>
> https://en.wikipedia.org/wiki/AddressSanitizer
> http://clang.llvm.org/docs/AddressSanitizer.html
> https://gcc.gnu.org/onlinedocs/gcc/Instrumentation-Options.html
>
>>> And the industry rejected it completely.  None of its features
>>> ever showed up in C Compilers that followed.
>>>
>>> So, tell me, why did none of these things find their way into
>>> the VMS C Compilers?
>>
>> You know, makes one wonder. Why did ANSI change so much trivial
>> stuff when the modified K&R to create ANSI-C and not fix any of
>> these supposed shortcomings?
>>
>> Why did VMS versions of C not fix any of this? There is nothing
>> in the language that prevents range checking or array boundaries.
>> Why do people continue to complain and yet no one "fixes" stuff
>> that was actually fixed over 40 years ago?
>>
>
> AddressSanitizer will hopefully work on x86-64 VMS as well.
>

That is not a change to the compiler. Lint used to point
out a lot of potential problems but I knew few people other
than myself who ever actually used it. If the compiler
lets it bad code will continue to come out of the mill.

bill

[Bill Gunshannon]

On 7/11/19 5:26 PM, Arne Vajhøj wrote:
> On 7/11/2019 10:21 AM, Bill Gunshannon wrote:
>> On 7/10/19 9:00 PM, Bill Gunshannon wrote:
>>> On 7/10/19 8:49 PM, Arne Vajhøj wrote:
>>>> On 7/10/2019 8:42 PM, Bill Gunshannon wrote:
>>>>> On 7/10/19 2:20 PM, Arne Vajhøj wrote:
>>>>>> But while Fortran and Pascal fixed the problem, then C
>>>>>> did not.
>>>>>
>>>>> Actually, it did.  A long time ago.
>>>>> 1983 PDP-11 Software Source Book -- Page 1395
>>>>> 1986 VAX Software Source Book -- Page 1155
>>>>>
>>>>> The Safe C Compiler.
>>>>>  From Catalytix Corp.
>>>>>
>>>>> OSes supported: RSTS, RSX, RT-11, ULTRIX-11, UNIX, ULTRIX-32, VMS.
>>>>
>>>> Did it have a string type?
>>>>
>>>
>>> I seriously doubt it as it then wouldn't have been C.  :-)
>
> But that was what we were discussing for Fortran and Pascal.

The 77 Fortran standard and various Pascals (I don't have a copy
of the standard handy) added strings to the language. C never has.
And the C in use at the time Safe C was created was pure K&R.

>
>>> "The language understood by the Safe C Compiler is identical
>>>   to that understood by the standard C compilers."
>>>
>>> But, it had a lot of the checks people here keep arguing that C
>>> needs.  Array indexing, Stray Pointers, mismatched formal and
>>> actual parameters, Misuse of string functions, etc.
>>>
>>> And the industry rejected it completely.  None of its features
>>> ever showed up in C Compilers that followed.
>>>
>>> So, tell me, why did none of these things find their way into
>>> the VMS C Compilers?
>>
>> You know, makes one wonder.  Why did ANSI change so much trivial
>> stuff when the modified K&R to create ANSI-C and not fix any of
>> these supposed shortcomings?
>
> If they had then C would have been much better for most applications
> but worse for operating system kernels.

In what way? I don't need unbounded arrays to write an OS. Or a
device driver.

>
> I have no idea what the ANSI/ISO people were thinking back in the
> late 1980's.

And still people wonder why I have never been impressed with the
work ANSI does.

>
> But it seems quite plausible that the logic was "C does what
> it does - those that want a more safe language should pick
> another language".

And yet the tried to add OO to COBOL. They created a standard for
Pascal which, for obvious reasons, couldn't please all Pascal users.
They added strings to Fortran, a language specifically intended for
complex mathematics. Go figure.

>
>> Why did VMS versions of C not fix any of this?  There is nothing
>> in the language that prevents range checking or array boundaries.
>
> They needed to be standard compliant.

Does the standard explicitly state that boundaries and ranges can
not be validated?

>
> I don't think it is possible/practical to make all required array,
> pointer and array-pointer mix functionality in the standard
> work with array range check.

If it can't be fixed then why do people still complain about the fact
that C does it?

bill

[Andrew Shaw]

On Friday, July 12, 2019 at 11:18:03 AM UTC+10, Bill Gunshannon wrote:
>
> Lint used to point
> out a lot of potential problems but I knew few people other
> than myself who ever actually used it. If the compiler
> lets it bad code will continue to come out of the mill.

I almost always use lint or I add more picky flags to whatever compiler I am using when building something that needs to run in a Production environment.
I want to explore as many avenues of potential failure as I can before I deploy
my code as I've already had way too many alarms go off at 3am (I don't know
whose law it is that says that code will only break at the most inconvenient time.) I still have nightmares of my pager (pre mobile phone era) going off at 3am meaning I had an hour to investigate and fix some anomalous ACMS runtime issue.

I want my code to break in Dev before I send it anywhere. I don't always get that !

[Bill Gunshannon]

Congratulation. Welcome to a very select and small group.

Try taking some piece of serious piece freeware and turn on
all warnings before running make. Then come back and tell
me how much you would trust it. Someone here is working
on PERL. Give that one a try. :-)

bill

[Arne Vajhøj]

On 7/11/2019 9:26 PM, Bill Gunshannon wrote:
> On 7/11/19 5:26 PM, Arne Vajhøj wrote:
>> On 7/11/2019 10:21 AM, Bill Gunshannon wrote:
>>> On 7/10/19 9:00 PM, Bill Gunshannon wrote:
>>>> On 7/10/19 8:49 PM, Arne Vajhøj wrote:
>>>>> On 7/10/2019 8:42 PM, Bill Gunshannon wrote:
>>>>>> On 7/10/19 2:20 PM, Arne Vajhøj wrote:
>>>>>>> But while Fortran and Pascal fixed the problem, then C
>>>>>>> did not.
>>>>>>
>>>>>> Actually, it did.  A long time ago.
>>>>>> 1983 PDP-11 Software Source Book -- Page 1395
>>>>>> 1986 VAX Software Source Book -- Page 1155
>>>>>>
>>>>>> The Safe C Compiler.
>>>>>>  From Catalytix Corp.
>>>>>>
>>>>>> OSes supported: RSTS, RSX, RT-11, ULTRIX-11, UNIX, ULTRIX-32, VMS.
>>>>>
>>>>> Did it have a string type?
>>>>>
>>>>
>>>> I seriously doubt it as it then wouldn't have been C.  :-)
>>
>> But that was what we were discussing for Fortran and Pascal.
>
> The 77 Fortran standard and various Pascals (I don't have a copy
> of the standard handy) added strings to the language.  C never has.
> And the C in use at the time Safe C was created was pure K&R.

As I wrote:

>>>>>>> But while Fortran and Pascal fixed the problem, then C
>>>>>>> did not.

>>>> "The language understood by the Safe C Compiler is identical
>>>>   to that understood by the standard C compilers."
>>>>
>>>> But, it had a lot of the checks people here keep arguing that C
>>>> needs.  Array indexing, Stray Pointers, mismatched formal and
>>>> actual parameters, Misuse of string functions, etc.
>>>>
>>>> And the industry rejected it completely.  None of its features
>>>> ever showed up in C Compilers that followed.
>>>>
>>>> So, tell me, why did none of these things find their way into
>>>> the VMS C Compilers?
>>>
>>> You know, makes one wonder.  Why did ANSI change so much trivial
>>> stuff when the modified K&R to create ANSI-C and not fix any of
>>> these supposed shortcomings?
>>
>> If they had then C would have been much better for most applications
>> but worse for operating system kernels.
>
> In what way?  I don't need unbounded arrays to write an OS.  Or a
> device driver.

Maybe not, but you will need unbounded pointers.

And with C's mixing of pointers and arrays, then bounded arrays
would become messy to implement.

>> But it seems quite plausible that the logic was "C does what
>> it does - those that want a more safe language should pick
>> another language".
>
> And yet the tried to add OO to COBOL.  They created a standard for
> Pascal which, for obvious reasons, couldn't please all Pascal users.
> They added strings to Fortran, a language specifically intended for
> complex mathematics.  Go figure.

But most of those changes was pure extensions of the language meaning
that existing code would run as is (there are a few exceptions,
but ...).

Some of the problems in C being discussed could be fixed in a
non-breaking way. But other like removing flexible pointer manipulation
would break a lot of existing C programs.

>>> Why did VMS versions of C not fix any of this?  There is nothing
>>> in the language that prevents range checking or array boundaries.
>>
>> They needed to be standard compliant.
>
> Does the standard explicitly state that boundaries and ranges can
> not be validated?

No.

But it makes it difficult to implement given what has to work.

>> I don't think it is possible/practical to make all required array,
>> pointer and array-pointer mix functionality in the standard
>> work with array range check.
>
> If it can't be fixed then why do people still complain about the fact
> that C does it?

I think most of the complaining about C is related to the usage.

Not a problem writing OS kernel in C. For that purpose you can't have
a language where a pointer can only point to something new'ed. You
need to lookup stuff all over S0 space. That comes with certain
risks, but those risks are unavoidable.

The problem is the other 99% of applications, where the ability to
shoot oneself in the foot is not needed and just an unnecessary risk.

Arne