Assembler header files

[Tony van der Hoff]

On 17 Sep 2002, in message <474f8e774b.philip at philipnet.com>,
Philip Ludlam <philip at philipnet.com> wrote:

> Hi All,
> 
> Some assembler related C work got me looking at the header (OSLib.Hdr.*)
> files in OSLib. Remembering past experiences with them I did wonder if
> they would all compile. It seems not. Happy fixing :-) !
> 
Urk! This shows up a hole in our pre-release testing, which needs to be
plugged as well as fixing these bugs. 

> In CD, the symbols CD_Audio and CD_DriveReady are defined twice.
> 
Indeed, once as a structure, and once as a constant. It doesn't affect
C mode because DEFMOD introduces a case difference. 

> In FontDbox, the symbol FontDbox_Font is defined twice.
> 
as above.

> In Iconbar there are four reports of Toolbox_o being undefined.
> 
Should be Toolbox_O in the source; The bug is masked in the C header, 'cos
everything there is translated to lower case.

> Error: Bad global name at line 11 in file OSLIB:oslib.Hdr.OSF32
>  included by GET/INCLUDE directive at line 11 in file
> "raFS::OSLIb.$.OsLib.OSlib.Hdr.OSCore32"
>    11 00000000  GBLS $OS_F Error: Unknown opcode at line 12 in file
> OSLIB:oslib.Hdr.OSF32
>  included by GET/INCLUDE directive at line 11 in file
> "raFS::OSLIb.$.OsLib.OSlib.Hdr.OSCore32"
>    12 00000000 $OS_F SETS OS_FW
> 
Hum. I think I've misunderstood OBJASM's variable substitution directive. I
guess the symbol name (in HDR.OSF32) should be just OS_F.

> In URL, the symbols URL_MethodCode and URL_MethodFlags are defined twice.
> 
Yes, as for CD.

> There are Multiply or incompatibility defined symbols (yuck!) messages
> for Window and Menu. There maybe more for some of the other toolbox
> related header files but ObjAsm's throwback is worse than useless in
> tracking down errors in included files :-(.
> 
I appreciate your problem in describing the problem, Phil; however, I can't
really do much with such a bug report, either.

> I would offer solutions, but not knowing the inside of OSLib and/or
> DefMod I wouldn't know where to start. But, in my opinion, backwards
> compatibility can be hung. The files as they stand don't compile so make
> whatever changes you feel are necessary to get them to.

Well, thanks for the bug report, anyway ;-)

We don't do bug compatibility, so that's not an issue here, but the problem
is more far-reaching than just these modules (apart from my silly in OS_F,
and the typo in IconBar), and the wrong choice could introduce accross the
board effects in the assembler headers, which we certainly don't want. 

One option is that it's fixed generically, such that DEFMOD distinguishes
between names of structures and names of constants in assembler headers, as
it does for C headers. That will undoubtedly introduce compatibility issues
in (assembler) headers which are currently error-free, although it could be
seen as correcting the code.

The alternative is to fix the duplicated names in (all) the source files in
a way that will generate valid assembler, without affecting the C headers.
Maybe DEFMOD should fault duplicate symbols such as these, instead of trying
to be clever by changing the case in specific instances.

Jonathan, can you advise which would be the correct choice from the OSLib
design-concept point of view?

I don't know when I'll be able to sort this, as I have rather a lot on my
plate at the mo. 

Cheers, Tony

-- 
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