On 2/28/2023 6:39 PM, Scott Dorsey wrote:
> 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."

And Dijkstra said:

"If debugging is the process of removing software bugs, then programming
must be the process of putting them in."

But we live in the real world.

The old rule of thumb says 1 bug per 1000 LOC. So 50 MLOC means
50000 bugs.

Arne

bill <bill.gunshannon@gmail.com> wrote:
>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.

True. But unfortunately if the compiler is putting the bugs in, the debugger
is probably not of much use anyway.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."

John Reagan schrieb am Dienstag, 28. Februar 2023 um 21:16:56 UTC+1:
> 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$
Hey, that looks great. Please give me more.
Andreas

On 2023-02-28 18:53, bill wrote:
> 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.

All very true. But that does not change the fact that when you point a
debugger at it, it will trace the binary back to C, not Cobol, unless
you extend the debugger to do the reversing of the C to the original
Cobol code. And unless you do some tricks to the C compiler, a debugger
don't even have a way to know that it wasn't originally C code.

But it is the same kind of problems all those other languages also have,
and in fact even native compiled languages. After all, the debugger only
sees the machine code, and hopefully a bunch of symbols and other
meta-data the compiler left behind.

Johnny

On 2023-02-28 20:11, Dan Cross wrote:
> 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!

You overcomplicated the whole explanation.
Basically, if you multiply two numbers, and the result would be bigger
than the types involved, the result is undefined. In this case, the type
is unsigned short. If the multiplication cause anything that don't fit
into an unsigned short, then the result is undefined.

And it's fairly easy to find two unsigned short numbers that when
multiplied will give a result that don't fit into an unsigned short.

It's really not that different from any other language. Some languages
will throw an exception, others will just give some result that might or
might not be meaningful. But there is no guarantee in almost any
language of some kind of specific meaningful result. Try it in FORTRAN
and see what you get there, or Cobol (or BASIC). :-)

Johnny

On 2023-03-01 02:09, Scott Dorsey wrote:
> bill <bill.gunshannon@gmail.com> wrote:
>> 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.
>
> True. But unfortunately if the compiler is putting the bugs in, the debugger
> is probably not of much use anyway.

Depends. I've found one case of a gcc bug where a debugger showed the
problem just fine.

However, the statement can be applied recursively to the compiler as
well. Stop putting bugs in the compiler.

Johnny

Johnny Billquist <bqt@softjar.se> wrote:
>All very true. But that does not change the fact that when you point a
>debugger at it, it will trace the binary back to C, not Cobol, unless
>you extend the debugger to do the reversing of the C to the original
>Cobol code. And unless you do some tricks to the C compiler, a debugger
>don't even have a way to know that it wasn't originally C code.

Doesn't gnucobol do that? I thought gdb did that just fine.

The original g77 used the Bell Labs f2c translator in front of gcc and
it often didn't work very well and debugging was occasionally an adventure
but it was better than you'd ever expect. Not that I was not delighted when
the natrive gfortran compiler finally came out.

>But it is the same kind of problems all those other languages also have,
>and in fact even native compiled languages. After all, the debugger only
>sees the machine code, and hopefully a bunch of symbols and other
>meta-data the compiler left behind.

When you have a precompiler and a compiler then you have twice as many
places for bugs to exist.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."

In article <ttnk0m$lg5$2@news.misty.com>,
Johnny Billquist <bqt@softjar.se> wrote:
>On 2023-02-28 20:11, Dan Cross wrote:
>> 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!
>
>You overcomplicated the whole explanation.

Hmm.

>Basically, if you multiply two numbers, and the result would be bigger
>than the types involved, the result is undefined.

Well...no. _unsigned_ integer overflow in C is well-defined (it
has modular wrapping semantics; C11 sec 6.2.5 para 9).
Similarly, overflow of signed atomics is well-defined (C11 sec
7.17.7.5 para 3), so this is not always true.

>In this case, the type
>is unsigned short. If the multiplication cause anything that don't fit
>into an unsigned short, then the result is undefined.
>
>And it's fairly easy to find two unsigned short numbers that when
>multiplied will give a result that don't fit into an unsigned short.

The range of unsigned short has little to do with it, and
truncation of the result is fine too (again, defined to use
modular wrapping for unsigned types; C11 sec 6.3.1.3). The
problem is entirely due to the promotion to _signed_ int prior
to the multiplication. The fix, incidentally, is easy:

unsigned short
mul(unsigned short a, unsigned short b)
{ unsigned int aa = a, bb = b;
return aa * bb;
}

This is well-defined, even if the range of `unsigned short` is
the same as `unsigned int`, which is permitted by the standard.

>It's really not that different from any other language. Some languages
>will throw an exception, others will just give some result that might or
>might not be meaningful. But there is no guarantee in almost any
>language of some kind of specific meaningful result. Try it in FORTRAN
>and see what you get there, or Cobol (or BASIC). :-)

The issue, and the reason for the complex initial explanation,
is the subtle interaction between the implicit type promotion
rules, arithmetic, undefined behavior, and the freedom that UB
gives to compiler writers, which is pretty unique to C. Hence
why optimizing compilers often _appear_ to introduce bugs when
in fact they're performing perfectly legal transformations, and
turning off the optimizer can appear to "fix" the problem.

- Dan C.

On 3/1/2023 8:31 AM, Johnny Billquist wrote:
> On 2023-03-01 02:09, Scott Dorsey wrote:
>> bill  <bill.gunshannon@gmail.com> wrote:
>>> 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.
>>
>> True.  But unfortunately if the compiler is putting the bugs in, the
>> debugger
>> is probably not of much use anyway.
>
> Depends. I've found one case of a gcc bug where a debugger showed the
> problem just fine.
>
> However, the statement can be applied recursively to the compiler as
> well. Stop putting bugs in the compiler.

Or backdoors. :-)

bill

On 3/1/2023 8:21 AM, Johnny Billquist wrote:
> On 2023-02-28 18:53, bill wrote:
>> 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.
>
> All very true. But that does not change the fact that when you point a
> debugger at it, it will trace the binary back to C, not Cobol, unless
> you extend the debugger to do the reversing of the C to the original
> Cobol code. And unless you do some tricks to the C compiler, a debugger
> don't even have a way to know that it wasn't originally C code.
>
> But it is the same kind of problems all those other languages also have,
> and in fact even native compiled languages. After all, the debugger only
> sees the machine code, and hopefully a bunch of symbols and other
> meta-data the compiler left behind.

Looks like COBOL is still stuck with
SOURCE-COMPUTER. source-computer-entry [WITH DEBUGGING MODE].

:-)

bill

On 2/28/2023 2:11 PM, Dan Cross wrote:
>
>
> Consider, for example, this segment of code:
>
> unsigned short
> mul(unsigned short a, unsigned short b)
> {
> return a * b;
> }
>

I have always considered this to be really stupid code.
For the vast majority of values for a and b this is going to
overflow. That means that regardless of what "undefined behavior"
actually means the result will be useless.

What were we just saying about programmers not writing buggy code?

bill

In article <k69hofFu2e4U2@mid.individual.net>,
bill <bill.gunshannon@gmail.com> wrote:
>On 2/28/2023 2:11 PM, Dan Cross wrote:
>>
>>
>> Consider, for example, this segment of code:
>>
>> unsigned short
>> mul(unsigned short a, unsigned short b)
>> {
>> return a * b;
>> }
>
>I have always considered this to be really stupid code.
>For the vast majority of values for a and b this is going to
>overflow. That means that regardless of what "undefined behavior"
>actually means the result will be useless.

?? Sure, this is a contrived example, but what makes you think
that the original programmer didn't want the wrapping behavior
on overflow?

It's a contrived example, but having well-defined overflow
semantics is actually really useful; consider checksumming
and hashing functions. Or, for that matter, cryptographic
code (which often makes heavy use of modular arithmetic).

Yeah, this example is dumb, but there are plenty of similar
examples that are not. For example, consider this checksum:

unsigned char
checksum(const unsigned char *p, size_t n)
{ unsigned char c = 0;

for (size_t i = 0; i < n; i++)
c += *p++;

return 0 - c;
}

Is that well-defined? One may look at it and say, "yes, of
course; there's no way that the addition can overflow because
both 8-bit `unsigned char` operands will be converted to any
flavor of `int`, and that cannot overflow."

Except that there are implementations where the range of `int`
and `unsigned char` are the same, and on those, overflow _could_
occur.

So, one should, instead, write:

unsigned char
checksum(const unsigned char *p, size_t n)
{ unsigned int c = 0;

for (size_t i = 0; i < n; i++)
c += *p++;

return 0 - c;
}

Subtle, no?

>What were we just saying about programmers not writing buggy code?

Good luck with that. :-)

- Dan C.

On Wednesday, March 1, 2023 at 6:21:54 AM UTC-7, Johnny Billquist wrote:
> On 2023-02-28 18:53, bill wrote:
> > 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.
<snip>
> Johnny

Speaking of debugging GnuCobol (nee open-cobol)
https://lists.gnu.org/archive/html/gnucobol-users/2009-06/msg00003.html
I can't say why I never followed up. Anyway, it looks like the problem's been solved in the meanwhile.

On Thursday, March 2, 2023 at 6:08:00 AM UTC-7, plugh wrote:
> On Wednesday, March 1, 2023 at 6:21:54 AM UTC-7, Johnny Billquist wrote:
> > On 2023-02-28 18:53, bill wrote:
> > > 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.
> <snip>
> > Johnny
>
> Speaking of debugging GnuCobol (nee open-cobol)
> https://lists.gnu.org/archive/html/gnucobol-users/2009-06/msg00003.html
> I can't say why I never followed up. Anyway, it looks like the problem's been solved in the meanwhile.

Sorry, I think that was bill, not Johnny

On 3/2/2023 8:14 AM, plugh wrote:
> On Thursday, March 2, 2023 at 6:08:00 AM UTC-7, plugh wrote:
>> On Wednesday, March 1, 2023 at 6:21:54 AM UTC-7, Johnny Billquist wrote:
>>> On 2023-02-28 18:53, bill wrote:
>>>> 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.
>> <snip>
>>> Johnny
>>
>> Speaking of debugging GnuCobol (nee open-cobol)
>> https://lists.gnu.org/archive/html/gnucobol-users/2009-06/msg00003.html
>> I can't say why I never followed up. Anyway, it looks like the problem's been solved in the meanwhile.
>
> Sorry, I think that was bill, not Johnny

None of the included content was from me. Not sure if any of it was
from Johnny but I don't think so.

bill

In article <k6btpvFu2e4U4@mid.individual.net>,
bill <bill.gunshannon@gmail.com> wrote:
>On 3/2/2023 8:14 AM, plugh wrote:
>> On Thursday, March 2, 2023 at 6:08:00 AM UTC-7, plugh wrote:
>>> On Wednesday, March 1, 2023 at 6:21:54 AM UTC-7, Johnny Billquist wrote:
>>>> On 2023-02-28 18:53, bill wrote:
>>>>> 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.
>>> <snip>
>>>> Johnny
>>>
>>> Speaking of debugging GnuCobol (nee open-cobol)
>>> https://lists.gnu.org/archive/html/gnucobol-users/2009-06/msg00003.html
>>> I can't say why I never followed up. Anyway, it looks like the problem's been solved in the meanwhile.
>>
>> Sorry, I think that was bill, not Johnny
>
>None of the included content was from me. Not sure if any of it was
>from Johnny but I don't think so.

The proximal content was from Denys Beauchemin in
<be08c3cc-3990-401b-97d1-2cdf4ad92484n@googlegroups.com>.

The ">>>> Johnny" thing appears to be a text editing error,
because the response was cutting from many levels of quotation
(responses to responses to...).

- Dan C.

Damn! I learned something new today...

On 2023-03-01 15:54, Dan Cross wrote:
> In article <ttnk0m$lg5$2@news.misty.com>,
> Johnny Billquist <bqt@softjar.se> wrote:
>> On 2023-02-28 20:11, Dan Cross wrote:

[...]

>> You overcomplicated the whole explanation.
>
> Hmm.

I was wrong. :-)

>> Basically, if you multiply two numbers, and the result would be bigger
>> than the types involved, the result is undefined.
>
> Well...no. _unsigned_ integer overflow in C is well-defined (it
> has modular wrapping semantics; C11 sec 6.2.5 para 9).
> Similarly, overflow of signed atomics is well-defined (C11 sec
> 7.17.7.5 para 3), so this is not always true.

I had actually missed that unsigned integers do have a defined overflow
behavior. Thanks.

>> In this case, the type
>> is unsigned short. If the multiplication cause anything that don't fit
>> into an unsigned short, then the result is undefined.
>>
>> And it's fairly easy to find two unsigned short numbers that when
>> multiplied will give a result that don't fit into an unsigned short.
>
> The range of unsigned short has little to do with it, and
> truncation of the result is fine too (again, defined to use
> modular wrapping for unsigned types; C11 sec 6.3.1.3). The
> problem is entirely due to the promotion to _signed_ int prior
> to the multiplication. The fix, incidentally, is easy:
>
> unsigned short
> mul(unsigned short a, unsigned short b)
> {
> unsigned int aa = a, bb = b;
> return aa * bb;
> }
>
> This is well-defined, even if the range of `unsigned short` is
> the same as `unsigned int`, which is permitted by the standard.

Right. My second error. It is allowed to promote a unsigned short to a
signed int.
I do feel that I don't entirely agree with that rule, but it's
definitely written as such.

Changing from unsigned to signed feels just as a freedom too much.

>> It's really not that different from any other language. Some languages
>> will throw an exception, others will just give some result that might or
>> might not be meaningful. But there is no guarantee in almost any
>> language of some kind of specific meaningful result. Try it in FORTRAN
>> and see what you get there, or Cobol (or BASIC). :-)
>
> The issue, and the reason for the complex initial explanation,
> is the subtle interaction between the implicit type promotion
> rules, arithmetic, undefined behavior, and the freedom that UB
> gives to compiler writers, which is pretty unique to C. Hence
> why optimizing compilers often _appear_ to introduce bugs when
> in fact they're performing perfectly legal transformations, and
> turning off the optimizer can appear to "fix" the problem.

Yup. You were right. Sorry that I had to go and read the spec again.
Trusting my brain was obviously the wrong thing to do.

Johnny

On 3/3/2023 6:59 AM, Johnny Billquist wrote:
> Damn! I learned something new today...
>
> On 2023-03-01 15:54, Dan Cross wrote:
>> In article <ttnk0m$lg5$2@news.misty.com>,
>> Johnny Billquist  <bqt@softjar.se> wrote:
>>> On 2023-02-28 20:11, Dan Cross wrote:
>
> [...]
>
>>> You overcomplicated the whole explanation.
>>
>> Hmm.
>
> I was wrong. :-)
>
>>> Basically, if you multiply two numbers, and the result would be bigger
>>> than the types involved, the result is undefined.
>>
>> Well...no.  _unsigned_ integer overflow in C is well-defined (it
>> has modular wrapping semantics; C11 sec 6.2.5 para 9).
>> Similarly, overflow of signed atomics is well-defined (C11 sec
>> 7.17.7.5 para 3), so this is not always true.
>
> I had actually missed that unsigned integers do have a defined overflow
> behavior. Thanks.
>
>>> In this case, the type
>>> is unsigned short. If the multiplication cause anything that don't fit
>>> into an unsigned short, then the result is undefined.
>>>
>>> And it's fairly easy to find two unsigned short numbers that when
>>> multiplied will give a result that don't fit into an unsigned short.
>>
>> The range of unsigned short has little to do with it, and
>> truncation of the result is fine too (again, defined to use
>> modular wrapping for unsigned types; C11 sec 6.3.1.3).  The
>> problem is entirely due to the promotion to _signed_ int prior
>> to the multiplication.  The fix, incidentally, is easy:
>>
>> unsigned short
>> mul(unsigned short a, unsigned short b)
>> {
>>     unsigned int aa = a, bb = b;
>>     return aa * bb;
>> }
>>
>> This is well-defined, even if the range of `unsigned short` is
>> the same as `unsigned int`, which is permitted by the standard.
>
> Right. My second error. It is allowed to promote a unsigned short to a
> signed int.
> I do feel that I don't entirely agree with that rule, but it's
> definitely written as such.
>
> Changing from unsigned to signed feels just as a freedom too much.
>
>>> It's really not that different from any other language. Some languages
>>> will throw an exception, others will just give some result that might or
>>> might not be meaningful. But there is no guarantee in almost any
>>> language of some kind of specific meaningful result. Try it in FORTRAN
>>> and see what you get there, or Cobol (or BASIC). :-)
>>
>> The issue, and the reason for the complex initial explanation,
>> is the subtle interaction between the implicit type promotion
>> rules, arithmetic, undefined behavior, and the freedom that UB
>> gives to compiler writers, which is pretty unique to C.  Hence
>> why optimizing compilers often _appear_ to introduce bugs when
>> in fact they're performing perfectly legal transformations, and
>> turning off the optimizer can appear to "fix" the problem.
>
> Yup. You were right. Sorry that I had to go and read the spec again.
> Trusting my brain was obviously the wrong thing to do.
>

And it really doesn't matter whether the result is truncation,
conversion to signed int, wrap around, throwing an exception or
undefined. The answer is still going to be wrong and the calculation
worthless. So, what's the point? Fix the damn code.

Go ahead, blame the language again.

bill

On 3/3/2023 7:42 AM, bill wrote:
> On 3/3/2023 6:59 AM, Johnny Billquist wrote:
>> On 2023-03-01 15:54, Dan Cross wrote:
>>> In article <ttnk0m$lg5$2@news.misty.com>,
>>> Johnny Billquist  <bqt@softjar.se> wrote:
>>>> Basically, if you multiply two numbers, and the result would be bigger
>>>> than the types involved, the result is undefined.
>>>
>>> Well...no.  _unsigned_ integer overflow in C is well-defined (it
>>> has modular wrapping semantics; C11 sec 6.2.5 para 9).
>>> Similarly, overflow of signed atomics is well-defined (C11 sec
>>> 7.17.7.5 para 3), so this is not always true.
>>
>> I had actually missed that unsigned integers do have a defined
>> overflow behavior.

>> Yup. You were right. Sorry that I had to go and read the spec again.

> And it really doesn't matter whether the result is truncation,
> conversion to signed int, wrap around, throwing an exception or
> undefined.  The answer is still going to be wrong and the calculation
> worthless.  So, what's the point?  Fix the damn code.
>
> Go ahead, blame the language again.

I do.

:-)

The choice that provide the safest code is to throw
an exception at integer overflow.

For the cases where modulus 2^n math make sense, then
either the developer would need to move data to a bigger
data type and do an explicit modulus or the language
could support:

modulus_math_only_use_if_you_know_what_you_are_doing {
// code
}

Arne

In article <k6e8a5Fu2e4U5@mid.individual.net>,
bill <bill.gunshannon@gmail.com> wrote:
>On 3/3/2023 6:59 AM, Johnny Billquist wrote:
>> Damn! I learned something new today...
>>
>> On 2023-03-01 15:54, Dan Cross wrote:
>>> In article <ttnk0m$lg5$2@news.misty.com>,
>>> Johnny Billquist  <bqt@softjar.se> wrote:
>>>> On 2023-02-28 20:11, Dan Cross wrote:
>>
>> [...]
>>
>>>> You overcomplicated the whole explanation.
>>>
>>> Hmm.
>>
>> I was wrong. :-)
>>
>>>> Basically, if you multiply two numbers, and the result would be bigger
>>>> than the types involved, the result is undefined.
>>>
>>> Well...no.  _unsigned_ integer overflow in C is well-defined (it
>>> has modular wrapping semantics; C11 sec 6.2.5 para 9).
>>> Similarly, overflow of signed atomics is well-defined (C11 sec
>>> 7.17.7.5 para 3), so this is not always true.
>>
>> I had actually missed that unsigned integers do have a defined overflow
>> behavior. Thanks.
>>
>>>> In this case, the type
>>>> is unsigned short. If the multiplication cause anything that don't fit
>>>> into an unsigned short, then the result is undefined.
>>>>
>>>> And it's fairly easy to find two unsigned short numbers that when
>>>> multiplied will give a result that don't fit into an unsigned short.
>>>
>>> The range of unsigned short has little to do with it, and
>>> truncation of the result is fine too (again, defined to use
>>> modular wrapping for unsigned types; C11 sec 6.3.1.3).  The
>>> problem is entirely due to the promotion to _signed_ int prior
>>> to the multiplication.  The fix, incidentally, is easy:
>>>
>>> unsigned short
>>> mul(unsigned short a, unsigned short b)
>>> {
>>>     unsigned int aa = a, bb = b;
>>>     return aa * bb;
>>> }
>>>
>>> This is well-defined, even if the range of `unsigned short` is
>>> the same as `unsigned int`, which is permitted by the standard.
>>
>> Right. My second error. It is allowed to promote a unsigned short to a
>> signed int.
>> I do feel that I don't entirely agree with that rule, but it's
>> definitely written as such.
>>
>> Changing from unsigned to signed feels just as a freedom too much.
>>
>>>> It's really not that different from any other language. Some languages
>>>> will throw an exception, others will just give some result that might or
>>>> might not be meaningful. But there is no guarantee in almost any
>>>> language of some kind of specific meaningful result. Try it in FORTRAN
>>>> and see what you get there, or Cobol (or BASIC). :-)
>>>
>>> The issue, and the reason for the complex initial explanation,
>>> is the subtle interaction between the implicit type promotion
>>> rules, arithmetic, undefined behavior, and the freedom that UB
>>> gives to compiler writers, which is pretty unique to C.  Hence
>>> why optimizing compilers often _appear_ to introduce bugs when
>>> in fact they're performing perfectly legal transformations, and
>>> turning off the optimizer can appear to "fix" the problem.
>>
>> Yup. You were right. Sorry that I had to go and read the spec again.
>> Trusting my brain was obviously the wrong thing to do.
>>
>
>And it really doesn't matter whether the result is truncation,
>conversion to signed int, wrap around, throwing an exception or
>undefined. The answer is still going to be wrong and the calculation
>worthless. So, what's the point? Fix the damn code.

