* Address to function pointer conversion @ 1997-06-13 0:00 Michael Paus 1997-06-13 0:00 ` Samuel Mize ` (3 more replies) 0 siblings, 4 replies; 21+ messages in thread From: Michael Paus @ 1997-06-13 0:00 UTC (permalink / raw) Hi, I just stumbled over a little problem. I have a system address and I would like to convert it to an access to function type. How can this be done correctly? There is a generic package System.Address_To_Access_Conversions which takes an object type and then provides an access to object type and the appropriate conversion routines from address to access type and vice versa. But, what is the object of an access to function type here which I need to instantiate this package? Any suggestions are welcome. Michael PS: I currently just use an unchecked conversion which just works fine, but that's not the answer I am looking for. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Address to function pointer conversion 1997-06-13 0:00 Address to function pointer conversion Michael Paus @ 1997-06-13 0:00 ` Samuel Mize 1997-06-14 0:00 ` Robert Dewar 1997-06-13 0:00 ` John G. Volan ` (2 subsequent siblings) 3 siblings, 1 reply; 21+ messages in thread From: Samuel Mize @ 1997-06-13 0:00 UTC (permalink / raw) In article <5nrq5h$13cm@info4.rus.uni-stuttgart.de>, Michael Paus <michael@ifr16.luftfahrt.uni-stuttgart.de> wrote: [reformatted for length] > I just stumbled over a little problem. I have a system address and I > would like to convert it to an access to function type. How can this > be done correctly? Depends on how you define "correctly." There is no such conversion defined within the language, because the language would need some way to verify that this address is the correct place to enter a routine with the given profile. >PS: I currently just use an unchecked conversion which just works fine, That's the only way I can imagine. It is NOT "incorrect", but it IS extremely compiler-dependent. If you port to a different platform, compiler brand, or compiler VERSION, you'll need to re-verify that this works right. Sam Mize -- Samuel Mize -- smize@imagin.net -- Team Ada (personal net account) ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Address to function pointer conversion 1997-06-13 0:00 ` Samuel Mize @ 1997-06-14 0:00 ` Robert Dewar 0 siblings, 0 replies; 21+ messages in thread From: Robert Dewar @ 1997-06-14 0:00 UTC (permalink / raw) Sam says <<Depends on how you define "correctly." There is no such conversion defined within the language, because the language would need some way to verify that this address is the correct place to enter a routine with the given profile.>> It is worse than that. There is no guarantee at all that an access to function value looks anything like an address. Indeed, on the list of future enhancements for GNAT is to replace the current inefficient use of trampolines for pointers to nested functions by using "fat" pointers that will have two items 1) the address of the code 2) the static link And this is indeed probably the most sensible data structure to use for a pointer to a function (it is what is often used in Pascal and PL/1 compilers for example). This means that even if UC is working today in GNAT on some implementation, it may suddenly stop working in the future. What would be helpful is to know why you would want to do such a strange thing ... \x1adp ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Address to function pointer conversion 1997-06-13 0:00 Address to function pointer conversion Michael Paus 1997-06-13 0:00 ` Samuel Mize @ 1997-06-13 0:00 ` John G. Volan 1997-06-14 0:00 ` Robert Dewar 1997-06-14 0:00 ` Robert Dewar 1997-06-14 0:00 ` Robert A Duff 3 siblings, 1 reply; 21+ messages in thread From: John G. Volan @ 1997-06-13 0:00 UTC (permalink / raw) Michael Paus wrote: > > Hi, > > I just stumbled over a little problem. I have a system address and I would > like to > convert it to an access to function type. How can this be done correctly? > There is > a generic package System.Address_To_Access_Conversions which takes an > object type and then provides an access to object type and the appropriate > conversion routines from address to access type and vice versa. But, what is > the object of an access to function type here which I need to instantiate > this > package? Any suggestions are welcome. > > Michael > > PS: I currently just use an unchecked conversion which just works fine, but > that's not the answer I am looking for. Hmm, I think the answer may be that this sort of thing might just be beyond the scope of the Ada95 standard. In other words, this may be an implementation-specific (maybe even an OS-specific) thing not defined by Ada95. There may be no guaranteed portable way to take the address of a routine (I assume imported from some other language, such as C) and turn it into an access-to-subprogram. In that case, if you have an implementation specific solution that works, you may just have to live with the lack of portability. But what exactly are you trying to do? How are you acquiring this routine address? One thing people often overlook when they write bindings to other languages is the fact that it makes absolutely no difference what Ada data type you map to a given type from, e.g, C, as long as the bit representations match. In particular, there is no compelling reason a priori to favor an Ada type that provides a "lower-level" abstraction over one that provides a "higher-level" abstraction, as long as the representations match. In other words, suppose you're acquiring a function-pointer by calling some C function, such as: typedef void (*)() CallbackPtr; // arggh, is this the right syntax?? CallbackPtr getCallback (); Who says you have to map CallbackPtr to System.Address in Ada? Maybe you can map it directly into an access-to-subprogram type. If so, then you can completely avoid the System.Address middleman and the whole issue of what to convert it to: type Callback_Access_Type is access procedure; pragma Convention (C, Callback_Access_Type); -- ** is this right? function Get_Callback return Callback_Access_Type; pragma Import (C, Get_Callback, "getCallback"); ** What I don't know here is whether this Convention pragma is correct. But if it is, then this would be a guaranteed portable mechanism for doing what you want. However, the issue may be even simpler than this. Does your Ada program really need to be blind to what functions this pointer might be pointing to? In other words, does your getCallback function (or whatever) really need to be written in C? Could it be written on the Ada95 side instead? If so, then you could just statically bind to all the possible functions and not worry about a convention for Callback_Access_Type: procedure Callback_1; pragma Import (C, Callback_1, "callback1"); procedure Callback_2; pragma Import (C, Callback_2, "callback2"); ... procedure Callback_N; pragma Import (C, Callback_N, "callbackN"); type Callback_Access_Type is access procedure; function Get_Callback return Callback_Access_Type is begin -- the "..." lines below represent -- some kind of conditional structure -- (could be case, could be a bunch of ifs, whatever) ... return Callback_1'Access; ... return Callback_2'Access; ... . . . ... return Callback_N'Access; ... end Get_Callback; ------------------------------------------------------------------------ Internet.Usenet.Put_Signature (Name => "John G. Volan", Employer => "Texas Instruments Advanced C3I Systems, San Jose, CA", Work_Email => "johnv@ti.com", Home_Email => "johnvolan@sprintmail.com", Slogan => "Ada95: World's *FIRST* International-Standard OOPL", Disclaimer => "My employer never defined these opinions, so using " & "them would be totally erroneous...or is that just " & "nondeterministic behavior now? :-) "); ------------------------------------------------------------------------ ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Address to function pointer conversion 1997-06-13 0:00 ` John G. Volan @ 1997-06-14 0:00 ` Robert Dewar 1997-06-17 0:00 ` John G. Volan 0 siblings, 1 reply; 21+ messages in thread From: Robert Dewar @ 1997-06-14 0:00 UTC (permalink / raw) John says ~ <<Hmm, I think the answer may be that this sort of thing might just be beyond the scope of the Ada95 standard. In other words, this may be an implementation-specific (maybe even an OS-specific) thing not defined by Ada95. There may be no guaranteed portable way to take the address of a routine (I assume imported from some other language, such as C) and turn it into an access-to-subprogram. In that case, if you have an implementation specific solution that works, you may just have to live with the lack of portability. >> ~ ~ ~ If the address is coming from C, then I think the following should be quite portable: ~ type x is access procedure .... pragma Convention (C, X); ~ function Get_Address return x; pragma Import (C, Get_Address); Now your compiler might reject the pragma Convention on X, but it is reasonable that it shouold be supported, and if it is supported, then it should work. Notice this general approach, instead of importing some foreign gizmo from C like an address, import it in properly typed form, but apply pragma Convention C to the type. This is generally what should be done for access types as well when communicating with C. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Address to function pointer conversion 1997-06-14 0:00 ` Robert Dewar @ 1997-06-17 0:00 ` John G. Volan 1997-06-20 0:00 ` Robert Dewar 0 siblings, 1 reply; 21+ messages in thread From: John G. Volan @ 1997-06-17 0:00 UTC (permalink / raw) Robert Dewar wrote (quoting me): > > John says > ~ > <<Hmm, I think the answer may be that this sort of thing might just be > beyond the scope of the Ada95 standard. In other words, this may be an > implementation-specific (maybe even an OS-specific) thing not defined by > Ada95. There may be no guaranteed portable way to take the address of a > routine (I assume imported from some other language, such as C) and turn > it into an access-to-subprogram. In that case, if you have an > implementation specific solution that works, you may just have to live > with the lack of portability. > >> Later on in this same post which Robert quoted, I suggested: > type Callback_Access_Type is access procedure; > pragma Convention (C, Callback_Access_Type); -- ** is this right? > > function Get_Callback return Callback_Access_Type; > pragma Import (C, Get_Callback, "getCallback"); > > ** What I don't know here is whether this Convention pragma is correct. > But if it is, then this would be a guaranteed portable mechanism for > doing what you want. In his reply, Robert wrote: > If the address is coming from C, then I think the following should be quite > portable: > > type x is access procedure .... > pragma Convention (C, X); > > function Get_Address return x; > pragma Import (C, Get_Address); Excellent! Looks just like what I wrote. > Now your compiler might reject the pragma Convention on X, but it is reasonable > that it shouold be supported, and if it is supported, then it should work. > > Notice this general approach, instead of importing some foreign gizmo from C > like an address, import it in properly typed form, but apply pragma Convention > C to the type. > > This is generally what should be done for access types as well when > communicating with C. Thank you Robert, that answers my question. I didn't know whether this pragma was available for access-to-subprogram types. (I was making an informed guess.) ------------------------------------------------------------------------ Internet.Usenet.Put_Signature (Name => "John G. Volan", Employer => "Texas Instruments Advanced C3I Systems, San Jose, CA", Work_Email => "jvolan@ti.com", Home_Email => "johnvolan@sprintmail.com", Slogan => "Ada95: World's *FIRST* International-Standard OOPL", Disclaimer => "My employer never defined these opinions, so using " & "them would be totally erroneous...or is that just " & "nondeterministic behavior now? :-) "); ------------------------------------------------------------------------ ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Address to function pointer conversion 1997-06-17 0:00 ` John G. Volan @ 1997-06-20 0:00 ` Robert Dewar 1997-06-24 0:00 ` Matthew Heaney 0 siblings, 1 reply; 21+ messages in thread From: Robert Dewar @ 1997-06-20 0:00 UTC (permalink / raw) John said <<Thank you Robert, that answers my question. I didn't know whether this pragma was available for access-to-subprogram types. (I was making an informed guess.) >> It is obviously not *required* to be available, but it likely will work fine. If it is rejected, this is a red flag that the interface will not work. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Address to function pointer conversion 1997-06-20 0:00 ` Robert Dewar @ 1997-06-24 0:00 ` Matthew Heaney 1997-06-24 0:00 ` Robert Dewar 0 siblings, 1 reply; 21+ messages in thread From: Matthew Heaney @ 1997-06-24 0:00 UTC (permalink / raw) In article <dewar.866852244@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) wrote: ><<Thank you Robert, that answers my question. I didn't know whether this >pragma was available for access-to-subprogram types. (I was making an >informed guess.) > >> > >It is obviously not *required* to be available, but it likely will work fine. >If it is rejected, this is a red flag that the interface will not work. I'm confused by this answer. Do you mean If it is accepted, then it is guaranteed to work. or do you mean If it is accepted, it is not guaranteed to work, but is still likely to work anyway. When you say "but it will likely will work fine," are you describing the case when the pragma is accepted? Or that "it will likely work fine" even if the pragma isn't accepted? I'm confused because if the pragma is accepted, "likely is work fine" isn't how I would like to see it described. I'd rather you say, "If the pragma is accepted, then it is guaranteed to work." Having something compile without error, and then describing that program as "likely to work" doesn't give one a high degree of confidence, n'est-ce pas? -------------------------------------------------------------------- Matthew Heaney Software Development Consultant <mailto:matthew_heaney@acm.org> (818) 985-1271 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Address to function pointer conversion 1997-06-24 0:00 ` Matthew Heaney @ 1997-06-24 0:00 ` Robert Dewar 1997-06-25 0:00 ` Michael Paus 0 siblings, 1 reply; 21+ messages in thread From: Robert Dewar @ 1997-06-24 0:00 UTC (permalink / raw) Matthew Heaney asks <<I'm confused by this answer. Do you mean If it is accepted, then it is guaranteed to work. or do you mean If it is accepted, it is not guaranteed to work, but is still likely to work anyway. When you say "but it will likely will work fine," are you describing the case when the pragma is accepted? Or that "it will likely work fine" even if the pragma isn't accepted? I'm confused because if the pragma is accepted, "likely is work fine" isn't how I would like to see it described. I'd rather you say, "If the pragma is accepted, then it is guaranteed to work." Having something compile without error, and then describing that program as "likely to work" doesn't give one a high degree of confidence, n'est-ce pas? >> Robert replies The trouble is that "works" here is not well defined, it depends on exactly what you are doing, for example, if the C program you call raises a signal, what happens? Not clear. So likely to work is indeed a reasonable way of saying, on an informal basis, that, based on a best guess of what you might expect to work, it will work. Other things that might cause trouble are varargs for example. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Address to function pointer conversion 1997-06-24 0:00 ` Robert Dewar @ 1997-06-25 0:00 ` Michael Paus 0 siblings, 0 replies; 21+ messages in thread From: Michael Paus @ 1997-06-25 0:00 UTC (permalink / raw) In <dewar.867185277@merv> Robert Dewar wrote: > Matthew Heaney asks > > <<I'm confused by this answer. Do you mean > > If it is accepted, then it is guaranteed to work. > > or do you mean > > Robert replies > > The trouble is that "works" here is not well defined, it depends on exactly > what you are doing, for example, if the C program you call raises a signal, > what happens? Not clear. So likely to work is indeed a reasonable way of > saying, on an informal basis, that, based on a best guess of what you > might expect to work, it will work. Other things that might cause trouble > are varargs for example. > So, what you say here is that if the pragma is accepted the program is guaranteed to work exactly as reliable as any other program which directly interfaces to some C function because the potential problems you have mentioned will always make an Ada program which interfaces to a foreign language somewhat less reliable than a pure Ada program. I think everybody knows this and nobody will expect more. Michael ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Address to function pointer conversion 1997-06-13 0:00 Address to function pointer conversion Michael Paus 1997-06-13 0:00 ` Samuel Mize 1997-06-13 0:00 ` John G. Volan @ 1997-06-14 0:00 ` Robert Dewar 1997-06-16 0:00 ` Michael Paus 1997-06-14 0:00 ` Robert A Duff 3 siblings, 1 reply; 21+ messages in thread From: Robert Dewar @ 1997-06-14 0:00 UTC (permalink / raw) Michael says <<I just stumbled over a little problem. I have a system address and I would like to convert it to an access to function type. How can this be done correctly? There is a generic package System.Address_To_Access_Conversions which takes an object type and then provides an access to object type and the appropriate conversion routines from address to access type and vice versa. But, what is the object of an access to function type here which I need to instantiate this package? Any suggestions are welcome. Michael PS: I currently just use an unchecked conversion which just works fine, but that's not the answer I am looking for. >> Well, it is the only possible answer! It is clear that the language provides no such capability, because the very *idea* of converting an address to an access-to-function type is highly implementation dependent. What makes you think that an access-to-function value is anything like an address? It often is not. For example, in gcc it is often the address of a trampoline on a local stack. In the DEC ABI, an access to function value is a pointer to a procedure descriptor. Unchecked conversion may work on one particular implementation, and you feel nervous using it, because you are afraid that it might be implementation dependent. GOOD! You should feel nervous, whatever you feel you need this for should be reconsidered carefully, since you are venturing into the areas of highly non-portable code. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Address to function pointer conversion 1997-06-14 0:00 ` Robert Dewar @ 1997-06-16 0:00 ` Michael Paus 1997-06-16 0:00 ` Robert A Duff 1997-06-16 0:00 ` Robert Dewar 0 siblings, 2 replies; 21+ messages in thread From: Michael Paus @ 1997-06-16 0:00 UTC (permalink / raw) The problem which I have mentioned in my original post arises when you want to interface an Ada program to a C function which can return pointers to different functions like, e.g. dlsym on some UNIX systems or GetProcAddress on Windows NT. These functions are essential when you want to open a shared library (or DLL) dynamically at runtime of your program and access functions contained in this library. Depending on the given argument (a string with the name of the function) you get a void pointer to this function which you just cast to the appropriate pointer type in C. So, how would you do that in Ada? System.Address_To_Access_Conversions does not work as I have pointed out already in my first post. An unchecked conversion may also be problematic and is not portable. The only portable solution I see at the moment is to import the dlsym function several times for each anticipated function pointer type. This is not a very nice solution but I think it should work. Any comments are welcome. Michael ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Address to function pointer conversion 1997-06-16 0:00 ` Michael Paus @ 1997-06-16 0:00 ` Robert A Duff 1997-06-16 0:00 ` Robert Dewar 1 sibling, 0 replies; 21+ messages in thread From: Robert A Duff @ 1997-06-16 0:00 UTC (permalink / raw) In article <5o39sm$2fl6@info4.rus.uni-stuttgart.de>, Michael Paus <michael@ifr16.luftfahrt.uni-stuttgart.de> wrote: >...The only portable solution I see at the moment is to import the >dlsym function several times for each anticipated function pointer >type. This is not a very nice solution but I think it should work. The above sounds reasonable, if there aren't too many different such function prototypes. On the other hand, if you insist on the flexibility of the unchecked-conversion method, then it might make more sense to unchecked-convert from one access-to-subp type to another (both types being pragma Convention(C)). This is more likely to be portable in practise than unchecked-converting from type System.Address to access-to-subp. No guarantees, of course. - Bob ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Address to function pointer conversion 1997-06-16 0:00 ` Michael Paus 1997-06-16 0:00 ` Robert A Duff @ 1997-06-16 0:00 ` Robert Dewar 1997-06-16 0:00 ` Samuel Mize 1 sibling, 1 reply; 21+ messages in thread From: Robert Dewar @ 1997-06-16 0:00 UTC (permalink / raw) Michael said <<The problem which I have mentioned in my original post arises when you want to interface an Ada program to a C function which can return pointers to different functions like, e.g. dlsym on some UNIX systems or GetProcAddress on Windows NT. These functions are essential when you want to open a shared library (or DLL) dynamically at runtime of your program and access functions contained in this library. Depending on the given argument (a string with the name of the function) you get a void pointer to this function which you just cast to the appropriate pointer type in C. So, how would you do that in Ada? System.Address_To_Access_Conversions does not work as I have pointed out already in my first post. An unchecked conversion may also be problematic and is not portable. The only portable solution I see at the moment is to import the dlsym function several times for each anticipated function pointer type. This is not a very nice solution but I think it should work.>> Seems a nice solution to me, and indeed is entirely the appropriate solution in a strongly typed language! ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Address to function pointer conversion 1997-06-16 0:00 ` Robert Dewar @ 1997-06-16 0:00 ` Samuel Mize 1997-06-16 0:00 ` Robert A Duff 1997-06-17 0:00 ` Robert Dewar 0 siblings, 2 replies; 21+ messages in thread From: Samuel Mize @ 1997-06-16 0:00 UTC (permalink / raw) [quotations reformatted for line length] Robert Dewar wrote: > > Michael said > > <<The problem which I have mentioned in my original post arises > when you want to interface an Ada program to a C function which > can return pointers to different functions ... ... > [unchecked conversion] may also be problematic and is not > portable. The only portable solution I see at the moment is to > import the dlsym function several times for each anticipated > function pointer type. This is not a very nice solution but I > think it should work.>> > > Seems a nice solution to me, and indeed is entirely the > appropriate solution in a strongly typed language! I would agree EXCEPT -- dlsym is returning an address at run time, so you can't use pragma Import. You still have the problem, how do you call this address from Ada? It seems to me that you need a C function that takes an address and calls the function at that address. You can then pragma Import that function. If they're all "void FUNCTION (void)" this could be one C function. If they have different profiles, you would have several C interface functions with parameters, that call the function at "address" with the same parameters. Am I missing something simpler? Sam Mize -- -- Samuel Mize (817) 619-8622 smize@link.com "Team Ada" -- Hughes Training Inc. PO Box 6171 m/s 400, Arlington TX 76005 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Address to function pointer conversion 1997-06-16 0:00 ` Samuel Mize @ 1997-06-16 0:00 ` Robert A Duff 1997-06-17 0:00 ` Robert Dewar 1 sibling, 0 replies; 21+ messages in thread From: Robert A Duff @ 1997-06-16 0:00 UTC (permalink / raw) In article <33A5B0B3.7EA663D3@link.com>, Samuel Mize <smize@link.com> wrote: >I would agree EXCEPT -- dlsym is returning an address at run time, >so you can't use pragma Import. You still have the problem, how >do you call this address from Ada? True, but you can use pragma Convention(C) on the access-to-function type. Anyway, the caller needs to know what arguments to pass, so it's expecting some particular argument profile. So the caller, at least, ought to know what to do. - Bob ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Address to function pointer conversion 1997-06-16 0:00 ` Samuel Mize 1997-06-16 0:00 ` Robert A Duff @ 1997-06-17 0:00 ` Robert Dewar 1997-06-17 0:00 ` Samuel Mize 1 sibling, 1 reply; 21+ messages in thread From: Robert Dewar @ 1997-06-17 0:00 UTC (permalink / raw) Sam says <<I would agree EXCEPT -- dlsym is returning an address at run time, so you can't use pragma Import. You still have the problem, how do you call this address from Ada?>> No, on the Ada side the function which of course you Import (I don't understand your comment about not being able to use Import), returns an access to procedure value NOT an address. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Address to function pointer conversion 1997-06-17 0:00 ` Robert Dewar @ 1997-06-17 0:00 ` Samuel Mize 1997-06-20 0:00 ` Robert Dewar 1997-06-20 0:00 ` Robert Dewar 0 siblings, 2 replies; 21+ messages in thread From: Samuel Mize @ 1997-06-17 0:00 UTC (permalink / raw) Robert Dewar wrote: > > Sam says > > <<I would agree EXCEPT -- dlsym is returning an address at run time, > so you can't use pragma Import. You still have the problem, how > do you call this address from Ada?>> > > No, on the Ada side the function which of course you Import (I don't > understand your comment about not being able to use Import), returns > an access to procedure value NOT an address. I think I have put it together from several messages: - You specify one or more access-to-function types, with Convention(C). This way, whatever C uses as a pointer to a function -- in this case, an address -- can be called by Ada. This is what I didn't see how to do, but someone else pointed it out. - You import dlsym, which returns a pointer-to-function (an address). You possibly do this several times if you expect it to return functions with different profiles. Then you can call dlsym, and call what it returns. Sam Mize -- -- Samuel Mize (817) 619-8622 smize@link.com "Team Ada" -- Hughes Training Inc. PO Box 6171 m/s 400, Arlington TX 76005 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Address to function pointer conversion 1997-06-17 0:00 ` Samuel Mize @ 1997-06-20 0:00 ` Robert Dewar 1997-06-20 0:00 ` Robert Dewar 1 sibling, 0 replies; 21+ messages in thread From: Robert Dewar @ 1997-06-20 0:00 UTC (permalink / raw) Sam says <<- You import dlsym, which returns a pointer-to-function (an address). You possibly do this several times if you expect it to return functions with different profiles. Then you can call dlsym, and call what it returns.>> Be sure to use pragma Convention C *on the function types involved*, not just on the subprograms themselves. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Address to function pointer conversion 1997-06-17 0:00 ` Samuel Mize 1997-06-20 0:00 ` Robert Dewar @ 1997-06-20 0:00 ` Robert Dewar 1 sibling, 0 replies; 21+ messages in thread From: Robert Dewar @ 1997-06-20 0:00 UTC (permalink / raw) And Sam, do NOT assume that C represents a pointer to a function as an address, there is no such requirement in C. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Address to function pointer conversion 1997-06-13 0:00 Address to function pointer conversion Michael Paus ` (2 preceding siblings ...) 1997-06-14 0:00 ` Robert Dewar @ 1997-06-14 0:00 ` Robert A Duff 3 siblings, 0 replies; 21+ messages in thread From: Robert A Duff @ 1997-06-14 0:00 UTC (permalink / raw) In article <5nrq5h$13cm@info4.rus.uni-stuttgart.de>, Michael Paus <michael@ifr16.luftfahrt.uni-stuttgart.de> wrote: >I just stumbled over a little problem. I have a system address and I would >like to >convert it to an access to function type. How can this be done correctly? >There is >a generic package System.Address_To_Access_Conversions ... It doesn't work for access-to-subprograms. Where does this address come from? It might make sense to instead use an access-to-subp from the start, and apply pragma Convention(C) to the type, thus telling the compiler "represent this like the C compiler". - Bob ^ permalink raw reply [flat|nested] 21+ messages in thread
end of thread, other threads:[~1997-06-25 0:00 UTC | newest] Thread overview: 21+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1997-06-13 0:00 Address to function pointer conversion Michael Paus 1997-06-13 0:00 ` Samuel Mize 1997-06-14 0:00 ` Robert Dewar 1997-06-13 0:00 ` John G. Volan 1997-06-14 0:00 ` Robert Dewar 1997-06-17 0:00 ` John G. Volan 1997-06-20 0:00 ` Robert Dewar 1997-06-24 0:00 ` Matthew Heaney 1997-06-24 0:00 ` Robert Dewar 1997-06-25 0:00 ` Michael Paus 1997-06-14 0:00 ` Robert Dewar 1997-06-16 0:00 ` Michael Paus 1997-06-16 0:00 ` Robert A Duff 1997-06-16 0:00 ` Robert Dewar 1997-06-16 0:00 ` Samuel Mize 1997-06-16 0:00 ` Robert A Duff 1997-06-17 0:00 ` Robert Dewar 1997-06-17 0:00 ` Samuel Mize 1997-06-20 0:00 ` Robert Dewar 1997-06-20 0:00 ` Robert Dewar 1997-06-14 0:00 ` Robert A Duff
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox