Assembler header files

[Jonathan Coxhead]

   On 23 Sep 2002, at 12:38, Tony van der Hoff wrote:

> [...] 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.

   Let's call this option "a".

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

   And this one "b".
   
> Jonathan, can you advise which would be the correct choice from the OSLib
> design-concept point of view?

   I don't really know the answer to this. The original intent was that it 
should not happen. As you noted, the pre-release testing should catch such 
things before they see the light of day, and one name or the other (the 
structure or the constant) would be changed at that point.

   Now, I see 3 options: your a and b, and a third, c, which is the "design 
concept":

   Fix the duplicated names in (all) the source files in a way that will 
generate valid assembler, but *also* affecting the C headers.

   However, of the 3, I think a is by far the best, and I have a cunning 
plan :-). All we have to do is change one of the names so it generates the 
*same* C name. Admittedly this is very hacky and horrible! Let's take 
CD_DriveReady as an example. As a C structure, it's called cd_drive_ready, and 
as a C constant, CD_DRIVE_READY. (Option c would have us change the constant to 
something like CD_DriveIsReady, but this would break existing code---though the 
client code would get a compiler error, so maybe it's OK?)

   However, we can have option a, and compatibility too, if we change the name 
of the constant to CD_DRIVEReady in the DefMod file. This maps to 
cd_DRIVE_READY as a C constant, but is spelled differently as far as ObjAsm is 
concerned. It looks horrible, but it obeys all the rules. Similarly, CD_Audio 
should be the structure, and CD_AUDIO the constant: these each map to the same 
thing in C that they currently do (cd_audio, cd_AUDIO respectively), but are 
different in ObjAsm.

   They don't obey the naming convention (each word capitalised), which is a 
shame, but not critical. To make sure similar mistakes don't happen again, it 
would be necessary to make sure every header is run through ObjAsm as part of 
the OSLib release process. There used to be an ObjAsm source file that included 
(using GET) all the generated header files---maybe it could be resurrected?

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

   The other advantge of this is that it doesn't very long ... always an 
advantage for busy people!

   Cheers ...

        /|
 o o o (_|/
        /|
       (_/