Bug in wimp.h

David Bryan D.J.Bryan at cranfield.ac.uk
Thu Aug 24 03:47:45 BST 2000


Chris Rutter wrote:

> On Mon, 21 Aug 2000, Jonathan Coxhead wrote:
> 
> >  | The compiler's perfectly at liberty to feed you back nm[0] == '*' and
> >  | nm[1] == '\0' after that call, when clearly those memory locations will 
> >  | have been updated.
> > 
> >    Actually, it can't. The inside of wimp_load_template() (if written in C) 
> > would be completely within its rights to contain code like this:
> > 
> >       wimp_load_template (..., char const *name, ...)
> >       {
> >          char *name_var = (char *) name; /*cast away const*/
> >          name [0] = ...;
> >       }
> > 
> > and indeed, that's pretty much what it does.
> 
> Well, I'm aware that you can perform a const-removing cast and then
> write away, but don't you run the risk of invoking undefined behaviour?
> 
> I must have misunderstood the purpose of `const': in simple terms, I
> thought it was, amongst other things, to allow a function to declare
> `I don't modify the the object this pointer points to', so that the
> caller doesn't have to flush any cached values held in local/register
> memory from that object.
> 
> If this guarantee doesn't hold in this way, then what /is/ the purpose
> of `const'?

Yes, I thought Chris was right.  From K&R Second Ed.,

  The purpose of const is to announce objects that may be placed
  in read-only memory, and perhaps to increase opportunities for
  optimization.

I thought that compilers tended not to perform such optimisation,
because such pointer optimisation can be hard to get right, and
doesn't yield much improvement.

  void f1(char *)
  void f2(const char *)
  
  void f3(void)
  {
     char ca[32];
     
     f1(&ca[16]);
     ...
     ca[0] = '\0';
     f2(ca);
     /* Can't assume ca[0] == '\0' */
     ...
  }

I have heard that the MetaWare C compiler can perform such
optimisation.  (And, there's an ARM back end for it.)  Languages
without explicit pointers are better :-)
 
> Is there any analysis of the average space taken by OSLib veeners in
> OSLib-using RISC OS applications?

Negligible space.  (Most of the object file's bulk is symbol
tables etc.)

-- 
David Bryan




More information about the oslib-user mailing list