On 2/27/2023 1:43 PM, Dave Froble wrote:
> On 2/27/2023 10:37 AM, Scott Dorsey wrote:
>> You could argue that the need for customized environments is reduced
>> today,
>> now that standardized environments are more sophisticated.  I don't agree
>> with that at all but it is a thing which could be debated.
>
> I'm with you on this.  What I'm seeing is that some "standardized
> environments" is actually "this is what you're going to get, don't ask
> for more".

"this is what you're going to get, don't ask for more" is practically
the definition of standardized.

But the point being is that what you get is a lot more than what
it was 40 years ago.

> Perhaps "standardized environments" aren't so good for everyone?

Custom is more expensive than standard.

So it depends on whether custom can generate enough extra revenue than
standard to cover the extra cost.

If it is not related to the company's core business then the answer
is likely no.

If it is related to the company's core business then it may be a yes.

Especially of the business is huge so even significant absolute cost
becomes small relative cost.

Arne

On 2/27/2023 11:47 AM, ultr...@gmail.com wrote:
> On Friday, February 24, 2023 at 8:20:19 AM UTC-5, Simon Clubley wrote:
>> On 2023-02-23, ultr...@gmail.com <ultr...@gmail.com> wrote:
>>> I HELPED MY SON WITH C++ AND C# IN COLLEGE ... SAME OLD C SAME OLD COMPILER/DEBUGGER ISSUES
>> If you consider C# to be in any way related to C, then you are _very_
>> seriously delusional.
>
> but its design came from the same screwed up design of a language

As I said earlier then there is relative little in C# design that
exist in C design.

The usage of curly brackets. And the weird for loop construct.

Arne

On Sat, 25 Feb 2023 19:28:06 -0500, Arne Vajhøj <arne@vajhoej.dk>
wrote:

>On 2/25/2023 4:32 PM, John Dallman wrote:
>> In article <ttd4ta$2j12a$2@dont-email.me>, arne@vajhoej.dk (Arne Vajhøj)
>> wrote:
>>> C# and Java are very similar. I don't think MS ever made a secret
>>> of that.
>>
>> Microsoft started on .NET during their lawsuit with Sun over their
>> incomplete-but-extended Java implementation. They seem to have hoped to
>> replace Java with .NET.
>
>Yes.
>
>>> There are of course also some differences. C# got
>>> unsafe blocks with pointers (nobody use them) ...
>>
>> The main thing those are useful for is calling native code. It's way
>> easier than using JNI.
>
>I was not thinking about pointer type aka IntPtr, which are commonly
>used for p/Invoke (DllImport).
>
<snip>
>
>I was thinking about real star pointer.
>
>Example:
>
>using System;
>
>namespace StarPtr
>{
> public class Program
> {
> public static void Main(string[] args)
> {
> int[] a = new int[4] { 1, 2, 3, 4 };
> foreach(int ai in a)
> {
> Console.Write(" {0}", ai);
> }
> Console.WriteLine();
> unsafe
> {
> fixed(int *p = &a[0])
> {
> for(int i = 0; i < 4; i++)
> {
> int *p2 = p + i;
> Console.Write(" {0}", *p2);
> }
> Console.WriteLine();
> }
> }
> }
> }
>}
>
>The star pointer do not need to be used with p/Invoke (DllImport) but
>they can be used - I just think it is very rare.
>
<snip>

Exactly. I use C# for building the UI for all my test and measurement
devices, because it's so quick development time wise, and has a pretty
good thirdparty UI widget ecosystem. Having the full suite of unsafe
C tools available makes it a dream, when you have to interface with
tons of random vendor specific drivers and libraries, and the glue
code is very clean and maintainable.

Mark

On 2/27/2023 4:14 PM, Arne Vajhøj wrote:
> On 2/27/2023 1:43 PM, Dave Froble wrote:
>> On 2/27/2023 10:37 AM, Scott Dorsey wrote:
>>> You could argue that the need for customized environments is reduced
>>> today,
>>> now that standardized environments are more sophisticated.  I don't
>>> agree
>>> with that at all but it is a thing which could be debated.
>>
>> I'm with you on this.  What I'm seeing is that some "standardized
>> environments" is actually "this is what you're going to get, don't ask
>> for more".
>
> "this is what you're going to get, don't ask for more" is practically
> the definition of standardized.
>
> But the point being is that what you get is a lot more than what
> it was 40 years ago.

