Robert Epprecht wrote: > I have done more tests today and can reproduce a situation now, where > there *is* a zero byte at /dev/midi and key?-file gives FALSE. I can > get the zero byte with key-file. So I can confirm what I assumed in my > last message. Unfortunately I need my midi hardware to trigger the bug, > but I will inquire more.
Well, either the way that Gforth's KEY?-FILE is implemented has a bug that is not triggered by ordinary files, but by the MIDI stuff, or this is some specific problem (bug?) of the MIDI driver. I guess the fastest way for you to proceed is to use your original plan of doing your own open() with a non-blocking way, and then use read() (READ-FILE uses fread() (buffering), and probably does not do what you want). > I *did* use KEY? and KEY in my debugging. I hope this did not change the > results of KEY?-FILE and KEY-FILE. Or do they also use the same variable? Yes, KEY?-FILE and KEY-FILE are factors of KEY? and KEY. > > The clean way to solve this would be to check if there is already a > > character buffered by the FILE * structure, and if not, try to read > > it, and then ungetc() it. Unfortunately, I don't know a portable way > > to determine that there are buffered characters in a FILE *. > > If not portable, By portable, here I meant the portability of Gforth among platforms. > do you know a way to do this in gforth on linux on > /dev/midi? As mentioned above, I would go with open() and read(). - anton --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
