messagetrans_error_lookup : wrong type

[Stewart Brodie]

In message <538714854a.Jo at village.uunet.be>
          John Tytgat <John.Tytgat at aaug.net> wrote:

> In message <38b3c5844a.Tony at mk-net.demon.co.uk>
>           Tony van der Hoff <tony at mk-net.demon.co.uk> wrote:
> 
> > However, even if we, for now, ignore backward compatibility issues, maybe it
> > would be slightly presumptious to assume that the user will always want to
> > pass a pointer to a 256-byte buffer. If we did, then we could default |size|
> > to that number as well. The fact that RISC OS doesn't assume that suggests
> > that we shouldn't.
> > 
> > On the other hand, I guess most users will want to do exactly what you're
> > suggesting, so perhaps the best solution would be to provide a new veneer:
> > 
> > extern os_error *xmessagetrans_error_lookup_tobuffer 
> >       (os_error const *error,
> >        messagetrans_control_block const *cb,
> >        os_error *buffer,
> >        char const *arg0,
> >        char const *arg1,
> >        char const *arg2,
> >        char const *arg3);
> > 
> > Has anyone any alternative/better suggestions (including name of new veneer)?
> 
> I would just change the 'char' into 'os_error'.  I don't think it is
> somewhere specified that the error buffer passed to messagetrans may
> not be longer or shorter than 256 bytes.  In most cases the users will
> want to pass 'sizeof(os_error)' as 'size' but they don't have to.  E.g.
> when they want to add some text afterwards and still want to stay into
> the 256 byte limit.

IME, most people pass 0 in R2 anyway (well all my software does ;-)

In this case, I would recommend just changing the char* to an os_error*.  It
is *NOT* legal for a char* to be passed to this SWI - because a char* may not
be aligned.  Callers are already probably having to cast their error block
points to char* to match the veneer.  This adjustment will permit the cast to
be removed.  Anybody passing 0 will be fine anyway.

-- 
Stewart Brodie, Senior Software Engineer    (Views expressed are my own and
Pace Micro Technology PLC                   not those of my employer)
645 Newmarket Road
Cambridge, CB5 8PB, United Kingdom         WWW: http://www.pacemicro.com/