From who's viewpoint?

>
>> Perhaps "standardized environments" aren't so good for everyone?
>
> Custom is more expensive than standard.

Didn't used to be. That happened when they started paying someone
outside of their own organization to do the work.

>
> So it depends on whether custom can generate enough extra revenue than
> standard to cover the extra cost.

Back in the day :-) making changes to satisfy your user's requirements
wasn't a separate budget line item.

>
> If it is not related to the company's core business then the answer
> is likely no.

In many cases today, even if it is related to the company's core
business the answer is no.

>
> If it is related to the company's core business then it may be a yes.

But probably not.

And then we now have the issue of which company's core business? Yours
or the software package provider's?

>
> Especially of the business is huge so even significant absolute cost
> becomes small relative cost.
>
> Arne
>
>

bill

On 2/27/2023 4:26 PM, bill wrote:
> On 2/27/2023 4:14 PM, Arne Vajhøj wrote:
>> On 2/27/2023 1:43 PM, Dave Froble wrote:
>>> On 2/27/2023 10:37 AM, Scott Dorsey wrote:
>>>> You could argue that the need for customized environments is reduced
>>>> today,
>>>> now that standardized environments are more sophisticated.  I don't
>>>> agree
>>>> with that at all but it is a thing which could be debated.
>>>
>>> I'm with you on this.  What I'm seeing is that some "standardized
>>> environments" is actually "this is what you're going to get, don't
>>> ask for more".
>>
>> "this is what you're going to get, don't ask for more" is practically
>> the definition of standardized.
>>
>> But the point being is that what you get is a lot more than what
>> it was 40 years ago.
>
> From who's viewpoint?

There is more functionality. That is a fact.

Some may consider it unnecessary bloat, but there is "more".

>>> Perhaps "standardized environments" aren't so good for everyone?
>>
>> Custom is more expensive than standard.
>
> Didn't used to be.  That happened when they started paying someone
> outside of their own organization to do the work.

Internal customization also cost.

>> So it depends on whether custom can generate enough extra revenue than
>> standard to cover the extra cost.
>
> Back in the day :-)  making changes to satisfy your user's requirements
> wasn't a separate budget line item.
>
>>
>> If it is not related to the company's core business then the answer
>> is likely no.
>
> In many cases today, even if it is related to the company's core
> business the answer is no.
>
>>
>> If it is related to the company's core business then it may be a yes.
>
> But probably not.
>
> And then we now have the issue of which company's core business?  Yours
> or the software package provider's?

The ISV's try to sell their stuff as the best invention since
the round wheel.

It is up to the company to decide whether the product being
pushed provide value.

Arne

On 2/27/2023 4:31 PM, Arne Vajhøj wrote:
> On 2/27/2023 4:26 PM, bill wrote:
>> On 2/27/2023 4:14 PM, Arne Vajhøj wrote:
>>> On 2/27/2023 1:43 PM, Dave Froble wrote:
>>>> On 2/27/2023 10:37 AM, Scott Dorsey wrote:
>>>>> You could argue that the need for customized environments is reduced today,
>>>>> now that standardized environments are more sophisticated. I don't agree
>>>>> with that at all but it is a thing which could be debated.
>>>>
>>>> I'm with you on this. What I'm seeing is that some "standardized
>>>> environments" is actually "this is what you're going to get, don't ask for
>>>> more".
>>>
>>> "this is what you're going to get, don't ask for more" is practically
>>> the definition of standardized.
>>>
>>> But the point being is that what you get is a lot more than what
>>> it was 40 years ago.
>>
>> From who's viewpoint?
>
> There is more functionality. That is a fact.
>
> Some may consider it unnecessary bloat, but there is "more".
>
>>>> Perhaps "standardized environments" aren't so good for everyone?
>>>
>>> Custom is more expensive than standard.
>>
>> Didn't used to be. That happened when they started paying someone
>> outside of their own organization to do the work.
>
> Internal customization also cost.

