NDK3.2r4: clib/asl_protos.h and Autodocs disagree on AslRequestTags()

[hceline]

In NDK3.2r4 clib/asl_protos.h claims that it's:
BOOL AslRequestTags( APTR requester, ... );

While the Autodocs in NDK2.3r4 say:
BOOL AslRequestTags(APTR,Tag,...);

I guess the Autodocs are right since that is in line with both includes and Autodocs for earlier releases.

Update: AllocAslRequestTags() has the same difference.

-Hagbard Celine

[Thomas Richter]

Both declarations are identical. The functions are varadic functions that take an opaque pointer as first argument, and a variable number of tags, terminated by TAG_DONE.

Actually, only AllocAslRequest() exists as library entry point, the "xxxTags()" function are generated by the compiler. This is very convenient as the compiler just provides a pointer to the tag list on the stack as second argument.

[hceline]

Ok, thank you for explaining.
Maybe this thread should have been in Coders.System instead, because I'm not quite sure I understand.

I got this code that compiles with older NDK:

APTR __stdargs AllocAslRequestTags(
    ULONG type,
    Tag tag1,...)
{
    return AllocAslRequest(type,(struct TagItem *)&tag1);
}

That fails with "Error 72: conflict with previous declaration See line 34 file "include:clib/asl_protos.h"

Is the solution to change it to:

APTR __stdargs AllocAslRequestTags(
    ULONG type,
    ...)
{
    return AllocAslRequest(type,(struct TagItem *)&tag1);
}

And that will work? Or am I missing something?
Update: When I look at it after posting, it does not seem right. tag1 is not defined anywhere. Just used.

[hceline]

After trying all options that threw compiler errors first, I got this to compile.

APTR __stdargs AllocAslRequestTags(
    ULONG type,
    ...)
{
    Tag tag1;
    return AllocAslRequest(type,(struct TagItem *)&tag1);
}

Don't know if its the correct fix for compiling under NDK3.2 though.
Please confirm/deny.

[thomas]

Originally Posted by hceline

Please confirm/deny.

It cannot work. Tag1 now is a local variable. Giving a pointer to a local variable to a function which expects an array of tag items will crash of course.

I am not sure what you are trying to do. As Thomas pointed out, the ...Tags() function should be provided by the compiler, it is not needed to make a stub for it.

But anyway, this could work for you:

APTR AllocAslRequestTags (ULONG type, ...)
{
    return AllocAslRequest(type,(struct TagItem *)((&type) + 1));
}

Or maybe even like so:

#include <stdarg.h>
APTR AllocAslRequestTags (ULONG type, ...)
{
    va_list taglist;
    va_start(taglist,type);
    APTR result = AllocAslRequest(type,(struct TagItem *)taglist);
    va_end(taglist);
    return (result);
}

[hceline]

Originally Posted by thomas

I am not sure what you are trying to do. As Thomas pointed out, the ...Tags() function should be provided by the compiler, it is not needed to make a stub for it.

I'm just trying to compile a old program, not written by me, with it's library with the new NDK.
I thought it might be a simple way to test my new install/compiler setup, as I had an easy time updating it for NDK3.1 earlier.

Originally Posted by thomas

But anyway, this could work for you:

APTR AllocAslRequestTags (ULONG type, ...)
{
    return AllocAslRequest(type,(struct TagItem *)((&type) + 1));
}

This compiled, will see if it works when I get the whole ting compiling.

[Thomas Richter]

Thomas' second solution based on va_start is the correct one "by the letter", even though it is for most (all?) Amiga compilers equivalent to the first. I suggest to go for the clean way and work on top of va_start.

Anyhow, the typical solution here would be rather to generate compiler prototypes from the .fd file through FD2Pragma (from aminet). This will, for example for the SAS/C compiler, result in a #pragma that automatically takes the stack pointer as second argument for the tag call, so no stub function is needed.

[hceline]

While working through the code and updating it for NDK3.2, looking at the headers and the supplied documentation/examples. I began to realize that this was what both of you and NDK3.2R4/DeveloperDocumentation/InterfaceHeaderFiles was conveying that I did not fully comprehend:
If I include clib/asl_protos.h and pragmas/asl_pragmas.h, I can just delete the code in question from the program.
Unless I'm still totally misunderstanding something. Still haven't got to the point where I can test if it runs, but that part compiles with this change.

And thanks to both of you for bearing with me.

[hceline]

I am sorry if my last post seems redundant, as I probably just reiterated what Thomas Richter posted just above with other words.
I once was so unlucky as to crack my skull open, and have since then had difficulties with written text.
I can read a text, and get part of it's meaning. And then during the next hour or day, I can slowly realize the full meaning. And in context the part I understood to begin with changes meaning. This makes me constantly question my understanding of what I read even if the message is quite obvious.
When I post myself I use a spellchecker and prof-reed several times. But still when I read it back some minutes after posting, I usually find words in the wrong place and words that mean something else but contains almost the same letters as the intended word.

Just felt I had to say this, because when I read back the two last posts now. I feel like, well if the roles where reversed my answer might have been: YEA, wasn't this what I just told you.

[arcanist]

I think the general recommendation is to include <proto/asl.h>, which will pick up a compiler-supplied header or the NDK header. That will choose the best library interface for your compiler.

[hceline]

Nice, thank you. I will do that then.

[phx]

Arcanist is right.

<proto/...>

is the way to go. It makes sure that all prototypes and compiler specific enhancements (like pragmas, inlines) are included. Never include some

<inline[s]/..>

or

<pragma[s]/...>

file directly, as it makes your source compiler-specific.
Include

<clib/...>

instead of

<proto/...>

if you absolutely want, for whatever reason, to use stub routines from amiga.lib to call OS functions and avoid inline calls.

Originally Posted by Thomas Richter

Thomas' second solution based on va_start is the correct one "by the letter",

It may work with most AmigaOS/68k compilers, but I wouldn't call it correct.
You shouldn't cast a va_list to some pointer. A va_list can be anything. For example a complex structure, for ABIs using arguments in registers, like PPC.

even though it is for most (all?) Amiga compilers equivalent to the first.

Not sure. Maybe there are gcc ports with a broken standard ABI (passing arguments in registers by default)?