32 bit file handles

[Tony van der Hoff]

On 11 Nov 2001, in message <200111111246.MAA09980 at inputplus.demon.co.uk>,
Ralph Corderoy <ralph at inputplus.demon.co.uk> wrote:

> 
> Hi,
> 
> > #define osfind_openin osfind_openinw
> > 
> > Now, in h.osfind we have:
> > 
> > extern os_error *xosfind_openin (osfind_flags flags,
> >       char const *file_name,
> >       char const *path,
> >       os_f *file);
> > extern os_f osfind_openin (osfind_flags flags,
> >       char const *file_name,
> >       char const *path);
> > 
> > So, if that #define is included *before* these prototypes, as it
> > would be by DefMod, after name substitution we'd end up with two
> > identical prototypes, which I think would be faulted by the compiler.
> > Ugh!
> > 
> > ...
> >
> > I don't think there is any clever trickery one can play with the
> > preprocessor to achieve the correct result.
> 
> Howsabout
> 
>     #define osfind_openin(flags, file_name, path) \
>         osfind_openinw(flags, file_name, path)
> 
> then later
> 
>     os_f (osfind_openin)(osfind_flags flags, char const *file_name,
>         char const *path);
> 
[snip]
> 

I think I understand your intentions, but I'm not sure that I understand
how you're proposing to implement it.

If I read you correctly, you're suggesting modifying osfind.h. Remember,
that these headers are autogenerated by DefMod, so any such change would
have to be via DefMod, and carry across throughout OSLib. Limiting this is
the reasoning behind introducing the xxx32.h maually-generated extensions. 
I also believe that it is excessively restrictive to constrain the number of
parameters in a call by defining them in a macro.

I know my proposal involves modifying DefMod, but I believe it is less
far-reaching than what you're suggesting.
-- 
Tony van der Hoff         | MailTo:tony at mk-net.demon.co.uk
                          | MailTo:avanderhoff at iee.org
Buckinghamshire, England  | http:www.mk-net.demon.co.uk