Interesting bug

[Dave Vandervies]

I just fixed a bug that some of the correctness pedants around here may
find useful as ammunition.
The problem was that some code would, very occasionally, die with a
segmentation violation error. (Not as infrequent as some bugs that
have been discussed here in the past, but maybe once in an overnight
run of the program when it was configured to aggressively exercise the
section that the bug was in.) It was easy enough to trap the error
(using compiler features that are beyond the scope of this newsgroup)
and retry, and the retry would always work, but the glitch was still
Annoying to me and one other correctness pedant I work with.

Turns out that the offending code looked something like this:

for(i=0;i<num;i++)
if(check(array[i]))
break;
if(check(array[i]))
continue;

array was a pointer to a malloc'd array of num structs; check() was
an expression that compared a member of the struct to another value.
(If the values matched, we didn't need to do anything more in the
next-outer loop.)

But if the for loop failed to exit abnormally, the check after it exited
would attempt to read the value just past the end of the malloc'd space.

My best guess about what the problem was is that normally this wasn't a
problem, since the bogus value was Highly Unlikely to match what it was
being checked against and the program was allowed to read that memory
(and didn't try to write to it), but occasionally the mallocd space would
be just at the high end of the process's memory space and attempting to
read a few bytes past it would access memory that the process didn't own,
and the OS would trap it.
This may be useful the next time somebody comes around and tries to
claim that "It works on my system" or something similar.
Comments?
dave

--
Dave Vandervies dj******@csclub.uwaterloo.ca
Welcome to comp.lang.c. People here are picky. That's good - it means you can
(generally) trust the answers you get - or at least, you can trust the answer
that emerges after a couple of days of bickering. --Richard Heathfield in CLC

[Dan Pop]

In <c6**********@oravannahka.helsinki.fi> Joona I Palaste <pa*****@cc.helsinki.fi> writes:

A fully interpreted BASIC that scanned the actual source code as the
program progressed caused lots of interesting things. For example,
short line numbers actually performed better than long ones. Also
variables were faster than literal numbers. This was obvious, really,
as scanning a literal number required a decimal-to-binary conversion
but scanning a variable only required a table lookup. Thus several
magazines actually recommended replacing uses of 0 and 1 (which were
the most common numbers) with uses of variables that were assigned
these values and never reassigned.
Sinclair BASIC took some shortcuts, to accelerate the execution:

1. All keywords were single bytes and were input as single character
strokes, using a modal model of the keyboard (3 cursor types: K/L/E
and 2 shift key types).

2. All constants in the code were followed by their binary representation.
Those hidden bytes were stripped when the line was edited and inserted
back when the line was scanned, before being inserted back into the
program.

#2 "wasted" more bytes than #1 saved. When optimising for program *size*,
one would use variables instead of constants.
The Commodore 64 actually used line numbers in a weird fashion. If we
ignore GOTO and GOSUB, line numbers were pretty much irrelevant.
And FOR loops. The loop control variable usually contained the line
number of the corresponding FOR statement, too.
Execution normally proceeded in the order the lines were in memory. If
you edited the memory directly, you could for example put the lines in
reverse order, or even give every line the same number, and the program
still ran like it originally did. (If it didn't use GOTO and GOSUB, of
course.)

This is normal for a minimal BASIC implementation: ordinary line numbers
are only to avoid the need for a more sophisticated editor. The HiSoft
Pascal and C *compilers* for ZX-Spectrum also used line numbers in the
source code, to simplify the built-in text editor: the compilers used
them only in diagnostics: "Error 15 at line 180" where 180 was the
logical line number (assigned by the programmer or automatically by the
editor) not the physical line number.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Richard Delorme]

Dan Pop a écrit :

In <40**********************@news.club-internet.fr> Richard Delorme <ab****@nospam.fr> writes:

That's the main point. The lake of competition, the availability of a
simple and inexpensive BASIC made by Microsoft for their platforms, and
other marketing issues can well explain the choices made by Commodore.
So, whatever if standardized specifications for a better BASIC existed
and the machine was powerful enough to handle them, they did not bother
implementing it.
Name one 8-bit home computer implementing the "better" BASIC
specification in its ROM. Even those which didn't go the Microsoft
BASIC way, still took the KnK specification from 1964 as their
starting point.

I called that "the lake of competition".

I just want to show that BASIC
could have been a well-structured language on the family and personal
computer of the early 1980s.

But you have provided exactly zilch arguments supporting this opinion.
The existence of a language specification is far from being enough for
that purpose.

I also gave the following link:
http://www.npsnet.com/danf/cbm/languages.html
from which you can read:

- Structured BASIC V6.5 [C64]
"Flexible new language".
- Symbolic/Structured BASIC [PET] (1979, Softside Software)
S-BASIC includes editor, "pre-compiler" and loader package. Allows
structured BASIC constructs like no line numbers, WHILE and UNTIL loops,
labeled GOTOs and long lines. Upwardly compatible with PET BASIC.

(the PET was actually not a C64 but an older professional computer from
which the C64 derived).

So structured BASIC existed on the C64 or similar machines.
Write an implementation that could fit in 16 K, along with
all the device drivers and the rest of the system management software
usually required by an 8-bit home computer and that would deliver decent
performance on a 4 MHz Z80A (or equivalent micro of the time) and THEN
you'd have a *valid* point.
Of course, I will write for tomorrow what needed several man-years of
development.
The fact that it took a mainframe or a PC to produce such implementations
might provide a clue....

Then, the fact that such languages existed on 8-bit machines proves my
point of view.

--
Richard

[Dan Pop]

In <40**********************@news.club-internet.fr> Richard Delorme <ab****@nospam.fr> writes:

Dan Pop a écrit :

In <40**********************@news.club-internet.fr> Richard Delorme <ab****@nospam.fr> writes:

That's the main point. The lake of competition, the availability of a
simple and inexpensive BASIC made by Microsoft for their platforms, and
other marketing issues can well explain the choices made by Commodore.
So, whatever if standardized specifications for a better BASIC existed
and the machine was powerful enough to handle them, they did not bother
implementing it.

Name one 8-bit home computer implementing the "better" BASIC
specification in its ROM. Even those which didn't go the Microsoft
BASIC way, still took the KnK specification from 1964 as their
starting point.

I called that "the lake of competition".

You haven't explained the reasons of this lack of competition, considering
that there was plenty of competition on the home computer market.
An evil conspiracy of the home computer makers?

I just want to show that BASIC
could have been a well-structured language on the family and personal
computer of the early 1980s.

But you have provided exactly zilch arguments supporting this opinion.
The existence of a language specification is far from being enough for
that purpose.

I also gave the following link:
http://www.npsnet.com/danf/cbm/languages.html
from which you can read:

- Structured BASIC V6.5 [C64]
"Flexible new language".
- Symbolic/Structured BASIC [PET] (1979, Softside Software)
S-BASIC includes editor, "pre-compiler" and loader package. Allows
structured BASIC constructs like no line numbers, WHILE and UNTIL loops,
labeled GOTOs and long lines. Upwardly compatible with PET BASIC.

(the PET was actually not a C64 but an older professional computer from
which the C64 derived).

So structured BASIC existed on the C64 or similar machines.

Not as part of their firmware, which was the point of this discussion.
I guess even Pascal compilers were available for C64, so no one contested
the possibility of implementing structured programming languages on such
machines. Merely the practicality of having such implementations in the
machines firmware.

Write an implementation that could fit in 16 K, along with
all the device drivers and the rest of the system management software
usually required by an 8-bit home computer and that would deliver decent
performance on a 4 MHz Z80A (or equivalent micro of the time) and THEN
you'd have a *valid* point.

Of course, I will write for tomorrow what needed several man-years of
development.

Then, you still have no valid point for your claim.

The fact that it took a mainframe or a PC to produce such implementations
might provide a clue....

Then, the fact that such languages existed on 8-bit machines proves my
point of view.

It proves zilch. How much of the machine's resources was taken by the
implementation of those languages? The answer to this question will
show you whether putting such implementations into the machine's firmware
was an economical option.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Randy Howard]

In article <c6**********@oravannahka.helsinki.fi>, pa*****@cc.helsinki.fi
says...

Randy Howard <ra*********@fooverizonbar.net> scribbled the following:

In article <c6***********@f1n1.spenet.wfu.edu>, co******@wfu.edu says...

As a teacher of undergraduates, I'm sorry to say that I can confirm
that. In the DOS days, I had a scattering of students who really
knew about computers. In the XP days, I have none.

Hmm, I have a 10-year old child currently learning to program in C
on an XP system. We'll be working on cross-platform portability to
Linux and Mac systems (the latter primarily for byte-order discussions)
shortly.

But *you're* a computer programmer too. Neither of my parents, nor any
of my elementary school teachers, knew anything about computers when I
started programming.

Same here. In fact, a couple other students and I, in the first "Computer
Math" class ever taught in my High School, taught the teacher how to use
her computer. The 6 week "Summer Course" she had before the class started
was fairly weak. In effect, several of us that had built our own computers
(Heathkits) taught most of that class, while letting her pretend to so she
could get paid. She taught algebra for 15 or 20 years before that, and
AFAICT, had never seen a computer before that summer. Of course, few people
had in that time period.
I started programming from natural interest, not because someone taught me.