Bill, do you understand that there are application domains where
people want well-defined modular arithmetic on unsigned types?
You seem intent on dismissing this as a valid use case, by
repeatedly that the results are "worthless." As I pointed out
to you earlier in this thread, wrapping semantics can be very
useful.

>Go ahead, blame the language again.

Ok. I blame the language for having confuing semantics, and I
blame compiler writer for exploiting that at the expense of
programmers.

- Dan C.

In article <ttsne6$ro6$1@news.misty.com>,
Johnny Billquist <bqt@softjar.se> wrote:
>[snip]
>I do feel that I don't entirely agree with that rule, but it's
>definitely written as such.
>
>Changing from unsigned to signed feels just as a freedom too much.

For the record, I agree with you.

>[snip]
>Yup. You were right. Sorry that I had to go and read the spec again.
>Trusting my brain was obviously the wrong thing to do.

No problem!

- Dan C.

On 3/3/2023 8:45 AM, Arne Vajhøj wrote:
> On 3/3/2023 7:42 AM, bill wrote:
>> And it really doesn't matter whether the result is truncation,
>> conversion to signed int, wrap around, throwing an exception or
>> undefined.  The answer is still going to be wrong and the calculation
>> worthless.  So, what's the point?  Fix the damn code.
>>
>> Go ahead, blame the language again.
>
> I do.
>
> :-)
>
> The choice that provide the safest code is to throw
> an exception at integer overflow.
>
> For the cases where modulus 2^n math make sense, then
> either the developer would need to move data to a bigger
> data type and do an explicit modulus or the language
> could support:
>
> modulus_math_only_use_if_you_know_what_you_are_doing {
>     // code
> }

Compare:

C (on VMS as this is comp.os.vms !):

$ type ovf.c
#include <stdio.h>

int main(int argc, char *argv[])
{ unsigned int pop;
unsigned int gdppercap;
unsigned int gdp;
pop = 300000000U;
gdppercap = 50000U;
gdp = pop * gdppercap;
(void)printf("%u people @ %u dollars = %u dollars\n", pop,
gdppercap, gdp);
return 0;
} $ cc/warn=ena:all ovf
$ link ovf
$ run ovf
300000000 people @ 50000 dollars = 1974202368 dollars
$ type bit.c
#include <stdio.h>

int main(int argc, char *argv[])
{ unsigned int word;
word = 0xF0F0F0F0U;
(void)printf("%08X\n", word);
word = word * 2U;
(void)printf("%08X\n", word);
return 0;
} $ cc/warn=ena:all bit
$ link bit
$ run bit
F0F0F0F0
E1E1E1E0

C# (not available on VMS so ...):

