home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / windows / x / 18834 < prev    next >
Encoding:
Internet Message Format  |  1992-11-08  |  2.8 KB
  1. Path: sparky!uunet!decwrl!netsys!agate!usenet.ins.cwru.edu!magnus.acs.ohio-state.edu!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!cbnewsc!cbfsb!att-out!rutgers!spcvxb!4carroll_j
  2. From: 4carroll_j@spcvxb.spc.edu
  3. Newsgroups: comp.windows.x
  4. Subject: Invalid Code Assumptions in Xt Code
  5. Message-ID: <1992Nov6.164950.4337@spcvxb.spc.edu>
  6. Date: 6 Nov 92 21:49:50 GMT
  7. Organization: St. Peter's College, US
  8. Lines: 47
  9.  
  10.  
  11.  Hi,
  12.  
  13.     I  don't  know who to inform about bugs in the X11R5 distribution, but I 
  14.  have found two today. Both bugs are due to the same oversight on  the  part 
  15.  of  the  programmer,  and  both  problems  relate to the X-Toolkit library. 
  16.  Someone it seems has made  the  mistaken  assumption  that  sizeof(int)  == 
  17.  sizeof(long).  
  18.  
  19.     The first example of where this is a problem in the  module  Resources.c 
  20.  in the Xt library. The function _XtDependencies() casts a XtResourceList to 
  21.  a  XrmResourceList.  If you examine the respective definitions of these two 
  22.  objects you will see that the 5th field of the XtResourceList is a Cardinal 
  23.  object  (typedef'ed  as  an  unsigned  int),  and  the  5th  field  of  the 
  24.  XrmResourceList is  a  long  int  object.   This  makes  structure  pointer 
  25.  arithmatic performed later invalid.
  26.  
  27.     To  correct  this  situation,  you  must alter one of the definitions to 
  28.  match the other. I have opted to change the long  int  declaration  in  the 
  29.  XrmResourceList object to a Cardinal. Hopefully this will work.
  30.  
  31.     The second  mistake  is  more  complicated,  but  stems  from  the  same 
  32.  erroneous  assumption.  It is also in the Xt library, but is in the Error.c 
  33.  module. There are two methods meant  to  provide  default  error  handling, 
  34.  _XtDefaultErrorMsg() and _XtDefaultWarningMsg(). Both of these methods 
  35.  invoke the sprintf method (the invokation is the problem).
  36.  
  37.     The first thing that each function  does  is  set  up  a  locale  String 
  38.  parm[10] object, and initialize it with the variable arguments passed.  The 
  39.  sprintf  function  is then called, with each of the 10 String objects being 
  40.  passed as parameters. The problem ocurrs if the format string passed to the 
  41.  method specifies %d. The sprintf method (on a 16-bit machine), will  assume 
  42.  that  16  bits  are  on the stack, and bump the va_list pointer to the next 
  43.  stack object.  Since String objects are actually typedef'ed  char  pointers 
  44.  (which  work  out  to 32-bits in compact, large and huge memory models) the 
  45.  sprintf method will not have bumped passed the  arg.  The  next  arg  fetch 
  46.  using va_arg(), will retrieve bad data.
  47.  
  48.     The only way to  solve  this  problem  is  to  write  a  custom  sprintf 
  49.  function, and replace all calls to the library sprintf to this sprintf. The 
  50.  custom method may then retrieve each parameter as a 32-bit object, but only 
  51.  use what portion of it it needs.
  52.  
  53.  Please Forward all comments to Me
  54.  
  55.  Jim Carroll
  56.    
  57.