NDK3.2r4: clib/asl_protos.h and Autodocs disagree on AslRequestTags()
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 |
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. |
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: Code:
APTR __stdargs AllocAslRequestTags( Is the solution to change it to: Code:
APTR __stdargs AllocAslRequestTags( Update: When I look at it after posting, it does not seem right. tag1 is not defined anywhere. Just used. |
After trying all options that threw compiler errors first, I got this to compile.
Code:
APTR __stdargs AllocAslRequestTags( Please confirm/deny. |
Quote:
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: Code:
APTR AllocAslRequestTags (ULONG type, ...) Code:
#include <stdarg.h> |
Quote:
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. Quote:
|
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. |
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. |
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. |
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.
|
Nice, thank you. I will do that then.
|
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. Quote:
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. Quote:
|
All times are GMT +2. The time now is 00:25. |
Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.