That can vary.

If employees are hired to do the work, then yes.
If existing employees do the work, and would be an employee regardless, then not
so much.

>>> So it depends on whether custom can generate enough extra revenue than
>>> standard to cover the extra cost.
>>
>> Back in the day :-) making changes to satisfy your user's requirements
>> wasn't a separate budget line item.
>>
>>>
>>> If it is not related to the company's core business then the answer
>>> is likely no.
>>
>> In many cases today, even if it is related to the company's core
>> business the answer is no.
>>
>>>
>>> If it is related to the company's core business then it may be a yes.
>>
>> But probably not.
>>
>> And then we now have the issue of which company's core business? Yours
>> or the software package provider's?
>
> The ISV's try to sell their stuff as the best invention since
> the round wheel.

And it can be, but that may have no bearing on whether the apps solve the
businesses problems/tasks.

> It is up to the company to decide whether the product being
> pushed provide value.

Always.

But lately I've been hearing that it's up to the auditors.

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

On 27/02/2023 20:58, Arne Vajhøj wrote:
> On 2/27/2023 11:49 AM, ultr...@gmail.com wrote:
>> On Thursday, February 23, 2023 at 5:05:50 PM UTC-5, Paul Gavin wrote:
>>> What, DEC C cannot be debugged?
>>> Working on some enhancements in a C based app on Alphas running 8.4.
>>> Can get to debugger just fine, step through code, look at data, set
>>> break points, etc., even from within ACMS.
>>
>> never debugged dec c but if the compiler debugger is anything like C
>> it is difficult ...

I feel the issue with debugging "C" is that in order to effectively use
the debugger you tend to need to turn down optimisation, but turning
down optimization tends to make the code work as you expect. When you
turn it up again, undefined behaviour tends to re-emerge.

>
> The VMS C compiler behaves pretty much like other VMS compilers.
>
> The same VMS debugger is used for C as for any other (DEC/CPQ/HPE/VSI)
> language.
>
> Arne
>

Dave

David Wade <g4ugm@dave.invalid> wrote:
>On 27/02/2023 20:58, Arne Vajhøj wrote:
>> On 2/27/2023 11:49 AM, ultr...@gmail.com wrote:
>>> On Thursday, February 23, 2023 at 5:05:50 PM UTC-5, Paul Gavin wrote:
>>>> What, DEC C cannot be debugged?
>>>> Working on some enhancements in a C based app on Alphas running 8.4.
>>>> Can get to debugger just fine, step through code, look at data, set
>>>> break points, etc., even from within ACMS.
>>>
>>> never debugged dec c but if the compiler debugger is anything like C
>>> it is difficult ...
>
>I feel the issue with debugging "C" is that in order to effectively use
>the debugger you tend to need to turn down optimisation, but turning
>down optimization tends to make the code work as you expect. When you
>turn it up again, undefined behaviour tends to re-emerge.

This is definitely not the case with either the newer VMS C nor the more
recent gcc. It used to be a real problem with gcc. Even worse with
Whitesmith's. But that was a long time ago.
--scott

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

On 2/27/2023 5:42 PM, David Wade wrote:
> On 27/02/2023 20:58, Arne Vajhøj wrote:
>> On 2/27/2023 11:49 AM, ultr...@gmail.com wrote:
>>> On Thursday, February 23, 2023 at 5:05:50 PM UTC-5, Paul Gavin wrote:
>>>> What, DEC C cannot be debugged?
>>>> Working on some enhancements in a C based app on Alphas running 8.4.
>>>> Can get to debugger just fine, step through code, look at data, set
>>>> break points, etc., even from within ACMS.
>>>
>>> never debugged dec c but if the compiler debugger is anything like C
>>> it is difficult ...
>>
>> The VMS C compiler behaves pretty much like other VMS compilers.
>>
>> The same VMS debugger is used for C as for any other (DEC/CPQ/HPE/VSI)
>> language.
>
> I feel the issue with debugging "C" is that in order to effectively use
> the debugger you tend to need to turn down optimisation, but turning
> down optimization tends to make the code work as you expect. When you
> turn it up again, undefined behaviour tends to re-emerge.