Again, I had the same experience. FYI, I didn't try to get her into computer
programming, (especially considering the future of the industry), but after
being asked to show how to do it, I don't see any harm in it.

--
Randy Howard
2reply remove FOOBAR

[Randy Howard]

In article <c6**********@oravannahka.helsinki.fi>, pa*****@cc.helsinki.fi
says...

Randy Howard <ra*********@fooverizonbar.net> scribbled the following:

In article <c6***********@f1n1.spenet.wfu.edu>, co******@wfu.edu says...

As a teacher of undergraduates, I'm sorry to say that I can confirm
that. In the DOS days, I had a scattering of students who really
knew about computers. In the XP days, I have none.

Hmm, I have a 10-year old child currently learning to program in C
on an XP system. We'll be working on cross-platform portability to
Linux and Mac systems (the latter primarily for byte-order discussions)
shortly.

But *you're* a computer programmer too. Neither of my parents, nor any
of my elementary school teachers, knew anything about computers when I
started programming.

Same here. In fact, a couple other students and I, in the first "Computer
Math" class ever taught in my High School, taught the teacher how to use
her computer. The 6 week "Summer Course" she had before the class started
was fairly weak. In effect, several of us that had built our own computers
(Heathkits) taught most of that class, while letting her pretend to so she
could get paid. She taught algebra for 15 or 20 years before that, and
AFAICT, had never seen a computer before that summer. Of course, few people
had in that time period.
I started programming from natural interest, not because someone taught me.

Again, I had the same experience. FYI, I didn't try to get her into computer
programming, (especially considering the future of the industry), but after
being asked to show how to do it, I don't see any harm in it.

--
Randy Howard
2reply remove FOOBAR

[glen herrmannsfeldt]

Old Wolf wrote:

(snip)

Don't forget the BASIC equivalent of "switch": 240 GOTO 250*(i=0) + 350*(i=1) + 380*(i=2) + .... + 3530*(i=51) (this came from an adventure game where there were 50 or so possible
user actions, each having its own handling "function"). Luckily my micro's version of BASIC included the feature of expressions
evaluating to either 1 or 0 (pretty advanced for those days); the other
micros had to do something more complicated.

Most BASICs that I knew of had real computed GOTO and GOSUB,
something like:

ON I GOTO 10,20,30,40

They were not completely interpreted, such that GOTOs
to non existing lines would be discovered before the program
started running.

In the early years of microcomputers, there were "Tiny BASIC"
systems that simplified many things, including the GOTO
method described above. Also, the same expression evaluator
was used for INPUT statements as for other expressions, so
variables could be use to reply to an INPUT prompt.

Around that time I had a TRS80 Color computer running
OS/9 with BASIC/09 and also a C compiler.
BASIC/09 was pretty different from other BASICs, among others
it didn't require line numbers for each line, and might
even have used alphanumeric statement labels. There was
something similar to break to get out of loops, which allowed
execution of one or more statements on the way out.

The C compiler was fine, but it didn't include the full
math library like one would expect.

-- glen

[Dan Pop]

In <OKDoc.37131$z06.5851597@attbi_s01> glen herrmannsfeldt <ga*@ugcs.caltech.edu> writes:

Most BASICs that I knew of had real computed GOTO and GOSUB,
something like:

ON I GOTO 10,20,30,40
Sinclair BASIC had GOTO var.
They were not completely interpreted, such that GOTOs
to non existing lines would be discovered before the program
started running.
Being almost completely interpreted, Sinclair BASIC would simply jump to
first existing line with a number higher than that specified (IIRC).
In the early years of microcomputers, there were "Tiny BASIC"
systems that simplified many things, including the GOTO
method described above. Also, the same expression evaluator
was used for INPUT statements as for other expressions, so
variables could be use to reply to an INPUT prompt.
I believe this is a language feature.
Around that time I had a TRS80 Color computer running
OS/9 with BASIC/09 and also a C compiler.
BASIC/09 was pretty different from other BASICs, among others
it didn't require line numbers for each line, and might
even have used alphanumeric statement labels. There was
something similar to break to get out of loops, which allowed
execution of one or more statements on the way out.

The C compiler was fine, but it didn't include the full
math library like one would expect.

Back then, you were happy when an 8-bit micro implementation supported
all the features documented in K&R1 (which didn't include any math
library support at all, although it was mentioned en passant).

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de