Path: eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: sjack@dontemail.me (sjack)
Newsgroups: comp.lang.forth
Subject: Re: Toad User abort with cut: ... -cut
Date: Thu, 17 Oct 2024 18:25:09 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 14
Message-ID: <verkq5$2rvc3$1@dont-email.me>
References: <verc15$2qfgr$1@dont-email.me>
Reply-To: sdwjack69@gmail.com
Injection-Date: Thu, 17 Oct 2024 20:25:09 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="5119eb69bad735d99744a2df73b89dbc";
	logging-data="3014019"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+6gCwAMpbgGO2QBqdNi/Is"
User-Agent: tin/2.6.4-20240224 ("Banff") (Linux/6.8.0-45-generic (x86_64))
Cancel-Lock: sha1:zt88Lgks3KrPOt70KzeENSmt78Q=

Ha,ha. Fooled myself looking at file id (FDIID) for zero value to
indicate cleanup took place. When file i/o failed because file foo
didn't exist, FDIID never got set so was always zero. (there were
other means of verifying that cleanup code got accessed, e.g. the
"FVIEWS abandon' being printed.
But to see FDIID being reset I needed to at least get the file opened
and then have it fail. So just open a corrupt file. No! Whatever I
put into a file, nulls and control characters, does not make the i/o
fail! To have failure has to be done on my end in processing the 
data. So patched UABORT into a low level part that was acting
on the data. Mission achomplished.

-- 
me