			  TCLMORE
			  =======

			 Known Bugs
			 ----------

* Sometimes test  pipechan-10.5 fails.  There  is an unknown
  bug  in  how   pipechan  handles  synchronisation  between
  threads.

* (TCL 8.4.5) When a stacked channel is registered, its open
  mode is validated against  the open mode of the underlying
  channel  by Tcl_StackChannel(). The  stacked open  mode is
  not registered in the channels stack. 

    This should  allow a  stacked channel to  transform data
  going in one direction and to leave alone data coming from
  the other.  But: when  a transformation is registered with
  RDONLY mode on top of  a RDWR channel, its output function
  is  invoked when an  attempt to  write data  is performed;
  analogue  behaviour  is  found  when a  transformation  is
  registered with WRONLY mode on top of a RDWR channel. 

    This   is  in   contrast   with  the   manual  page   of
  Tcl_StackChannel().

    [teechan] does the check itself.

* Understand and  fix the problem  in "varchan-102.5", which
  should have the same result of "varchan-102.6".

* Misterious  behaviour  in the  command  interface. In  the
  declaration  of commands:  when no  "member"  attribute is
  used  in the  <option>  markup, the  offset  field of  the
  command  declaration  is set  to  -1:  fine,  this can  be
  verified  by  inspection  of the  automatically  generated
  file.  When the same field is queried in "ParseOptions()",
  it becomes zero!  Why?

  The  "-1"  value should  be  a  flag  to signal  that  the
  extractor function  has to be invoked  with the pointer-to
  the-field-in-state-structure set to NULL; in this case the
  extractor must  know the type  of the state  structure and
  access it directly.

  The problem does not  prevent the extractor from doing its
  job, it is  just that the strange behaviour  may hide some
  bug somewhere. 

  The test suite is doing fine, though...


### end of file
# Local Variables:
# mode: text
# End:
