NO_INLINE_STDARG

[muibase]

I am trying to get my code compiled without using -DNO_LINE_STDARG, but haven't been able to figure out how.

Here is a short an example program.

Code: [Select]

// When commenting out this line, the code does not compile.
#define NO_INLINE_STDARG

#include <stdio.h>
#include <libraries/mui.h>
#include <proto/muimaster.h>
#include <proto/intuition.h>
#include <proto/exec.h>

struct Library *MUIMasterBase = NULL;
struct IClass *MyClass = NULL;

#define MyObject BOOPSIOBJMACRO_START(MyClass)

int main(void)
{
    MUIMasterBase = OpenLibrary((STRPTR)MUIMASTER_NAME, 0);
    if (MUIMasterBase == NULL) {
        printf("No MUI\n");
        return 10;
    }

    struct MUI_CustomClass *mcc =
        MUI_CreateCustomClass(NULL, (STRPTR)MUIC_Rectangle, NULL, 0, NULL);
    MyClass = mcc->mcc_Class;

    Object *app = ApplicationObject, End;

    Object *obj = MyObject, End;

    DisposeObject(obj);

    MUI_DisposeObject(app);

    CloseLibrary(MUIMasterBase);

    return 0;
}

 When commenting out the line "#define NO_INLINE_STDARG" the compiler says:

inline-stdargs.c: In function 'main':
inline-stdargs.c:39:0: error: unterminated argument list invoking macro "NewObject"
inline-stdargs.c:29:5: error: expected ',' or ';' at end of input
inline-stdargs.c:29:5: error: expected declaration or statement at end of input

The interesting thing here is that the line "app = ApplicationObject, End;" does compile fine.

Somehow there seems to be a difference here between MUI_NewObject (ApplicationObject) and NewObject (MyObject).

Has anyone figured out how to fix this compilation error?

[serk118uk]

[quote


The interesting thing here is that the line "app = ApplicationObject, End;" does compile fine.

Somehow there seems to be a difference here between MUI_NewObject (ApplicationObject) and NewObject (MyObject).

Has anyone figured out how to fix this compilation error?
[/quote]

I can confirm too mui_newobject fails and i used newobject instead of mui_newobject when porting amiIDE

[muibase]

I think you got it reversed: MUI_NewObject is fine but NewObject (from Intuition) gives compilation errors when compiling without -DNO_INLINE_STDARG.

I understand now why MUI_NewObject doesn't give compilation errors:

clib/muimaster_protos.h has these lines:

Code: [Select]

/
* By default, disable the variadic stuff for zune, since it's not
   very backward compatible */
#if !defined(MUIMASTER_YES_INLINE_STDARG)
#undef  MUIMASTER_NO_INLINE_STDARG
#define MUIMASTER_NO_INLINE_STDARG
#endif
This turns off the inlining for MUI_NewObject.

I wonder where/how this stdarg-inlining code actually compiles.  Anybody figured this out?

[deadwood]

I'm just looking at the same code

Indeed if you comment out tuning off of inlining for MUI, it fails the same way as for Intuition.

EDIT: I'll keep looking why this does not compile. The macros for NewObject and MUI_NewObject are autogenerated, so this might mean its a system wide issue (all varargs macros would have it :/)

[deadwood]

What is surprising, calling MUI_Request which uses the same autogenerated code as MUI_NewObject and NewObject does not break compilation :/

Edit: If you replace "End" with TAG_DONE), then it compiles:

Code: [Select]

    Object *app = ApplicationObject, TAG_DONE);

    Object *obj = MyObject, TAG_DONE);

There seems to be some negative interaction between "End" macro and probably AROS_PP_VARIADIC_CAST2IPTR.

[deadwood]

So far I came to this:

Code: [Select]

#define MyEnd   TAG_DONE
    Object *myapp = ApplicationObject, MyEnd);

This compiles, but if you move the closing parentesis to macro (as End has it => 'TAGDONE)' ), the you gen preprocessor error. I'll dig deeper into this later unless someone comes up with an answer.

[Mazze]

IIRC: if macros were becoming too complex you have to use MUIMASTER_YES_INLINE_STDARG. But then you need additional brackets. I don't know if that helps in this case.

[muibase]

I also noticed the TAG_DONE) trick.

I looked at the preprocessor output using "i386-aros-gcc -E":

Code: [Select]

...
int main(void)
{
    MUIMasterBase = __inline_Exec_OpenLibrary(((STRPTR)"muimaster.library"), (0), (SysBase));
    if (MUIMasterBase == ((void *)0)) {
        printf("No MUI\n");
        return 10;
    }

    struct MUI_CustomClass *mcc =
        __inline_MUIMaster_MUI_CreateCustomClass((((void *)0)), ((STRPTR)"Rectangle.mui"), (((void *)0)), (0), (((void *)0)), (MUIMasterBase));
    MyClass = mcc->mcc_Class;

    Object *app = MUI_NewObject("Application.mui", (0UL));

    Object *obj =
# 378 "/usr/local/aros-sdk/SDK-alt-abiv0-i386/include/libraries/mui.h" 3 4
                                       NewObject

and it simply stops in the middle of the " Object *obj = MyObject, End;" line

My hypothesis is that this is because NewObject itself is also a macro, so the pre-processor wants to find a closing parenthesis for doing the textual replacement of NewObject, but it hasn't processed the "End" define yet, and therefore fails.  Reading https://gcc.gnu.org/onlinedocs/cppinternals/Macro-Expansion.html it seems the pre-processing algorithm is such that it first wants to replace the NewObject macro before the End define, thus this might be working as intended.

I guess this means, one has one of the two choices:

• Use the MyObject, ApplicationObject, End, etc. defines but turn off inlining NewObject and MUI_NewObject through NO_INLINE_STDARG, or
  
• Don't use these defines and call NewObject and MUI_NewObject directly, or use TAG_DONE) instead of End.
  

 I think most code uses 1., thus maybe NO_INLINE_STDARG should be set as the default somewhere.  This also means AROS uses the AROS_SLOWSTACK code for both NewObject and MUI_NewObject.

[deadwood]

 I think most code uses 1., thus maybe NO_INLINE_STDARG should be set as the default somewhere.  This also means AROS uses the AROS_SLOWSTACK code for both NewObject and MUI_NewObject.

I also think this should be the approach, but it requires a deeper investigation in my opinion. For the time being I created a bug report: https://github.com/deadw00d/AROS/issues/54

[muibase]

On second thought, this applies only to MUI applications.  If some app uses Intuition/other toolkit then inlining NewObject might be just fine.  Also, it's probably enough to only disable inlining NewObject and MUI_NewObject.