@MSGID:
<d9d7ffa3-4d9b-49e3-85d9-4042131537f7n@googlegroups.com> 9efae0f7
@REPLY: 1@dont-email.me> dc70e9e2
@REPLYADDR Mark Ogden <ogdenpm@gmail.com>
@REPLYTO 2:5075/128 Mark Ogden
@CHRS: CP866 2
@RFC: 1 0
@RFC-References: 1@dont-email.me>
<kjf1ifFi86sU1@mid.individual.net> 1@dont-email.me> <878ral5vod.fsf@tilde.institute>
<874jl95u8j.fsf@tilde.institute> <fe884213-dbce-4c6f-a122-12c173f0895cn@googlegroups.com>
<c6b6bc25-67c3-4857-90d5-d2de37300ff1n@googlegroups.com> 1@dont-email.me>
<df48f126-36f2-4ec3-be4a-7ba81c3e1bcan@googlegroups.com> 1@dont-email.me>
@RFC-Message-ID:
<d9d7ffa3-4d9b-49e3-85d9-4042131537f7n@googlegroups.com>
@TZUTC: -0700
@PID: G2/1.0
@TID: FIDOGATE-5.12-ge4e8b94
On Sunday, 13 August 2023 at 11:45:30 UTC+1, dxforth wrote:
> On 13/08/2023 5:43 pm, Mark Ogden wrote: 
> > On Sunday, 13 August 2023 at 04:29:01 UTC+1, dxforth wrote:
> >> ...
 > >> FWIW I noticed the Aztec C fgets/fprintf combo produced some
unexpected results. 
 > >> Unbeknown to me the source text file used included some
`foreign` characters 
> >> with bit 7 set. These did not pass through correctly e.g. 
> >> 
> >> E2 80 99 
> >> 
> >> became 
> >> 
> >> 62 19 
> >> 
> >> bug? 
> > It is not a bug. 
 > > Aztec C 1.06D does not have separate open modes for text and
binary, but uses special functions e.g. agetc and aputc to handle text
files. 
 > > Under the covers fgets calls agetc, which removes the top bit,
detects 1A as EOF and also skips null and carriage return, hence the 80h
is removed, as it becomes 0 when the top bit is removed. 
 > > Using fread/fwrite should avoid this, also using raw read/write
with a buffer a reasonable multiple of the sector size, would avoid too
many multiple buffer copies and should be the most performant. 
> > 
 > > Other compilers e.g. Hitech C, do have open modes e.g. "rt"
or "wt" to open a file as text and "rb" or "wb" to open as binary,
implementing the differences beneath the covers.
> If clearing bit 7 isn`t a bug, perhaps a dubious feature :)
 I suspect is mainly due to history. It was not unknown for serial
connected terminals to add a parity bit. As fgets is reading a line, rather
than a binary stream, then removing the parity bit is not unreasonable.
It would also have made reading Wordstar documents straightforward,
removing the top bits it used. It was only later that non ascii characters
i.e. (80H-FFH) were more widely supported.
--- G2/1.0
 * Origin: usenet.network (2:5075/128)
SEEN-BY: 5001/100 5005/49 5015/255 5019/40 5020/715
848 1042 4441 12000
SEEN-BY: 5030/49 1081 5075/128
@PATH: 5075/128 5020/1042 4441