02 January 2023, 09:06 | #1 |
Registered User
Join Date: Nov 2009
Location: Top of the world
Posts: 161
|
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 |
03 January 2023, 18:45 | #2 |
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,247
|
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. |
03 January 2023, 19:07 | #3 |
Registered User
Join Date: Nov 2009
Location: Top of the world
Posts: 161
|
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( ULONG type, Tag tag1,...) { return AllocAslRequest(type,(struct TagItem *)&tag1); } Is the solution to change it to: Code:
APTR __stdargs AllocAslRequestTags( ULONG type, ...) { return AllocAslRequest(type,(struct TagItem *)&tag1); } Update: When I look at it after posting, it does not seem right. tag1 is not defined anywhere. Just used. Last edited by hceline; 03 January 2023 at 19:17. Reason: On further thought.My solution does not seem right |
03 January 2023, 19:56 | #4 |
Registered User
Join Date: Nov 2009
Location: Top of the world
Posts: 161
|
After trying all options that threw compiler errors first, I got this to compile.
Code:
APTR __stdargs AllocAslRequestTags( ULONG type, ...) { Tag tag1; return AllocAslRequest(type,(struct TagItem *)&tag1); } Please confirm/deny. |
03 January 2023, 21:11 | #5 |
Registered User
Join Date: Jan 2002
Location: Germany
Posts: 7,005
|
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: Code:
APTR AllocAslRequestTags (ULONG type, ...) { return AllocAslRequest(type,(struct TagItem *)((&type) + 1)); } Code:
#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); } |
03 January 2023, 22:36 | #6 | |
Registered User
Join Date: Nov 2009
Location: Top of the world
Posts: 161
|
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. This compiled, will see if it works when I get the whole ting compiling. Last edited by hceline; 03 January 2023 at 22:42. Reason: Cleaned up quote, had a few irellevant lines. |
|
05 January 2023, 10:38 | #7 |
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,247
|
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. |
05 January 2023, 14:46 | #8 |
Registered User
Join Date: Nov 2009
Location: Top of the world
Posts: 161
|
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. |
05 January 2023, 18:58 | #9 |
Registered User
Join Date: Nov 2009
Location: Top of the world
Posts: 161
|
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. |
05 January 2023, 19:56 | #10 |
Registered User
Join Date: Dec 2017
Location: Austin, TX
Age: 41
Posts: 410
|
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.
|
05 January 2023, 22:02 | #11 |
Registered User
Join Date: Nov 2009
Location: Top of the world
Posts: 161
|
Nice, thank you. I will do that then.
|
06 January 2023, 16:10 | #12 | ||
Natteravn
Join Date: Nov 2009
Location: Herford / Germany
Posts: 2,510
|
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:
|
||
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
NDK3.2R4 looks to be available! | alancfrancis | News | 1 | 07 April 2022 04:25 |
Do you know RTG autodocs or tutorials? | doble07 | Coders. General | 10 | 20 December 2020 22:53 |
gcc clib for KS1.3 | sparhawk | Coders. C/C++ | 5 | 20 September 2019 19:34 |
Includes & Autodocs | Jherek Carnelia | request.Apps | 7 | 12 March 2002 00:09 |
|
|