BJ> I've seen this one character issue / bug in other 
 BJ> software.  I think it gets back to how the C 
 BJ> compiler libraries handle pointers on character 
 BJ> devices..... 
 WG>  
 WG> To be clear, under UNIX there are C compiler libraries (the annoying 
 WG> exception being the C++ compiler libraries for gcc 3 
 WG> onward) -- technically, these are OS-level libraries 
 WG> which compiled C code calls. Subtle difference, but 
 WG> important -- it means that you can't depend on the 
 WG> compiler for 'bug compatible' (etc) behaviour, because 
 WG> the underlying OS is really what matters. This is 
 WG> actually similar to the way Windows works if you're 
 WG> calling, say, winsock code from either Borland or VC, 
 WG> the compiler matters not, the version of winsock.dll does.

Yes, the bug is getting back to OS level issues.  I think I've seen it in
both C and Pascal code.....  And on multiple operating systems, including
some old mainframe systems.

 WG> Anyhow, when I fixed that bug under Maximus, what I 
 WG> found was that the ncurses library didn't behave the 
 WG> way I thought it would -- I was asking for a 0-second 
 WG> timeout on my reads with the timeout() call. This is 
 WG> supposed to be equivalent to a non-blocked read, but 
 WG> seems to cause buggy behaviour observed. Asking for 
 WG> notimeout() seems to fix it. Stupid, stupid, stupid. 
 WG> Either seems to work under real curses.


We may need to look at the ncurses code and suggest a patch for using
Maximus with it......  Something in the back of my mind says I've seen this
documented someplace concerning ncurses....

Take care.....

Bob Jones, 1:343/41


--- Maximus/2 3.01