/DEB/NOOP is not required but tend to make it easier to
debug because there is a closer correlation between the
instruction stream and the lines of source code.

And as you point out then that can in fact by itself
remove symptoms of a bug.

But isn't that the case for all VMS compilers? I know
I use /DEB/NOOP for both Fortran, Pascal and C when I want
to debug.

Arne

On 2/27/2023 5:39 PM, Dave Froble wrote:
> On 2/27/2023 4:31 PM, Arne Vajhøj wrote:
>> On 2/27/2023 4:26 PM, bill wrote:
>>> On 2/27/2023 4:14 PM, Arne Vajhøj wrote:
>>>> On 2/27/2023 1:43 PM, Dave Froble wrote:
>>>>> Perhaps "standardized environments" aren't so good for everyone?
>>>>
>>>> Custom is more expensive than standard.
>>>
>>> Didn't used to be.  That happened when they started paying someone
>>> outside of their own organization to do the work.
>>
>> Internal customization also cost.
>
> That can vary.
>
> If employees are hired to do the work, then yes.
> If existing employees do the work, and would be an employee regardless,
> then not so much.

If the alternative to the employees doing this work was that they
were sitting idle at their desk reading news papers, then you can
say that there is no cost.

If they could do something other useful, then there is a cost. And
that is hopefully the most common case.

In theory the cost should be accounted as the value of the other work.
In practice it tend to just be calculated based on direct and
indirect cost of the employee.

Arne

On 2/27/2023 6:35 PM, Arne Vajhøj wrote:

> But isn't that the case for all VMS compilers? I know
> I use /DEB/NOOP for both Fortran, Pascal and C when I want
> to debug.

Reagan may weigh in here, but I'm pretty sure that DEC suggested using
/DEBUG/NOOP when using the debugger for any language with an optimizer back in
the 80's; if so, then that's been a pretty consistent message.

--

--- Rob

On Monday, February 27, 2023 at 8:11:36 PM UTC-5, Robert A. Brooks wrote:
> On 2/27/2023 6:35 PM, Arne Vajhøj wrote:
>
> > But isn't that the case for all VMS compilers? I know
> > I use /DEB/NOOP for both Fortran, Pascal and C when I want
> > to debug.
> Reagan may weigh in here, but I'm pretty sure that DEC suggested using
> /DEBUG/NOOP when using the debugger for any language with an optimizer back in
> the 80's; if so, then that's been a pretty consistent message.
>
> --
>
> --- Rob
Debugging optimized code has been the Holy Grail for years. On Alpha, GEM and the debugger have
some attempt at make it possible but it wasn't perfect. Later DWARF standards have added additional
features for compilers to use to help convey the transformations used by the compiler, but it still a
challenge to present to the human in a way that makes sense. And of course, if the original source
program was technically illegal (which might be why you are in the debugger to start with), optimizers
will often do unspeakable transformations to such invalid programs.

So debugging unoptimized code helps you catch your algorithm errors (like subtracting one when you
should have added one). Finding things like uninitialized variables, free-after-use pointers, buffer
overruns, etc. often require more advanced tooling.

By the way, thanks to all the folks who've beat up on the native C compiler so far. And while we've
been discussing these fine topics here on c.o.v, the native Fortran compiler is about to appear. :)