C:\Work>type ovf.cs
using System;

public class Program
{ public static void Main(string[] args)
{
uint pop;
uint gdppercap;
uint gdp;
pop = 300000000U;
gdppercap = 50000U;
gdp = pop * gdppercap;
Console.WriteLine("{0} people @ {1} dollars = {2} dollars\n",
pop, gdppercap, gdp);
}
}

C:\Work>csc ovf.cs
Microsoft (R) Visual C# Compiler version 4.3.0-3.22470.13 (80a8ce8d)
Copyright (C) Microsoft Corporation. All rights reserved.

C:\Work>ovf
300000000 people @ 50000 dollars = 1974202368 dollars

C:\Work>csc /checked+ ovf.cs
Microsoft (R) Visual C# Compiler version 4.3.0-3.22470.13 (80a8ce8d)
Copyright (C) Microsoft Corporation. All rights reserved.

C:\Work>ovf
Unhandled Exception: System.OverflowException: Arithmetic operation
resulted in
an overflow.
at Program.Main(String[] args)

C:\Work>type bit.cs
using System;

public class Program
{ public static void Main(string[] args)
{
uint word;
word = 0xF0F0F0F0U;
Console.WriteLine("{0,8:X}", word);
word = unchecked(word * 2U);
Console.WriteLine("{0,8:X}", word);
}
}

C:\Work>csc bit.cs
Microsoft (R) Visual C# Compiler version 4.3.0-3.22470.13 (80a8ce8d)
Copyright (C) Microsoft Corporation. All rights reserved.

C:\Work>bit
F0F0F0F0
E1E1E1E0

C:\Work>csc /checked+ bit.cs
Microsoft (R) Visual C# Compiler version 4.3.0-3.22470.13 (80a8ce8d)
Copyright (C) Microsoft Corporation. All rights reserved.

C:\Work>bit
F0F0F0F0
E1E1E1E0

(note that /checked+ is not default)

Arne

On 2/12/2023 2:34 PM, Arne Vajhøj wrote:
> VMS Tech Demo 6 - converting files between VMS Cobol and GnuCOBOL:
>   https://www.vajhoej.dk/arne/articles/vmstd6.html

Examples added for when GnuCOBOL use VBISAM
instead of BDB for indexed files.

BDB is technically better than VBISAM, but the license
for VBISAM (LGPL) is more attractive for some than the
license for BDB (AGPL or Oracle commercial).

GnuCOBOL with VBISAM is easy for Windows as Arnold Trembley
provides builds for none, BDB and VBISAM.

GnuCOBOL with VBISAM for Linux requires an "old fashioned"
build:
* get the prerequisites ready
* get the source
* configure --with-vbisam
* make
and all the associated fun.

Arne

