Re: [hatari-devel] (raw) MIDI connection reliability?

[ Thread Index | Date Index | More Archives ]

Am Sat, 18 Jun 2022 14:59:24 +0300
schrieb Eero Tamminen <oak@xxxxxxxxxxxxxx>:

> On 18.6.2022 7.18, Thomas Huth wrote:
> > Am Fri, 17 Jun 2022 21:51:28 +0300
> > schrieb Eero Tamminen <oak@xxxxxxxxxxxxxx>:
> > ...  
> >> I added output to MIDI trace on whether buffering disabling actually
> >> succeeded, and fixed issue in
> >> read error handling (it handled other errors than
> >> EOF as valid input).  
> > 
> > I don't think that change wrt EOF was really necessary.
> > Midi_Host_ReadByte() only returns EOF on errors, and that's
> > also what the comment in front of the function says.  
> No, it returns what fgetc() returns, or EOF if nothing is available.
> Manual page says:
> -----------------
>         fgetc(), getc(), and getchar() return the character read as an 
> unsigned
>         char cast to an int or EOF on end of file *or error*.

Hmm, interesting, I think you read the man page differently than I did.

I interpreted it that way:

	(unsigned character) OR (EOF if (end of of file or error))

while you read it that way:

	(unsigned character) OR (EOF if end of file) OR (error)

It's ambiguous in the man-page, indeed.

The Posix version (man 3p fgetc) of the man page is more precise:

       Upon successful completion, fgetc() shall return the next byte from the  in‐
       put  stream  pointed  to  by  stream.   If the end-of-file indicator for the
       stream is set, or if the stream is at end-of-file, the end-of-file indicator
       for  the  stream  shall be set and fgetc() shall return EOF. If a read error
       occurs, the error indicator for the stream shall be set, fgetc()  shall  re‐
       turn EOF, and shall set errno to indicate the error.

Anyway, since EOF is guaranteed to be negative, it shouldn't
really matter much in this case, so never mind, let's just
leave the code as it is.


Mail converted by MHonArc 2.6.19+