On 27/02/2023 23:35, Arne Vajhøj wrote:
> On 2/27/2023 5:42 PM, David Wade wrote:
>> On 27/02/2023 20:58, Arne Vajhøj wrote:
>>> On 2/27/2023 11:49 AM, ultr...@gmail.com wrote:
>>>> On Thursday, February 23, 2023 at 5:05:50 PM UTC-5, Paul Gavin wrote:
>>>>> What, DEC C cannot be debugged?
>>>>> Working on some enhancements in a C based app on Alphas running 8.4.
>>>>> Can get to debugger just fine, step through code, look at data, set
>>>>> break points, etc., even from within ACMS.
>>>>
>>>> never debugged dec c but if the compiler debugger is anything like C
>>>> it is difficult ...
>>>
>>> The VMS C compiler behaves pretty much like other VMS compilers.
>>>
>>> The same VMS debugger is used for C as for any other
>>> (DEC/CPQ/HPE/VSI) language.
>>
>> I feel the issue with debugging "C" is that in order to effectively
>> use the debugger you tend to need to turn down optimisation, but
>> turning down optimization tends to make the code work as you expect.
>> When you turn it up again, undefined behaviour tends to re-emerge.
>
> /DEB/NOOP is not required but tend to make it easier to
> debug because there is a closer correlation between the
> instruction stream and the lines of source code.
>
> And as you point out then that can in fact by itself
> remove symptoms of a bug.
>
> But isn't that the case for all VMS compilers? I know
> I use /DEB/NOOP for both Fortran, Pascal and C when I want
> to debug.

Of course, BUT I feel other languages have fewer places where undefined
behaviour can occur, and so the problem is not so severe.

>
> Arne
>

On 2/28/2023 6:39 AM, David Wade wrote:
> On 27/02/2023 23:35, Arne Vajhøj wrote:
>> On 2/27/2023 5:42 PM, David Wade wrote:
>>> On 27/02/2023 20:58, Arne Vajhøj wrote:
>>>> On 2/27/2023 11:49 AM, ultr...@gmail.com wrote:
>>>>> On Thursday, February 23, 2023 at 5:05:50 PM UTC-5, Paul Gavin wrote:
>>>>>> What, DEC C cannot be debugged?
>>>>>> Working on some enhancements in a C based app on Alphas running 8.4.
>>>>>> Can get to debugger just fine, step through code, look at data,
>>>>>> set break points, etc., even from within ACMS.
>>>>>
>>>>> never debugged dec c but if the compiler debugger is anything like
>>>>> C it is difficult ...
>>>>
>>>> The VMS C compiler behaves pretty much like other VMS compilers.
>>>>
>>>> The same VMS debugger is used for C as for any other
>>>> (DEC/CPQ/HPE/VSI) language.
>>>
>>> I feel the issue with debugging "C" is that in order to effectively
>>> use the debugger you tend to need to turn down optimisation, but
>>> turning down optimization tends to make the code work as you expect.
>>> When you turn it up again, undefined behaviour tends to re-emerge.
>>
>> /DEB/NOOP is not required but tend to make it easier to
>> debug because there is a closer correlation between the
>> instruction stream and the lines of source code.
>>
>> And as you point out then that can in fact by itself
>> remove symptoms of a bug.
>>
>> But isn't that the case for all VMS compilers? I know
>> I use /DEB/NOOP for both Fortran, Pascal and C when I want
>> to debug.
>
> Of course, BUT I feel other languages have fewer places where undefined
> behaviour can occur, and so the problem is not so severe.
>

And then you have the case (it's been a long while but at one time
was very common in my experience) where turning off optimization
"fixes" the problem.

:-)

bill

On 2/28/2023 8:15 AM, bill wrote:
> On 2/28/2023 6:39 AM, David Wade wrote:
>> On 27/02/2023 23:35, Arne Vajhøj wrote:
>>> On 2/27/2023 5:42 PM, David Wade wrote:
>>>> I feel the issue with debugging "C" is that in order to effectively
>>>> use the debugger you tend to need to turn down optimisation, but
>>>> turning down optimization tends to make the code work as you expect.
>>>> When you turn it up again, undefined behaviour tends to re-emerge.
>>>
>>> /DEB/NOOP is not required but tend to make it easier to
>>> debug because there is a closer correlation between the
>>> instruction stream and the lines of source code.
>>>
>>> And as you point out then that can in fact by itself
>>> remove symptoms of a bug.
>>>
>>> But isn't that the case for all VMS compilers? I know
>>> I use /DEB/NOOP for both Fortran, Pascal and C when I want
>>> to debug.
>>
>> Of course, BUT I feel other languages have fewer places where
>> undefined behaviour can occur, and so the problem is not so severe.
>>
>
> And then you have the case (it's been a long while but at one time
> was very common in my experience) where turning off optimization
> "fixes" the problem.

