[Coco] 'arc' copy command and Stack Overflow (ERROR #207)

[Gene Heskett]

On Monday 26 January 2015 01:40:07 Stephen H. Fischer did opine
And Gene did reply:
> It was a year or two back.
> 
>  archive                                        11/05/30 12:43     
> 4E71
> 
> Says I compiled it in May 2011.

For Nitros9, thats just above the K-T boundary.
> 
> Preinstalled Hard disk image Nitros9 Ver 3.2.8 for VCC
> 
> The library I used has left my memory but I now realize Kevin Darling
> is the wrong person to ask for help.
> 
> libraries from RTSI:
> CLib_Krieder_91.lzh

Sorry, I don't even see the connection between that and the disk full 
error you were going on about.
 
> I suspect is the one I used.
> 
> Looking at the backup of my computer before it needed to be sent to
> Sony for a new motherboard, always use the proper glue for your GPU, I
> do not see the source.
> 
> But SHF841 on my webpage appears to have the source.
> 
> I lost interest in fixing up my muliticolumn printing software when the
> printer would not work.
> 
> I lost interest in archive when I realized that no longer could I trace
> down if the problem was a library problem or system and as I said, no
> response to the report.
> 
> Archive is where I found the problem (And was I suprised), Colorful
> Sled has the same code. After losing my editing too many times I went
> on a cursade to fix any posibility of losing the editing file.
> Something the other Sled people did not see as important, more modern
> looking yes.
> 
> SHF

I have tried to use Colorful Sled, several times but not recently. I did 
not find it the least bit intuitive to use, and I have never successfully 
saved a modified file using it.  I usually need every byte of memory I can 
find, and when I was working on rbf.mn, using the Adams patched tsedit, 
now called vim on my system because the vi clashed with a vdg descriptor, 
which can handle a 56k buffer, I still had to go thru it several times 
removing comments because the buffer was full.  Anything else I ever used 
was equipt with such a small buffer I couldn't even write a 3 page latter 
without saving the partial to make room for some more prose.

> ----- Original Message -----
> From: "Gene Heskett" <gheskett at wdtv.com>
> To: <coco at maltedmedia.com>
> Sent: Sunday, January 25, 2015 9:36 PM
> Subject: Re: [Coco] 'arc' copy command and Stack Overflow (ERROR #207)
> 
> > On Sunday 25 January 2015 22:57:06 Stephen H. Fischer did opine
> > 
> > And Gene did reply:
> >> Be careful, NitrOS-9 has changed some related things.
> >> 
> >> My similar Archive program counted on the return code from Disk Full
> >> to stop and tell the user.
> >> 
> >> Upon changing the syntax for another utility I thought I was done.
> >> 
> >> Then I discovered that the disk full error was not being returned to
> >> the program.
> > 
> > That is a pretty serious charge Stephen.  No coder in his right mind
> > would remove that error return.
> 
> I thought so also!

Then why are we changing the subject, which I thought was the lack of rbf 
reporting an error 240, #E$Full, or $F0 hex, which will occur if the 
allocation map does not have sufficient bits to satisfy the size of the 
write request.

> The cmdline is the normal "Copy \d1\dir1\file.c \d2\dir2\file.c".
> 
> It has already been determined that file.c is not in dir2.
> 
> syscall(cmdline)
> char *cmdline;
> {
> 
>    int length, status;
>    fputs("\n",stdout);
>    fputs(cmdline,stdout);
>    fputs("\n",stdout);
>    if((length = strlen(cmdline)) <= 80) {
>       if((status=system(cmdline)) == NULL)  {
>          fputs("\nsystem command successful\n",stdout);
>          return(status);
>       }
>       else {
>          fprintf(stdout, "SYSTEM ERROR # %d\n Press ENTER ",status);
>          while(getchar() != ENTER);
>          return(status);
>       }
>    }
>    else
>        {
>       fputs("\ncommand line > 80 chars - cannot issue",stderr);
>       return -1;
>    }
> }

This is C code, not a Basic09 syscall.  It could probably be compiled to 
run on a coco even, but ATM this is just so much canned fog from offstage. 
Changing the subject IOW.

Even the subject line is wrong.  It says error 207, stack overflow.

That's a very easily fixed problem.

Stack and buffer space for most assembled programs can usually be adjusted 
to raise the limit if its needed on a modulo 65536 basis by the proper use 
of my 'vfy', without being forced to re-assemble the code.  Thats just one 
of the minor reasons why I wrote it.  Not the real reason of course since 
the real reason was to show Paul Jerkatis that his CS profs M68k version 
of verify was not the only one who could write assembly code. I admit I 
was out to outdo the swiss army knife, and did.

This may be yet another case where the emulator, VCC or whatever, DOESN'T 
quite do the coco/os9. And while I can see some utility in the likes of 
MESS & VCC, to accuse the coco of mis-behaving because the emulator 
doesn't do it quite right, is stretching my tolerance a bit. Code I write 
for the coco, is written and built on a real coco, and tested to the five 
nines.  On a real, 6309 equipt coco3 in the two cases I've quoted.

And I still want to know who ATD is & why is he walking around in my code 
undoing things I did to save a few cycles here & there?  But you carefully 
snipped all that.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
US V Castleman, SCOTUS, Mar 2014 is grounds for Impeaching SCOTUS