On 2023-03-03 13:42, bill wrote:
> On 3/3/2023 6:59 AM, Johnny Billquist wrote:
>> Damn! I learned something new today...
>>
>> On 2023-03-01 15:54, Dan Cross wrote:
>>> In article <ttnk0m$lg5$2@news.misty.com>,
>>> Johnny Billquist  <bqt@softjar.se> wrote:
>>>> On 2023-02-28 20:11, Dan Cross wrote:
>>
>> [...]
>>
>>>> You overcomplicated the whole explanation.
>>>
>>> Hmm.
>>
>> I was wrong. :-)
>>
>>>> Basically, if you multiply two numbers, and the result would be bigger
>>>> than the types involved, the result is undefined.
>>>
>>> Well...no.  _unsigned_ integer overflow in C is well-defined (it
>>> has modular wrapping semantics; C11 sec 6.2.5 para 9).
>>> Similarly, overflow of signed atomics is well-defined (C11 sec
>>> 7.17.7.5 para 3), so this is not always true.
>>
>> I had actually missed that unsigned integers do have a defined
>> overflow behavior. Thanks.
>>
>>>> In this case, the type
>>>> is unsigned short. If the multiplication cause anything that don't fit
>>>> into an unsigned short, then the result is undefined.
>>>>
>>>> And it's fairly easy to find two unsigned short numbers that when
>>>> multiplied will give a result that don't fit into an unsigned short.
>>>
>>> The range of unsigned short has little to do with it, and
>>> truncation of the result is fine too (again, defined to use
>>> modular wrapping for unsigned types; C11 sec 6.3.1.3).  The
>>> problem is entirely due to the promotion to _signed_ int prior
>>> to the multiplication.  The fix, incidentally, is easy:
>>>
>>> unsigned short
>>> mul(unsigned short a, unsigned short b)
>>> {
>>>     unsigned int aa = a, bb = b;
>>>     return aa * bb;
>>> }
>>>
>>> This is well-defined, even if the range of `unsigned short` is
>>> the same as `unsigned int`, which is permitted by the standard.
>>
>> Right. My second error. It is allowed to promote a unsigned short to a
>> signed int.
>> I do feel that I don't entirely agree with that rule, but it's
>> definitely written as such.
>>
>> Changing from unsigned to signed feels just as a freedom too much.
>>
>>>> It's really not that different from any other language. Some languages
>>>> will throw an exception, others will just give some result that
>>>> might or
>>>> might not be meaningful. But there is no guarantee in almost any
>>>> language of some kind of specific meaningful result. Try it in FORTRAN
>>>> and see what you get there, or Cobol (or BASIC). :-)
>>>
>>> The issue, and the reason for the complex initial explanation,
>>> is the subtle interaction between the implicit type promotion
>>> rules, arithmetic, undefined behavior, and the freedom that UB
>>> gives to compiler writers, which is pretty unique to C.  Hence
>>> why optimizing compilers often _appear_ to introduce bugs when
>>> in fact they're performing perfectly legal transformations, and
>>> turning off the optimizer can appear to "fix" the problem.
>>
>> Yup. You were right. Sorry that I had to go and read the spec again.
>> Trusting my brain was obviously the wrong thing to do.
>>
>
> And it really doesn't matter whether the result is truncation,
> conversion to signed int, wrap around, throwing an exception or
> undefined.  The answer is still going to be wrong and the calculation
> worthless.  So, what's the point?  Fix the damn code.
>
> Go ahead, blame the language again.

No. I don't fully agree. The fact that unsigned types are defined to
have the wrapping behavior means that you could definitely do this
intentionally and for rather good reasons.

But the type propagation rule here breaks that promise, which is what I
find *very* broken. I do consider it a error in the language
specification when this can happen.

Johnny

On 2023-03-03 14:45, Arne Vajhøj wrote:
> On 3/3/2023 7:42 AM, bill wrote:
>> On 3/3/2023 6:59 AM, Johnny Billquist wrote:
>>> On 2023-03-01 15:54, Dan Cross wrote:
>>>> In article <ttnk0m$lg5$2@news.misty.com>,
>>>> Johnny Billquist  <bqt@softjar.se> wrote:
>>>>> Basically, if you multiply two numbers, and the result would be bigger
>>>>> than the types involved, the result is undefined.
>>>>
>>>> Well...no.  _unsigned_ integer overflow in C is well-defined (it
>>>> has modular wrapping semantics; C11 sec 6.2.5 para 9).
>>>> Similarly, overflow of signed atomics is well-defined (C11 sec
>>>> 7.17.7.5 para 3), so this is not always true.
>>>
>>> I had actually missed that unsigned integers do have a defined
>>> overflow behavior.
>
>>> Yup. You were right. Sorry that I had to go and read the spec again.
>
>> And it really doesn't matter whether the result is truncation,
>> conversion to signed int, wrap around, throwing an exception or
>> undefined.  The answer is still going to be wrong and the calculation
>> worthless.  So, what's the point?  Fix the damn code.
>>
>> Go ahead, blame the language again.
>
> I do.
>
> :-)
>
> The choice that provide the safest code is to throw
> an exception at integer overflow.

C don't have exceptions. And it can be argues if that is safe as well.

> For the cases where modulus 2^n math make sense, then
> either the developer would need to move data to a bigger
> data type and do an explicit modulus or the language
> could support:

The sad thing is that C is basically saying that this should be done
with 2^n modulus math. However, the rule saying that a unsigned short
can be propagated to a signed int is fucking you over. Technically, it's
ok since a signed int can fit all values that an unsigned short can.
However, a signed int is not defined to have a 2^n modulus behavior, so
in essence, behind your back, the compiler changed to a type with a
different behavior which invalidates something you expected/were
promised by the language.

Johnny