I think it has been a code smell for several decades now.

But I also remember build scripts written for VAX C 3.x that
specified /NOOPT with a note saying that the program would
not work if compiled with /OPT. Tt was indicated several
times though that the code was right and the compiler was wrong.
Of course it was a bit fuzzy what right code really meant before
ANSI/ISO.

When DEC C 4.x hit the streets then things got better. And that
must be more than 30 years ago by now.

Arne

On 2/26/2023 4:24 PM, Arne Vajhøj wrote:
> On 2/26/2023 3:14 PM, bill wrote:
>> On 2/26/2023 10:05 AM, Johnny Billquist wrote:
>>> On 2023-02-25 13:00, Neil Rieck wrote:
>>>> comment: ISAM was important elsewhere on VMS including the fact that
>>>> SYSUAF.DAT was indexed
>>>
>>> Yeah, I don't think anything in RSTS/E or RSX on the system level
>>> used indexed files. VMS I know a little bit less, but since RMS
>>> integration went deeper in VMS, I'm not surprised if more things made
>>> use of it.
>>
>> Today, it is hard to imagine any reason for using ISAM/VSAM.  Small
>> Simple Databases like MySQL/MariaDB or SQLite can do a better job
>> and in most cases are probably just as easy to understand.
>
> RDBMS would be the default today. SQLite for embedded.
> MySQL/MariaDB or PostgreSQL or commercial for server.
>
> There are still use cases for ISAM or to use a more
> modern term NoSQL key value store. But I believe there
> is little intersection between those use cases and
> the use cases for Cobol today. Cobol is used for
> money and money is stored in RDBMS.

I just saw some statistics on database type usage:

https://thenewstack.io/how-to-choose-the-right-database-in-2023

RDBMS 71.9%
Document Store 10.4%
Key Value Store 5.7%
Search Engine 4.4%
Wide Column Store 2.9%
Graph DB 1.8%

RDBMS is definitely king.

For those that wonder what products these categories cover:

RDBMS = Oracle DB, MS SQLServer, IBM DB2, MySQL/MariaDB, PostgreSQL etc.
Document Store = MongoDB, CouchDB etc.
Key Value Store = BDB, RocksDB etc.
Search Engine = Lucene
Wide Column Store = Cassandra, HBase etc.
Graph DB = Neo4j, OrientDB etc.

Arne

In article <199e3e7c-d1b1-4726-be39-2500b1e08851n@googlegroups.com>,
John Reagan <xyzzy1959@gmail.com> wrote:
>[snip]
>By the way, thanks to all the folks who've beat up on the native C compiler so far. And while we've
>been discussing these fine topics here on c.o.v, the native Fortran compiler is about to appear. :)

That's fantastic news! Congratulations.

- Dan C.

On 2/27/2023 10:35 PM, John Reagan wrote:
> By the way, thanks to all the folks who've beat up on the native C compiler so far. And while we've
> been discussing these fine topics here on c.o.v, the native Fortran compiler is about to appear. :)

So C, C++ and Fortran are out (I have seen questions related to both C
and C++).

Cobol, Pascal and Basic to go. In that order? Maybe 3 months a piece?

Arne

On Monday, February 27, 2023 at 7:11:36 PM UTC-6, Robert A. Brooks wrote:
> On 2/27/2023 6:35 PM, Arne Vajhøj wrote:
>
> > But isn't that the case for all VMS compilers? I know
> > I use /DEB/NOOP for both Fortran, Pascal and C when I want
> > to debug.
> Reagan may weigh in here, but I'm pretty sure that DEC suggested using
> /DEBUG/NOOP when using the debugger for any language with an optimizer back in
> the 80's; if so, then that's been a pretty consistent message.
>
> --
>
> --- Rob
Speaking of debuggers.

I'm not clear on how you can actually debug a gnucobol program, since it's C in reality.

