Ahem A Rivet's Shot wrote to The Natural Philosopher <=-
CP/M did not have a heirachial directory system. The CP/M
filesystem was single level with user IDs and drives being the only separations, user IDs were not visible and a little strange by modern standards - there were only 15 of them with 0 being everyone.
CP/M filenames were like A:THING.COM - no slashes in any
direction.
Ahem A Rivet's Shot wrote to The Natural Philosopher <=-
CP/M did not have a heirachial directory system. The CP/M filesystem was single level with user IDs and drives being the only separations, user IDs were not visible and a little strange by
modern standards - there were only 15 of them with 0 being everyone.
CP/M filenames were like A:THING.COM - no slashes in any direction.
Later versions of CP/M did have a hierarchial directory structure. But I need to do some research to see if they added that before or after MS-DOS came out.
The first version of MS-DOS did NOT support sub-directories.
On Sun, 13 Feb 2022 13:25:03 +1200
nospam.Ron.Lauzon@f383.n135.z1.fidonet.org (Ron Lauzon) wrote:
Ahem A Rivet's Shot wrote to The Natural Philosopher <=-everyone.
CP/M did not have a heirachial directory system. The CP/M
filesystem was single level with user IDs and drives being the only
separations, user IDs were not visible and a little strange by
modern standards - there were only 15 of them with 0 being
CP/M filenames were like A:THING.COM - no slashes in any
direction.
Later versions of CP/M did have a hierarchial directory structure. But I
need to do some research to see if they added that before or after MS-DOS
came out.
I'd like to see details - the CP/M-86 filesystem on the ACT Sirius
I used didn't have one.
The first version of MS-DOS did NOT support sub-directories.
IIRC they came into MS-DOS along with hard disc support in 2.0.
Heirarchial filesystems go back a *long* way, there are papers from
the late 1950s but Multics is generally considered to have had the first
full blown version.
Ahem A Rivet's Shot wrote to Dr. What <=-
I'd like to see details - the CP/M-86 filesystem on the ACT
Sirius I used didn't have one.
IIRC they came into MS-DOS along with hard disc support in
2.0.
Heirarchial filesystems go back a *long* way, there are papers
from the late 1950s but Multics is generally considered to have had the first full blown version.
I'm trying to see if I can find that information, but I'm coming up empty. >Maybe I'm thinking about DRI's offerings much later (like DR DOS).
But if you think about the time frame, it was mostly floppy drive systems. >Subdirectories don't become really useful until hard drives are relatively >common.
I'm just imagining what it would be like to use a Kaypro 10 (with the hard >drive) without subdirectories and that's certainly a different way of thinking.
Dennis Lee Bieber wrote to All <=-
CP/M: single level; max drive 8M (larger drives are split
into "logical drives")
LS-DOS/TRS-DOS6:
single level directory; path names
8/3<.password>:<drv#>
would scan multiple drives to find file, and
for
output would skip write-protected drives to
find
first writable media (made it easy to use a
write-protected system drive with writable data
drive)
How much stuff could you fit on a 5-10 MB hard-drive...
Granted, back then, the entire OS and support would fit on a 360kB (or less) floppy.
Dennis Lee Bieber wrote to All <=-
CP/M: single level; max drive 8M (larger drives are
split into "logical drives")
CP/M must not have suffered from the MS-DOS limitation of 255 files in the root direcory. Or did it? And that's why they had to split larger
drives.
Dennis Lee Bieber wrote to All <=-
CP/M: single level; max drive 8M (larger drives are split
into "logical drives")
CP/M must not have suffered from the MS-DOS limitation of 255 files in the >root direcory. Or did it? And that's why they had to split larger drives.
On Tue, 15 Feb 2022 08:49:07 +1200, nospam.Ron.Lauzon@f383.n135.z1.fidonet.org (Ron Lauzon) declaimed the following:split DLB>
Dennis Lee Bieber wrote to All <=-
CP/M: single level; max drive 8M (larger drives are
theinto "logical drives")"A drive may contain up to 64k separate allocation blocks"; and
CP/M must not have suffered from the MS-DOS limitation of 255 files in
the root direcory. Or did it? And that's why they had to split larger >>drives.
driver can be defined to use block sizes from 1kB to 16kB.is only
Even though I/O was based upon 128byte sectors, and file length
known by the number of blocks allocated in the directory (text filesthe
need to be scanned to find the <EOF> marker).
Book doesn't mention any limit on directory entries (large /files/ toggle from the directory entry have block pointers to having "extent" pointers (to additional directory entries), with the extents having the actual block pointers.
No bit-map of block allocations, per se; each drive has to have
directory scanned to build up a table (in RAM) of which blocks are used/available.
On Tue, 15 Feb 2022 08:49:07 +1200
nospam.Ron.Lauzon@f383.n135.z1.fidonet.org (Ron Lauzon) wrote:
Dennis Lee Bieber wrote to All <=-
CP/M: single level; max drive 8M (larger drives are
split into "logical drives")
CP/M must not have suffered from the MS-DOS limitation of 255 files in the >> root direcory. Or did it? And that's why they had to split larger
drives.
The CP/M filesystem could only handle eight megabytes per drive. A
CP/M directory entry is 32 bytes (files over 16K would use multiple
directory entries - proper name extents - which cuts down the count). Most >floppy formats used one track for the directory giving 64 entries in a 2K >track - which was plenty for an 80K or even 160K floppy. I don't think
there was any limit except that imposed by how much of the disc was
allocated to directory entries which was an implemntors choice.
So I wrote a CP/M clone in the holidays in Z80 asm running on the ZX81 system.
On Tue, 15 Feb 2022 19:38:49 GMT
Jan Panteltje <pNaonStpealmtje@yahoo.com> wrote:
So I wrote a CP/M clone in the holidays in Z80 asm running on the ZX81
system.
Did you ever attempt to get WordStar running ?
It gave us some
trouble at Torch because it was using some undocumented bits (literally
IIRC) in the directory entry and the reason CPN existed was because I felt >quite ill when I saw the extent mechanism and decided it wasn't much harder >to re-implement and make a decent filesystem than it was to port to the >hybrid 6502/Z80 environment we had - nobody argued!
Also had The C Programming Language by Ritchie & Kernighan, is a free download these days (google).
The worst I think I ever saw was updated by one Ken
Eagle, who called any numeric variables he added KENn and any strings
EAGLEn and clearly didn't give a shit about anybody else who might have
to maintain the code in future, hence you'd see lines in code he'd
touched like:
ADD KEN15 TO KEN5 GIVING KEN9.
MOVE KEN9 TO EAGLE2.
On 16-02-2022 11:21, Martin Gregorie wrote:
The worst I think I ever saw was updated by one Ken Eagle, who called
any numeric variables he added KENn and any strings EAGLEn and clearly
didn't give a shit about anybody else who might have to maintain the
code in future, hence you'd see lines in code he'd touched like:
ADD KEN15 TO KEN5 GIVING KEN9.
MOVE KEN9 TO EAGLE2.
Holy shit. Legend! (And an asshole.)
On 16-02-2022 11:21, Martin Gregorie wrote:
The worst I think I ever saw was updated by one Ken
Eagle, who called any numeric variables he added KENn and any strings
EAGLEn and clearly didn't give a shit about anybody else who might have
to maintain the code in future, hence you'd see lines in code he'd
touched like:
ADD KEN15 TO KEN5 GIVING KEN9.
MOVE KEN9 TO EAGLE2.
Holy shit. Legend! (And an asshole.)
On Wed, 16 Feb 2022 07:55:44 +0000, Jan Panteltje wrote:
Also had The C Programming Language by Ritchie & Kernighan, is a freeYes, that, or (better choice these days) the second edition which covers
download these days (google).
ANSI C.
Another book which I think is helpful for almost any new programmer is
"The Practice of Programming" by Kernighan and Pike. This shows how to
write well-structured code with meaningful names that's easy to read,
modify and debug. The book is really intended for new C programmers, but
what it has to say about choosing function and variable names as well as >designing (and commenting) programs so they are easy to maintain and is >relevant to almost any programming language except the real oddballs like >FORTH and APL.
This book, and the ideas in it, should work for almost any language
though its written round C. It deals with topics that, IME, most books
and courses that claim to teach a programming language should cover but
don't and it shows, especially in some of the COBOL systems I've had to >maintain in the past. The worst I think I ever saw was updated by one Ken >Eagle, who called any numeric variables he added KENn and any strings
EAGLEn and clearly didn't give a shit about anybody else who might have
to maintain the code in future, hence you'd see lines in code he'd
touched like:
ADD KEN15 TO KEN5 GIVING KEN9.
MOVE KEN9 TO EAGLE2.
I generally find the better the coder the less obfuscated the code.,
And fourth there is indentation
for(x = 0; x < 10; x++)
{
do something
}
Note where the brackets are
On Wed, 16 Feb 2022 12:36:59 +0100, A. Dumas wrote:
On 16-02-2022 11:21, Martin Gregorie wrote:
The worst I think I ever saw was updated by one Ken Eagle, who called
any numeric variables he added KENn and any strings EAGLEn and clearly
didn't give a shit about anybody else who might have to maintain the
code in future, hence you'd see lines in code he'd touched like:
ADD KEN15 TO KEN5 GIVING KEN9.
MOVE KEN9 TO EAGLE2.
Holy shit. Legend! (And an asshole.)
That was back in the '70s, when there were some real chancers among some
of the freelancers.
Another pair who stood out (this was on an (unnamed) large Civil Service project in Bath:
- One of them was well-known among the locally-based freelancers because
none of them could remeber this gent actually finishing a project.
His speciality was to put in lots of overtime and then quit abruptly
just before system testing started. His 'completed' programs usually
weren't.
- Another well-known member of that tribe was considered unlikely to know
that, in a COBOL program, code in a paragraph defaults to falling
through into the following one unless there's a explicit GO TO,
STOP RUN or the paragraph is that last one in a PERFORMED SECTION or
set of PERFORMED paragraphs.
We knew this because his programs always contained several sequences
that looked like this..... i.e. were sprinkled with line pairs like
lines 6 to 8 in the following:
LOOP-START.
READ IN-FILE
AT END GO TO LOOP_EXIT.
NOTE a set of moves, additions, PERFORMs etc
GO TO LOOP-END.
LOOP-END.
NOTE more code that completes the in-loop processing.
GO TO LOOP-START.
LOOP_EXIT.
...
but at least his code usually worked....
As a matter of interest, are i++, i +=1 and i = i + 1 equally efficient
for most compilers?
"The Natural Philosopher" <tnp@invalid.invalid> wrote in message news:suj00t$t99$1@dont-email.me...
I generally find the better the coder the less obfuscated the code.,
I'd say the opposite. Unless something has to be super-efficient I tend
to take small nibbles at a problem because it is easy to understand the
code and (more importantly) easier to understand what I was intending to achieve. Clever people try to show how clever they are by writing very obfuscated code which does in one line what takes several lines of more understandable and maintainable code. Having said that, is the cleverer,
more efficient coder "better" if his code is harder to maintain?
I worked with one guy who had a quad-core brain at a time when the rest
of us had single-core brains. And his C code was exceptionally efficient because he'd studied the source code of the compiler, but no-one else
could understand what the F it was supposed to do. It was recommended
that you never ask him a question, not because he'd tell you to F-off,
but because he would answer your question in far more detail than you
wanted, and then he'd go on to answer all the related questions that you might have asked him next.
He was a walking-lookup table of telephone STD codes and dashboard instruments in cars ("ah yes, 01423 is Harrogate, and if the
subscriber's number starts with 61 it's in Woodlands whereas if it
starts with 62 it's in Oatlands" or "ah yes, that speedometer was used
in a Ford Cortina between 1962 and 1963, a Ford Corsair between 1963 and
1965 and a very similar one that was calibrated up to 100 rather than 90
mph was used in the Zephyr GT"). He apparently discovered a very obscure
bug in a device driver (*) that was supplied with a third-party network
card, fixed it and offered the fix (with his manager's approval) back to
the card vendor so everyone else would benefit from it.
(*) Looking only at the EXE file, with no source code.
I like my opening and closing braces to line up so I can count if I've
got more opening than closing etc:
if (a==b)
{
do something
}
else
{
do something
}
I've seen if statements written all on one line
if (a==b) a++; else { b++; c++ }
Which is legal - but tedious to try to read.
On Wed, 16 Feb 2022 14:45:34 +0000, NY wrote:
Kernighan and Ritchie have got a *lot* to answer for in promoting theAgreed - I hate reading code with opening and closing 'brackets' which
indentation
if (a==b) {
do something
} else {
do something
}
are not on the same level, but I put the brackets on the same level as
the introductory statement, e.g.
void function(int arg)
{
if (arg)
{
do_this();
}
else
{
do_something_else();
}
}
I generally find the better the coder the less obfuscated the code.,
REGEXPS are for wannabe geniuses who have learnt regexp but still cant
write clean workmanlike code.
Nowadays with optimising compilers there is no excuse for
a=(b? c:d);
when
if(b)
a=c;
else a=d;
will probably compile to the same thing.
Kernighan and Ritchie have got a *lot* to answer for in promoting the indentation
if (a==b) {
do something
} else {
do something
}
x=(a==b)? a++: b++ + c++;
:-)
Then throw x away.
Kernighan and Ritchie have got a *lot* to answer for in promoting the indentation
if (a==b) {
do something
} else {
do something
}
I like my opening and closing braces to line up so I can count if I've
got more opening than closing etc:
if (a==b)
{
do something
}
else
{
do something
}
On Wed, 16 Feb 2022 14:45:34 +0000, NY wrote:
Kernighan and Ritchie have got a *lot* to answer for in promoting the
indentation
if (a==b) {
do something
} else {
do something
}
Agreed - I hate reading code with opening and closing 'brackets' which
are not on the same level, but I put the brackets on the same level as
the introductory statement, e.g.
void function(int arg)
{
if (arg)
{
do_this();
}
else
{
do_something_else();
}
}
On Wed, 16 Feb 2022 14:45:34 -0000
"NY" <me@privacy.invalid> wrote:
Kernighan and Ritchie have got a *lot* to answer for in promoting the
indentation
if (a==b) {
do something
} else {
do something
}
If you had to work on a single 24 line, 80 column screen you would
want to conserve lines too - those three lines saved are an eighth of the available screen space.
On Wed, 16 Feb 2022 15:15:15 +0000
The Natural Philosopher <tnp@invalid.invalid> wrote:
x=(a==b)? a++: b++ + c++;
:-)
Then throw x away.
a nice example of how *not* to use ternary expressions,
as recursing in multiple ways in the expression though.
Martin Gregorie <martin@mydomain.invalid> wrote:
On Wed, 16 Feb 2022 14:45:34 +0000, NY wrote:
Kernighan and Ritchie have got a *lot* to answer for in promoting
the indentation
if (a==b) {
do something
} else {
do something
}
Agreed - I hate reading code with opening and closing 'brackets'
which are not on the same level,
but I put the brackets on the same level as
the introductory statement, e.g.
void function(int arg)
{
if (arg)
{
do_this();
}
else
{
do_something_else();
}
}
This, except I'm likely to leave them out if they only enclose a single statement. I'd use this:
void function(int arg)
{
if (arg)
do_this();
else
do_something_else();
}
If a piece of code expands beyond one statement, then I'll add the brackets:
void function(int arg)
{
if (arg)
{
do_this();
and_that();
}
else
do_something_else();
}
On 16/02/2022 16:18, Ahem A Rivet's Shot wrote:
On Wed, 16 Feb 2022 14:45:34 -0000
"NY" <me@privacy.invalid> wrote:
Kernighan and Ritchie have got a *lot* to answer for in promoting the
indentation
if (a==b) {
do something
} else {
do something
}
If you had to work on a single 24 line, 80 column screen you
would want to conserve lines too - those three lines saved are an
eighth of the available screen space.
you were lucky, Most of us had a one line teleprinter
On Wed, 16 Feb 2022 07:55:44 +0000, Jan Panteltje wrote:
Also had The C Programming Language by Ritchie & Kernighan, is a freeYes, that, or (better choice these days) the second edition which covers
download these days (google).
ANSI C.
Another book which I think is helpful for almost any new programmer is
"The Practice of Programming" by Kernighan and Pike. This shows how to
write well-structured code with meaningful names that's easy to read,
modify and debug. The book is really intended for new C programmers, but
what it has to say about choosing function and variable names as well as designing (and commenting) programs so they are easy to maintain and is relevant to almost any programming language except the real oddballs like FORTH and APL.
This book, and the ideas in it, should work for almost any language
though its written round C. It deals with topics that, IME, most books
and courses that claim to teach a programming language should cover but
don't and it shows, especially in some of the COBOL systems I've had to maintain in the past. The worst I think I ever saw was updated by one Ken Eagle, who called any numeric variables he added KENn and any strings
EAGLEn and clearly didn't give a shit about anybody else who might have
to maintain the code in future, hence you'd see lines in code he'd
touched like:
ADD KEN15 TO KEN5 GIVING KEN9.
MOVE KEN9 TO EAGLE2.
On 16/02/2022 14:45, NY wrote:
I've seen if statements written all on one line
if (a==b) a++; else { b++; c++ }
Which is legal - but tedious to try to read.
x=(a==b)? a++: b++ + c++;
:-)
Then throw x away.
I didn't mean me, I meant Kernighan, Ritchie, Pike et al - a hand
card punch is the least convenient editing device I have used.
On 2022-02-16, Martin Gregorie wrote:
On Wed, 16 Feb 2022 07:55:44 +0000, Jan Panteltje wrote:
Also had The C Programming Language by Ritchie & Kernighan, is a freeYes, that, or (better choice these days) the second edition which
download these days (google).
covers ANSI C.
Another book which I think is helpful for almost any new programmer is
"The Practice of Programming" by Kernighan and Pike. This shows how to
write well-structured code with meaningful names that's easy to read,
modify and debug. The book is really intended for new C programmers,
but what it has to say about choosing function and variable names as
well as designing (and commenting) programs so they are easy to
maintain and is relevant to almost any programming language except the
real oddballs like FORTH and APL.
This book, and the ideas in it, should work for almost any language
though its written round C. It deals with topics that, IME, most books
and courses that claim to teach a programming language should cover but
don't and it shows, especially in some of the COBOL systems I've had to
maintain in the past. The worst I think I ever saw was updated by one
Ken Eagle, who called any numeric variables he added KENn and any
strings EAGLEn and clearly didn't give a shit about anybody else who
might have to maintain the code in future, hence you'd see lines in
code he'd touched like:
ADD KEN15 TO KEN5 GIVING KEN9.
MOVE KEN9 TO EAGLE2.
Was this partly to make himself indispensable (i.e., no-one else would
be able to patch his code)?
On Wed, 16 Feb 2022 19:05:49 +0000, Ahem A Rivet's Shot wrote:
I didn't mean me, I meant Kernighan, Ritchie, Pike et al - a
hand card punch is the least convenient editing device I have used.
The old 12 key punches were damn good for fixing single single character mistakes provided your computer used a optical card reader with a
straight card path.
I'm looking for the dreaded "if (a=b)" test which is almost never what is intended ;-)
The trouble with C is that it allows "side-effects" which can cause some
very obfuscated code which is perfectly legal - and is a nightmare to understand.
I saw some code of the form
array1[i++] = b;
array2[--i] =c;
array3[i++] = d;
The worst I think I ever saw was updated by one Ken
Eagle, who called any numeric variables he added KENn and any strings
EAGLEn and clearly didn't give a shit about anybody else who might have
to maintain the code in future, hence you'd see lines in code he'd
touched like:
ADD KEN15 TO KEN5 GIVING KEN9.
MOVE KEN9 TO EAGLE2.
On Wed, 16 Feb 2022 19:22:11 -0000
"NY" <me@privacy.invalid> wrote:
I'm looking for the dreaded "if (a=b)" test which is almost never what is
intended ;-)
For tests like if (x==3) writing it as if (3=x) generates an error
if you miss out the second = like I just did - one legal reversal of convention that is useful
unlike using 5[x] insteadof x[5] which just confuses people.
On 16/02/2022 14:16, NY wrote:
The trouble with C is that it allows "side-effects" which can cause
some very obfuscated code which is perfectly legal - and is a nightmare
to understand.
I saw some code of the form
array1[i++] = b;
array2[--i] =c;
array3[i++] = d;
You could come up with a similar contrived example in just about any language.
"Ahem A Rivet's Shot" <steveo@eircom.net> wrote in message
"NY" <me@privacy.invalid> wrote:
I'm looking for the dreaded "if (a=b)" test which is almost never
what is intended ;-)
For tests like if (x==3) writing it as if (3=x) generates an error
if you miss out the second = like I just did - one legal reversal of
convention that is useful
I like it. Looks a bit odd but it's good defensive coding.
unlike using 5[x] insteadof x[5] which just confuses people.
The writers of compilers actually allow 5[x] as a synonym for x[5]
(where x is an array)? WTF!
It’s part of the C language. Personally I’d reject it in a code review, but compiler writers don’t really have any choice about supporting it.
j[i] = ++i[j++];
I saw a similar technique used to protect commercial software written in
BBC BASIC from being plagiarised. As it was interpreted BASIC it had to
be supplied in a form which could be read by both humans and the
computer, but they had renamed every variable and every procedure to a variant of 'ClaresMicroSupplies' with each instance have a different combination of upper and lower case letters. The computer could still
execute it, but humans just find it impossible to distinguish between
the variants.
"Richard Kettlewell" <invalid@invalid.invalid> wrote in message news:87ee42326l.fsf@LkoBDZeT.terraraq.uk...
It’s part of the C language. Personally I’d reject it in a code review, but compiler writers don’t really have any choice about supporting it.
Sure. I do wonder what funny substance K and R were smoking when they
came up with 5[x] as a valid C syntax - they were definitely having a
laugh. I suppose you could say that at pointer level, you are specifying
a pointer of value (5*sizeof(int) + &x) for both 5[x] and x[5], but the latter is a damn sight more meaningful.
"Ahem A Rivet's Shot" <steveo@eircom.net> wrote in message news:20220216215357.137efe85b657c3425d77ae54@eircom.net...
j[i] = ++i[j++];
That makes my brain hurt. But is it syntactically legal? i is being used
as an array (a pointer) on the RHS but as an integer on the LHS. And vice versa for j. I wonder how you would declare i and j so the code would actually compile.
"Richard Kettlewell" <invalid@invalid.invalid> wrote:
It’s part of the C language. Personally I’d reject it in a code
review, but compiler writers don’t really have any choice about
supporting it.
Sure. I do wonder what funny substance K and R were smoking when they
came up with 5[x] as a valid C syntax - they were definitely having a
laugh. I suppose you could say that at pointer level, you are
specifying a pointer of value (5*sizeof(int) + &x) for both 5[x] and
x[5], but the latter is a damn sight more meaningful.
j[i] = ++i[j++];
That makes my brain hurt. But is it syntactically legal? i is being
used as an array (a pointer) on the RHS but as an integer on the
LHS. And vice versa for j. I wonder how you would declare i and j so
the code would actually compile.
The compiler converts 5[x] into *(5+x) becuase that's the language
definition and performs pointer arithmetic. It's more of an unintended >consequence of keeping things simple than a deliberate design decision.
Anyway why is "3rd of array" less meaningful than "array position
3" ?
On a sunny day (Thu, 17 Feb 2022 07:15:59 +0000) it happened Ahem A
Rivet's Shot <steveo@eircom.net> wrote in <20220217071559.54716e3e30df759ef3245267@eircom.net>:
The compiler converts 5[x] into *(5+x) becuase that's the
language
definition and performs pointer arithmetic. It's more of an unintended >consequence of keeping things simple than a deliberate design decision.
Anyway why is "3rd of array" less meaningful than "array position
3" ?
If you put it that way OK.
But somebody was moaning lately in an other groups that multi-dimensional arrays did not work in C. So just for fun I did this in xflir recently:
How would you write that in that other notation?
If you put it that way OK.
But somebody was moaning lately in an other groups that
multi-dimensional arrays did not work in C.
So just for fun I did this in xflir recently:
header:
char input_frame_data[Y_PIXELS][X_PIXELS][3];
code:
...
input_frame_data[y][x][0] = red; input_frame_data[y][x][1] = green;
input_frame_data[y][x][2] = blue;
...
Works perfectly :-)
On Tue, 15 Feb 2022 19:38:49 GMT
Jan Panteltje <pNaonStpealmtje@yahoo.com> wrote:
What helped me a lot in the early days was >https://www.goodreads.com/book/show/3603797-8080-z80-assembly-language
it also had all the Z80 secret asm statements,
Also had The C Programming Language by Ritchie & Kernighan, is a free download these days (google).
the moaner must show compilable, runnable code that illustrates the
problem. If they can't or won't do that they get rubbished.
See also http://sscce.org/
"NY" <me@privacy.invalid> writes:
"Ahem A Rivet's Shot" <steveo@eircom.net> wrote in message
j[i] = ++i[j++];
That makes my brain hurt. But is it syntactically legal? i is being
used as an array (a pointer) on the RHS but as an integer on the
LHS. And vice versa for j. I wonder how you would declare i and j so
the code would actually compile.
It’s syntactically legal. 'int i, *j;' would make it compile.
But it has no meaning. There’s no sequence point between the read of j
on the left hand side and the change on the right hand side, so it
violates a constraint in the language spec:
"Ahem A Rivet's Shot" <steveo@eircom.net> wrote in message >news:20220216215357.137efe85b657c3425d77ae54@eircom.net...
j[i] = ++i[j++];
That makes my brain hurt. But is it syntactically legal? i is being used as >an array (a pointer) on the RHS but as an integer on the LHS. And vice versa >for j. I wonder how you would declare i and j so the code would actually >compile.
How many characters were significant in a variable name in that dialect?
For the Microsoft BASIC implementations you'd find on nearly everything on >this side of the puddle, only the first two characters are significant. >Attempting to obfuscate code by naming a couple of strings SCOTT1$ and >SCOTT2$ will fail as they're both treated the same as SC$.
As I recall, that tended to derive from Kemeny&Kurtz BASIC... <a..z>[<0..9>][$] (as I recall, original K&K BASIC didn't provide
punctuation to differentiate integer<>float<>double, only the $ for
string). One alphabetic followed by optional single digit, followed by optional string indicator. Also DIM statements allocated space for one element more than the number provided, as subscript 0 was valid.
On Thu, 17 Feb 2022 13:48:01 -0500, Dennis Lee Bieber wrote:
As I recall, that tended to derive from Kemeny&Kurtz BASIC...
<a..z>[<0..9>][$] (as I recall, original K&K BASIC didn't provide
punctuation to differentiate integer<>float<>double, only the $ for
string). One alphabetic followed by optional single digit, followed by
optional string indicator. Also DIM statements allocated space for one
element more than the number provided, as subscript 0 was valid.
Ugh! Thankfully, the first interactive language I used was JEAN (JOSS Extensively Adapted for Nineteenhundred), which ran under the MINIMOP timesharing system, on ICL 1900s with teletypes connected via a uniplex
or multiplex switch. JOSS itself was written for Rand's JOHNIAC computer
JEAN was nice to edit on a teletype since it used real line numbers: you could always insert another line between existing ones.
Its only real drawbacks were its single character variable names, so a program could only have 26 variables though they could be arrays, and its conditional syntax:
1.1 Type "Hello, World!" if X=5
which meant there was no 'else' branch.
It was in the scorching hot summer of 1976 [...]
It was a sign of the times that I opened the article with "The other day, my neighbour received an electricity bill for £376", as if that was a preposterous amount for a quarterly bill, which was due to a "computer
error" that was probably operator error. Now a quarterly bill for £376 would be fairly low. How times change.
My first introduction to computer programming was another ICL language,
CESIL (Computer Education in Schools Instructive Language). That was at
ICL's training centre, Beaumont, in Old Windsor (near the Bells of
Ouzeley pub). It was in the scorching hot summer of 1976 and it was a
toss-up between having the windows open so we didn't get *too* hot, and having them closed so we could hear the lecturer and he didn't get
drowned out by the incoming and outgoing planes at Heathrow.
Only after a day of CESIL did we move on to BASIC. All our coding was
done with pencil and squared coding sheets; these were then collected up
and typed onto punched cards which were taken to another site nearby to
be run on the computer, with listings returned the following day. Not
very interactive! The only interactive time we got was on a teletype
that was linked by acoustic coupler to a mainframe, on which we played
the lunar-landing game.
I wrote an article for the school magazine about my experiences on the course, but some dimbo "corrected" CESIL to CECIL, so I was plagued by
people saying "but Computer Education in Schools Instructive Language
should have an S, not a C, in the middle".
It was a sign of the times that I opened the article with "The other
day, my neighbour received an electricity bill for £376", as if that was
a preposterous amount for a quarterly bill, which was due to a "computer error" that was probably operator error. Now a quarterly bill for £376
would be fairly low. How times change.
"NY" <me@privacy.invalid> declaimed the following:
"Ahem A Rivet's Shot" <steveo@eircom.net> wrote in message >>news:20220216215357.137efe85b657c3425d77ae54@eircom.net...
j[i] = ++i[j++];
That makes my brain hurt. But is it syntactically legal? i is being used as >>an array (a pointer) on the RHS but as an integer on the LHS. And vice versa >>for j. I wonder how you would declare i and j so the code would actually >>compile.
I'd object to it just on the basis that it is ambiguous -- depending upon what order the compiler computes the subscripted terms. Did the
compiler determine/cache the address for j[i] first, and then do the increment/subscripts on the right side... Did it compute the right side
first before applying the values to the left, ... etc.
druck <news@druck.org.uk> wrote:
I saw a similar technique used to protect commercial software written in
BBC BASIC from being plagiarised. As it was interpreted BASIC it had to
be supplied in a form which could be read by both humans and the
computer, but they had renamed every variable and every procedure to a
variant of 'ClaresMicroSupplies' with each instance have a different
combination of upper and lower case letters. The computer could still
execute it, but humans just find it impossible to distinguish between
the variants.
How many characters were significant in a variable name in that dialect?
For the Microsoft BASIC implementations you'd find on nearly everything on this side of the puddle, only the first two characters are significant. Attempting to obfuscate code by naming a couple of strings SCOTT1$ and SCOTT2$ will fail as they're both treated the same as SC$.
| Sysop: | deepend |
|---|---|
| Location: | Calgary, Alberta |
| Users: | 262 |
| Nodes: | 10 (0 / 10) |
| Uptime: | 33:04:38 |
| Calls: | 1,880 |
| Calls today: | 1 |
| Files: | 4,273 |
| D/L today: |
23 files (14,059K bytes) |
| Messages: | 403,317 |