[GAP] Get_Immediate on Mac OS X

[Christfried Webers]

This is in reply to Roberts mail, but I changed the topic to better
reflect the contents of the discussion.

Robert,

after reading the file sysdep.c in the directory adainclude (using the
GPL 2006 version) I understand what you mean by "non-trivial 
implementation".

All usages of Get_Immediate seem to end up in
the
  void getc_immediate_common(...)
call.

In this call, there is a long

  #if defined (linux) || defined (sun) || defined (sgi) || \
      defined (__EMX__) || defined (__osf__) || \
    ! defined (__alpha_vxworks)) || defined (__CYGWIN32__) ||
      defined (__MACHTEN__) || defined (__hpux__) || \
      defined (_AIX) || (defined (__svr4__) && defined (i386)) || \
      defined (__Lynx__) || defined (__FreeBSD__)

clause which if taken branches to test if the file descriptor is a
terminal (by calling isatty()). If it is a terminal the terminal is read
without a delay and the result is returned immediately.

The long #if defined (linux) ... clause seems to NOT test for
the Mac OS X, at least I can't find anything like Darwin etc.

Therefore, the #else branch is taken which results in
a standard getc() call which is blocking when connected to
a terminal.

If I understand it correctly, the fix might be as simple as adding a
  defined (DARWIN or whatever designates Mac OS X )
to the corresponding clause.
On the other hand, a terminal on the Mac might need some
special handling as some of the other OSes do.

Of course, I very well understand that pointing to a problem and
reliably fixing it without introducing new errors is a very
different matter. But I was just curious how far I could go to
understand the blocking Get_Immediate on Mac OS X.

Best
Chris

--On 9 September 2006 7:47:40 -0400 Robert Dewar <dewar at adacore.com> wrote:

> It is on our list as an unfunded enhancement request. As I am sure you
> can understand, such requests have lower priority than funded
> enhancements or bug fixes, so we can't give any definite commitment
> or schedule on such enhancements.
>
> That being said, when you look at the features file for a new release
> the great majority of new features start their life as unfunded
> enhancement requests, so such requests are very welcome.
>
> Clearly this particular enhancement is desirable, but unfortunately
> the implementation is non-trivial.