With NETCOBOL, as an example, debugging on Linux with gdb is much enhanced with our gdb extensions. When you're debugging across frames, and you have COBOL type variables to examine or modify, it helps to be able to see your COBOL code and ask to see the variables in the sometimes extensive COBOL structures; throw in an OCCURS x TIMES or more and it's a challenge. It's nice to be able to display the values as COBOL uses them.

Some customers really like to reuse coblib files and the names are the same across multiple structures. GDB doesn't know COBOL "var1 of struct1 of level1 var". But our extensions do.

On 2/28/2023 12:04 PM, Denys Beauchemin wrote:
> On Monday, February 27, 2023 at 7:11:36 PM UTC-6, Robert A. Brooks wrote:
>> On 2/27/2023 6:35 PM, Arne Vajhøj wrote:
>>
>>> But isn't that the case for all VMS compilers? I know
>>> I use /DEB/NOOP for both Fortran, Pascal and C when I want
>>> to debug.
>> Reagan may weigh in here, but I'm pretty sure that DEC suggested using
>> /DEBUG/NOOP when using the debugger for any language with an optimizer back in
>> the 80's; if so, then that's been a pretty consistent message.
>>
>> --
>>
>> --- Rob
> Speaking of debuggers.
>
> I'm not clear on how you can actually debug a gnucobol program, since it's C in reality.

To be honest, there probably isn't really a debugger for GnuCOBOL.
We really need to put this one misconception to rest. You are not
supposed to do anything with the C code generated by the GnuCOBOL
compiler. It's an intermediate language not intended for human
consumption. Every compiler I have worked with so far takes the
original source and converts it into some intermediate language.
Some use RTL. Some use assembler. GnuCOBOL uses C. RATFOR uses
Fortran. :-) We even have the Chung/Yuen Tiny Pascal which converted
to a P-code that could be further processed into 8080 Assembler and
then further processed into an executable for the Northstar.
None of these intended humans to read, understand or manipulate
the intermediate forms. So lets just ignore the fact that GnuCOBOL
converts COBOL into C. It really converts COBOL into an executable
program on the host computer just like every other compiler.

bill

In article <k66d38Ftd0kU10@mid.individual.net>,
bill <bill.gunshannon@gmail.com> wrote:
>> Of course, BUT I feel other languages have fewer places where undefined
>> behaviour can occur, and so the problem is not so severe.
>>
>
>And then you have the case (it's been a long while but at one time
>was very common in my experience) where turning off optimization
>"fixes" the problem.

Indeed; this is quite common. In the context of C and C++, this
is often a result of misunderstanding how "undefined behavior"
works. What UB actually means is that the language _imposes no
requirements_ when such behavior is detected (C11, sec 3.4.3).
So the compiler is free to implement any behavior it chooses.

The issue is that compiler writers have begun taking aggressive
advantage of this to use UB to push occasionally surprising
optimizations.

Consider, for example, this segment of code:

unsigned short
mul(unsigned short a, unsigned short b)
{ return a * b;
}

Is this always well-defined? Well, no, depending on the
platform. But why? It looks innocuous enough.

To understand this, consider a platform with 32-bit ints and
16-bit shorts. According to pretty much every version of the C
standard, before the multiplication is performed, the operands
will be subject to the, "usual arithmetic conversions" (C11 sec
6.3.1.8). In this case, the `unsigned short` operands have
lesser "rank" than `int`, and an `int` can represent the full
range of values representable in `unsigned short`, so the
"integer promotions" apply and the operands will be converted to
type `int` (C11 sec 6.3.1.1, para 2). The multiplication will
then be performed using _signed_ integer arithemtic. But note
that there exist unsigned 16-bit short values 'c' and 'd' such
that 'c * d' overflows a signed 32-bit int, and non-atomic
_signed_ integer overflow is undefined behavior in C (C11 sec
6.5 para 5; in this case, the product is not in the range of
representable values for type `int`).

The result is that the compiler is free to do whatever it wants
here. In practical terms, most compilers will produce code that
behaves as expected, but if a compiler decided to, for whatever
reason, emitting (say) a saturating multiplication instruction
instead of a a normal MUL, it would be entirely within its
rights to do so. Caveat emptor.

An issue with C code in particular is that it's almost
impossible to write a non-trivial program that doesn't have
_some_ UB in it, often hidden in ways that are not obvious to
the programmer (e.g., inside of a macro perhaps). So as
compilers evolve and become more aggressive, code that seems to
have worked for _years_ all of a sudden seems to spontaneously
break. Again, caveat emptor.

So yeah. Often turning off the optimizer appears to "fix"
programs. Heisenbugs indeed!

- Dan C.

On 2/28/23 10:38 AM, Arne Vajhøj wrote:
> On 2/27/2023 10:35 PM, John Reagan wrote:
>> By the way, thanks to all the folks who've beat up on the native C
>> compiler so far.  And while we've
>> been discussing these fine topics here on c.o.v, the native Fortran
>> compiler is about to appear. :)
>
> So C, C++ and Fortran are out (I have seen questions related to both C
> and C++).
>
> Cobol, Pascal and Basic to go. In that order? Maybe 3 months a piece?

Your guess is probably better than mine, but don't forget these are
field test releases and it's probably the same people fixing things in
existing compilers and working on the new ones. There might be a pause
where they fix all the gem2ir stuff that has come up with C and Fortran
before moving on to the other compilers. But then hopefully the later
compilers will be easier because more problems with the underpinnings
have already been shaken out.

On Tuesday, February 28, 2023 at 2:17:58 PM UTC-5, Craig A. Berry wrote:
> On 2/28/23 10:38 AM, Arne Vajhøj wrote:
> > On 2/27/2023 10:35 PM, John Reagan wrote:
> >> By the way, thanks to all the folks who've beat up on the native C
> >> compiler so far. And while we've
> >> been discussing these fine topics here on c.o.v, the native Fortran
> >> compiler is about to appear. :)
> >
> > So C, C++ and Fortran are out (I have seen questions related to both C
> > and C++).
> >
> > Cobol, Pascal and Basic to go. In that order? Maybe 3 months a piece?
> Your guess is probably better than mine, but don't forget these are
> field test releases and it's probably the same people fixing things in
> existing compilers and working on the new ones. There might be a pause
> where they fix all the gem2ir stuff that has come up with C and Fortran
> before moving on to the other compilers. But then hopefully the later
> compilers will be easier because more problems with the underpinnings
> have already been shaken out.

Not sure on the cadence. And yes, we're shaking things out right now especially
with regards to debugging information, impact on optimizations (we're still working
in that area), etc. I'll point out that the frontend for the Fortran compiler (written in C)
is compiled on OpenVMS x86 with the native C compiler. We're "eating our own
dogfood" as it were. And yes, we have native BLISS compilers too.

I sure hope I don't accidentally cut-n-paste into the wrong window...

PASCAL$ write sys$output f$getsyi("arch_name")
x86_64
PASCAL$ pascal/vers
VSI Pascal x86-64 X6.3-136 (50X2D) on OpenVMS x86-64 V9.2
PASCAL$ pascal hw
PASCAL$ link hw
PASCAL$ run hw
hello world 10
PASCAL$

John Reagan <xyzzy1959@gmail.com> wrote:
>Debugging optimized code has been the Holy Grail for years. On Alpha, GEM =
>and the debugger have
>some attempt at make it possible but it wasn't perfect. Later DWARF standa=
>rds have added additional
>features for compilers to use to help convey the transformations used by th=
>e compiler, but it still a
>challenge to present to the human in a way that makes sense. And of course=
>, if the original source
>program was technically illegal (which might be why you are in the debugger=
> to start with), optimizers
>will often do unspeakable transformations to such invalid programs. =20

gus baird always said "You don't need a debugger. What you need is to stop
putting bugs in your programs."
--scott

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

On 2/28/2023 6:39 PM, Scott Dorsey wrote:
>
>
> gus baird always said "You don't need a debugger. What you need is to stop
> putting bugs in your programs."

Which is great if it is you putting the bugs in and not the compiler.

bill