Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #66125 > unrolled thread

Generic function-calling code

Back to article view | Back to comp.lang.c

Contents

  Generic function-calling code Bartc <bc@freeuk.com> - 2015-07-21 21:21 +0100
    Re: Generic function-calling code jacobnavia <jacob@jacob.remcomp.fr> - 2015-07-21 23:04 +0200
      Re: Generic function-calling code luser droog <luser.droog@gmail.com> - 2015-07-21 14:45 -0700
        Re: Generic function-calling code Bartc <bc@freeuk.com> - 2015-07-22 00:56 +0100
          Re: Generic function-calling code BGB <cr88192@hotmail.com> - 2015-07-22 00:25 -0500
            Re: Generic function-calling code "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-22 02:37 -0700
              Re: Generic function-calling code Bartc <bc@freeuk.com> - 2015-07-22 11:50 +0100
                Re: Generic function-calling code "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-22 04:29 -0700
                  Re: Generic function-calling code Bartc <bc@freeuk.com> - 2015-07-22 13:04 +0100
                    Re: Generic function-calling code "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-22 05:44 -0700
                AVCALL (from the 'ffcall' package) really is the answer! (Was: Generic function-calling code) gazelle@shell.xmission.com (Kenny McCormack) - 2015-07-22 12:50 +0000
                  Re: AVCALL (from the 'ffcall' package) really is the answer! (Was: Generic function-calling code) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-22 06:07 -0700
                    Let's see who can be the most off-topic (Was: AVCALL ...) Generic function-calling code) gazelle@shell.xmission.com (Kenny McCormack) - 2015-07-22 13:30 +0000
                      Re: Let's see who can be the most off-topic (Was: AVCALL ...) Generic function-calling code) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-22 07:42 -0700
                        Re: Let's see who can be the most off-topic (Was: AVCALL ...) Generic function-calling code) David Brown <david.brown@hesbynett.no> - 2015-07-22 17:07 +0200
                          Re: Let's see who can be the most off-topic (Was: AVCALL ...) Generic function-calling code) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-22 08:16 -0700
                          Re: Let's see who can be the most off-topic (Was: AVCALL ...) Generic function-calling code) Keith Thompson <kst-u@mib.org> - 2015-07-22 08:41 -0700
                            Re: Let's see who can be the most off-topic (Was: AVCALL ...) Generic function-calling code) Keith Thompson <kst-u@mib.org> - 2015-07-22 08:47 -0700
                              Re: Let's see who can be the most off-topic (Was: AVCALL ...) Generic function-calling code) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-22 08:53 -0700
                              Re: Let's see who can be the most off-topic (Was: AVCALL ...) Generic function-calling code) David Brown <david.brown@hesbynett.no> - 2015-07-22 18:09 +0200
                            Re: Let's see who can be the most off-topic (Was: AVCALL ...) Generic function-calling code) David Kleinecke <dkleinecke@gmail.com> - 2015-07-22 16:38 -0700
                          Re: Let's see who can be the most off-topic (Was: AVCALL ...) Generic function-calling code) Richard Heathfield <rjh@cpax.org.uk> - 2015-07-22 18:28 +0100
                            Re: Let's see who can be the most off-topic (Was: AVCALL ...) Generic function-calling code) James Kuyper <jameskuyper@verizon.net> - 2015-07-22 13:37 -0400
                              Re: Let's see who can be the most off-topic (Was: AVCALL ...) Generic function-calling code) BGB <cr88192@hotmail.com> - 2015-07-22 15:04 -0500
                            Re: Let's see who can be the most off-topic (Was: AVCALL ...) Generic function-calling code) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-22 10:39 -0700
                              Re: Let's see who can be the most off-topic (Was: AVCALL ...) Generic function-calling code) Richard Heathfield <rjh@cpax.org.uk> - 2015-07-22 19:10 +0100
                                Re: Let's see who can be the most off-topic (Was: AVCALL ...) Generic function-calling code) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-22 11:39 -0700
                                  Re: Let's see who can be the most off-topic (Was: AVCALL ...) Generic function-calling code) Richard Heathfield <rjh@cpax.org.uk> - 2015-07-22 20:01 +0100
                                    Re: Let's see who can be the most off-topic (Was: AVCALL ...) Generic function-calling code) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-22 12:06 -0700
                                      Re: Let's see who can be the most off-topic (Was: AVCALL ...) Generic function-calling code) Richard Heathfield <rjh@cpax.org.uk> - 2015-07-22 20:51 +0100
                                      Re: Let's see who can be the most off-topic (Was: AVCALL ...) Generic function-calling code) guinness.tony@gmail.com - 2015-07-22 17:48 -0700
                                  Re: Let's see who can be the most off-topic (Was: AVCALL ...) Generic function-calling code) raltbos@xs4all.nl (Richard Bos) - 2015-07-22 19:50 +0000
                                    Re: Let's see who can be the most off-topic (Was: AVCALL ...) Generic function-calling code) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-22 13:15 -0700
                                      Re: Let's see who can be the most off-topic (Was: AVCALL ...) Generic function-calling code) Richard Heathfield <rjh@cpax.org.uk> - 2015-07-22 21:28 +0100
                                        Re: Let's see who can be the most off-topic Gareth Owen <gwowen@gmail.com> - 2015-07-22 21:44 +0100
                                      Re: Let's see who can be the most off-topic (Was: AVCALL ...) Generic function-calling code) Morris Dovey <mrdovey@iedu.com> - 2015-07-22 16:35 -0500
                                        Re: Let's see who can be the most off-topic (Was: AVCALL ...) Generic function-calling code) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-22 15:17 -0700
                                          Re: Let's see who can be the most off-topic (Was: AVCALL ...) Generic function-calling code) Morris Dovey <mrdovey@iedu.com> - 2015-09-05 15:20 -0500
                                            Re: Let's see who can be the most off-topic (Was: AVCALL ...) Generic function-calling code) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-05 23:01 -0700
                                              Re: Let's see who can be the most off-topic (Was: AVCALL ...) Generic function-calling code) wssimms@gmail.com - 2015-09-06 01:58 -0700
                                                Re: Let's see who can be the most off-topic (Was: AVCALL ...) Generic function-calling code) Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-06 02:28 -0700
                                                  Re: Let's see who can be the most off-topic (Was: AVCALL ...) Generic function-calling code) Keith Thompson <kst-u@mib.org> - 2015-09-06 12:48 -0700
                                                Re: Let's see who can be the most off-topic (Was: AVCALL ...) Generic function-calling code) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-06 07:08 -0700
                                  Re: Let's see who can be the most off-topic (Was: AVCALL ...) Generic function-calling code) Keith Thompson <kst-u@mib.org> - 2015-07-22 13:50 -0700
                              Re: Let's see who can be the most off-topic Gareth Owen <gwowen@gmail.com> - 2015-07-22 21:43 +0100
                                Re: Let's see who can be the most off-topic guinness.tony@gmail.com - 2015-07-22 17:43 -0700
                                  Re: Let's see who can be the most off-topic James Kuyper <jameskuyper@verizon.net> - 2015-07-24 10:41 -0400
                                    Re: Let's see who can be the most off-topic Richard Heathfield <rjh@cpax.org.uk> - 2015-07-24 16:01 +0100
                                      Re: Let's see who can be the most off-topic raltbos@xs4all.nl (Richard Bos) - 2015-07-25 19:20 +0000
                                    Re: Let's see who can be the most off-topic Gareth Owen <gwowen@gmail.com> - 2015-07-24 20:25 +0100
                        Re: Let's see who can be the most off-topic (Was: AVCALL ...) Generic function-calling code) Rosario19 <Ros@invalid.invalid> - 2015-07-23 20:41 +0200
                          Re: Let's see who can be the most off-topic (Was: AVCALL ...) Generic function-calling code) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-23 12:00 -0700
                  Re: AVCALL (from the 'ffcall' package) really is the answer! (Was: Generic function-calling code) Bartc <bc@freeuk.com> - 2015-07-22 17:43 +0100
                    Re: AVCALL (from the 'ffcall' package) really is the answer! (Was: Generic function-calling code) gazelle@shell.xmission.com (Kenny McCormack) - 2015-07-22 19:36 +0000
                      Re: AVCALL (from the 'ffcall' package) really is the answer! (Was: Generic function-calling code) Bartc <bc@freeuk.com> - 2015-07-22 23:19 +0100
                        Re: AVCALL (from the 'ffcall' package) really is the answer! (Was: Generic function-calling code) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-22 15:43 -0700
                        Re: AVCALL (from the 'ffcall' package) really is the answer! (Was: Generic function-calling code) Bartc <bc@freeuk.com> - 2015-07-22 23:47 +0100
                          Re: AVCALL (from the 'ffcall' package) really is the answer! (Was: Generic function-calling code) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-23 04:44 -0700
                            Re: AVCALL (from the 'ffcall' package) really is the answer! (Was: Generic function-calling code) Bartc <bc@freeuk.com> - 2015-07-23 13:14 +0100
                              Re: AVCALL (from the 'ffcall' package) really is the answer! (Was: Generic function-calling code) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-23 06:26 -0700
                                Re: AVCALL (from the 'ffcall' package) really is the answer! (Was: Generic function-calling code) Bartc <bc@freeuk.com> - 2015-07-23 15:00 +0100
                                  Re: AVCALL (from the 'ffcall' package) really is the answer! (Was: Generic function-calling code) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-23 07:13 -0700
                              Re: AVCALL (from the 'ffcall' package) really is the answer! (Was: Generic function-calling code) Bartc <bc@freeuk.com> - 2015-07-23 18:02 +0100
                                Re: AVCALL (from the 'ffcall' package) really is the answer! (Was: Generic function-calling code) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-23 10:05 -0700
                                  Re: AVCALL (from the 'ffcall' package) really is the answer! (Was: Generic function-calling code) Bartc <bc@freeuk.com> - 2015-07-23 18:19 +0100
                                    Re: AVCALL (from the 'ffcall' package) really is the answer! (Was: Generic function-calling code) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-23 10:37 -0700
                                  Re: AVCALL (from the 'ffcall' package) really is the answer! (Was: Generic function-calling code) Bartc <bc@freeuk.com> - 2015-07-23 23:29 +0100
                          Re: AVCALL (from the 'ffcall' package) really is the answer! (Was: Generic function-calling code) gazelle@shell.xmission.com (Kenny McCormack) - 2015-07-23 16:18 +0000
                Re: Generic function-calling code Richard Damon <Richard@Damon-Family.org> - 2015-07-24 01:21 -0400
            Re: Generic function-calling code Bartc <bc@freeuk.com> - 2015-07-22 13:23 +0100
              Re: Generic function-calling code Ian Collins <ian-news@hotmail.com> - 2015-07-23 07:44 +1200
                Re: Generic function-calling code Bartc <bc@freeuk.com> - 2015-07-22 22:24 +0100
        Re: Generic function-calling code luser droog <luser.droog@gmail.com> - 2015-07-22 10:29 -0700
        Re: Generic function-calling code luser droog <luser.droog@gmail.com> - 2015-07-22 10:32 -0700
      Re: Generic function-calling code Keith Thompson <kst-u@mib.org> - 2015-07-21 15:38 -0700
    Generic function-calling code "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-21 17:26 -0700
    Re: Generic function-calling code Ian Collins <ian-news@hotmail.com> - 2015-07-22 14:27 +1200
    Re: Generic function-calling code gazelle@shell.xmission.com (Kenny McCormack) - 2015-07-22 02:39 +0000
    Re: Generic function-calling code Lőrinczy Zsigmond <zsiga@nospam.for.me> - 2015-07-23 09:28 +0200
    Re: Generic function-calling code "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-23 19:04 -0700
    Re: Generic function-calling code owen.jacobson@grimoire.ca - 2015-07-24 08:32 -0700
      Re: Generic function-calling code gazelle@shell.xmission.com (Kenny McCormack) - 2015-07-24 18:48 +0000
      Re: Generic function-calling code Bartc <bc@freeuk.com> - 2015-07-24 20:22 +0100
        Re: Generic function-calling code Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-25 03:03 -0700
    Re: Generic function-calling code "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-25 13:32 -0700
      Re: Generic function-calling code Bartc <bc@freeuk.com> - 2015-07-25 23:28 +0100
        Re: Generic function-calling code "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-26 06:18 -0700
          Re: Generic function-calling code gazelle@shell.xmission.com (Kenny McCormack) - 2015-07-26 13:39 +0000
            Re: Generic function-calling code "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-26 07:33 -0700
              Re: Generic function-calling code Bartc <bc@freeuk.com> - 2015-07-26 16:21 +0100
                Re: Generic function-calling code "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-26 08:39 -0700
    Re: Generic function-calling code "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-26 05:37 -0700
      Re: Generic function-calling code Bartc <bc@freeuk.com> - 2015-08-26 14:36 +0100
        Re: Generic function-calling code "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-26 06:46 -0700
          Re: Generic function-calling code Bartc <bc@freeuk.com> - 2015-08-26 16:11 +0100
            Re: Generic function-calling code "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-26 08:20 -0700
    Re: Generic function-calling code "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-27 16:53 -0700
      Re: Generic function-calling code Bartc <bc@freeuk.com> - 2015-08-28 01:03 +0100
        Re: Generic function-calling code "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-30 05:36 -0700
          Re: Generic function-calling code "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-30 06:35 -0700
            Re: Generic function-calling code "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-30 06:43 -0700
            Re: Generic function-calling code Bartc <bc@freeuk.com> - 2015-08-30 15:10 +0100
              Re: Generic function-calling code "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-30 08:59 -0700
                Re: Generic function-calling code Geoff <geoff@invalid.invalid> - 2015-08-30 10:54 -0700
                  Re: Generic function-calling code "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-30 10:57 -0700
                    Re: Generic function-calling code Geoff <geoff@invalid.invalid> - 2015-08-30 11:13 -0700
                      Re: Generic function-calling code "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-30 11:16 -0700
                        Re: Generic function-calling code Geoff <geoff@invalid.invalid> - 2015-08-30 11:59 -0700
                          Re: Generic function-calling code "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-30 12:15 -0700
                            Re: Generic function-calling code Geoff <geoff@invalid.invalid> - 2015-08-30 12:57 -0700
                              Re: Generic function-calling code "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-30 13:40 -0700
                    Re: Generic function-calling code Geoff <geoff@invalid.invalid> - 2015-08-30 11:15 -0700
                      Re: Generic function-calling code "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-30 11:28 -0700
                        Re: Generic function-calling code Bartc <bc@freeuk.com> - 2015-08-30 20:11 +0100
                          Re: Generic function-calling code David Brown <david.brown@hesbynett.no> - 2015-08-30 22:28 +0200
                          Re: Generic function-calling code "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-01 01:13 -0700
                            Re: Generic function-calling code Philip Lantz <prl@canterey.us> - 2015-09-03 00:40 -0700
                              Re: Generic function-calling code "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-03 01:26 -0700
                                Re: Generic function-calling code David Brown <david.brown@hesbynett.no> - 2015-09-03 11:34 +0200
                                  Re: Generic function-calling code "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-03 03:15 -0700
                                    Re: Generic function-calling code "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-03 03:21 -0700
                                    Re: Generic function-calling code David Brown <david.brown@hesbynett.no> - 2015-09-03 13:07 +0200
                                      Re: Generic function-calling code "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-03 04:30 -0700
                                        Re: Generic function-calling code David Brown <david.brown@hesbynett.no> - 2015-09-03 13:39 +0200
                                          Re: Generic function-calling code Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-03 07:20 -0700
                                            Re: Generic function-calling code David Brown <david.brown@hesbynett.no> - 2015-09-03 20:25 +0200
                                              Re: Generic function-calling code "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-03 11:30 -0700
                                                Re: Generic function-calling code "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-03 11:44 -0700
                                  Re: Generic function-calling code Bartc <bc@freeuk.com> - 2015-09-03 11:21 +0100
                                    Re: Generic function-calling code David Brown <david.brown@hesbynett.no> - 2015-09-03 13:19 +0200
                                      Re: Generic function-calling code "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-03 04:51 -0700
                                        Re: Generic function-calling code David Brown <david.brown@hesbynett.no> - 2015-09-03 14:31 +0200
                                          Re: Generic function-calling code "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-03 05:57 -0700
                                      Re: Generic function-calling code "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-03 04:56 -0700
                                        Re: Generic function-calling code David Brown <david.brown@hesbynett.no> - 2015-09-03 14:53 +0200
                                          Re: Generic function-calling code "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-03 06:08 -0700
                                            Re: Generic function-calling code David Brown <david.brown@hesbynett.no> - 2015-09-03 15:18 +0200
                                              Re: Generic function-calling code "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-03 06:30 -0700
                                                Re: Generic function-calling code Martin Shobe <martin.shobe@yahoo.com> - 2015-09-03 10:09 -0500
                                                  Re: Generic function-calling code "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-03 08:59 -0700
                                                Re: Generic function-calling code Philip Lantz <prl@canterey.us> - 2015-09-03 08:37 -0700
                                        Re: Generic function-calling code Philip Lantz <prl@canterey.us> - 2015-09-03 08:31 -0700
                                          Re: Generic function-calling code "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-03 09:07 -0700
                                            Re: Generic function-calling code David Brown <david.brown@hesbynett.no> - 2015-09-03 20:42 +0200
                                              Re: Generic function-calling code "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-03 11:49 -0700
                                    Re: Generic function-calling code Philip Lantz <prl@canterey.us> - 2015-09-03 08:25 -0700
                                      Re: Generic function-calling code Bartc <bc@freeuk.com> - 2015-09-03 16:46 +0100
                                      Re: Generic function-calling code "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-03 09:02 -0700
                                Re: Generic function-calling code glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-09-04 04:04 +0000
                          Re: Generic function-calling code Philip Lantz <prl@canterey.us> - 2015-09-03 00:36 -0700
                            Re: Generic function-calling code Bartc <bc@freeuk.com> - 2015-09-03 16:29 +0100
                              Re: Generic function-calling code Philip Lantz <prl@canterey.us> - 2015-09-03 08:45 -0700
                              Re: Generic function-calling code David Brown <david.brown@hesbynett.no> - 2015-09-03 22:33 +0200

Page 4 of 8 — ← Prev page 1 2 3 [4] 5 6 7 8  Next page →

#66251 — Re: AVCALL (from the 'ffcall' package) really is the answer! (Was: Generic function-calling code)

On 23/07/2015 14:26, Rick C. Hodgin wrote:
> On Thursday, July 23, 2015 at 8:15:08 AM UTC-4, Bart wrote:
>> The problem is not in getting it done at all, but doing it in a nice,
>> tidy manner which can also be expressed in ordinary C, and can form part
>> of a simple C distribution of the project.
>
> I would like to suggest something to you.  Feel free to take it or leave
> it.  It's sometimes easier to do this, where each call_dll.c is a little
> bit of custom assembly code for the target platform:

A couple of problems here: how will the assembly code be compiled? Each 
C compiler, if it supports assembly at all, will do it differently. And 
I if concentrate on gcc, that uses an interface I can't understand. (I 
would end up having a hacked .s file instead; I think gcc can compile .s 
files.

> ...rather than writing a C-only solution which can be unwieldly in
> maintenance and understanding for follow-on developers.

I don't normally think that far ahead. The first obstacle is, I have 
this program in a non-standard language; how can /you/ compile, build 
and run it? (Assuming that binaries are not acceptable.) Creating 
beautiful, elegant C code would be a different project.

(At the moment, much of my C code would be auto-generated, so a lot of 
information is lost: 'a' becomes 97; MAXPARAM becomes 42; etc.)

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#66252 — Re: AVCALL (from the 'ffcall' package) really is the answer! (Was: Generic function-calling code)

On Thursday, July 23, 2015 at 10:00:53 AM UTC-4, Bart wrote:
> On 23/07/2015 14:26, Rick C. Hodgin wrote:
> > On Thursday, July 23, 2015 at 8:15:08 AM UTC-4, Bart wrote:
> >> The problem is not in getting it done at all, but doing it in a nice,
> >> tidy manner which can also be expressed in ordinary C, and can form part
> >> of a simple C distribution of the project.
> >
> > I would like to suggest something to you.  Feel free to take it or leave
> > it.  It's sometimes easier to do this, where each call_dll.c is a little
> > bit of custom assembly code for the target platform:
> 
> A couple of problems here: how will the assembly code be compiled? Each 
> C compiler, if it supports assembly at all, will do it differently. And 
> I if concentrate on gcc, that uses an interface I can't understand. (I 
> would end up having a hacked .s file instead; I think gcc can compile .s 
> files.

Quite correct.  I had assumed MSVC for Windows, and GCC for Linux.

GCC can use the -masm=Intel switch to make it a little easier.  And
I agree that the assembly parameter syntax for GCC is horrid.  It is
confusing and, by all things I understand, completely unnecessary
because the encoding of each instruction conveys fully the intent and
impact of the operation on the variables (read, write, reference),
as well as the machine state.

It is a nice extension when you want to optimize assembly.  But I
then am inundated by the question which leaps to my mind:  Why
would you want a compiler to optimize your inline assembly?  There's
probably a reason you're using assembly in the first place.

> > ...rather than writing a C-only solution which can be unwieldly in
> > maintenance and understanding for follow-on developers.
> 
> I don't normally think that far ahead. The first obstacle is, I have 
> this program in a non-standard language; how can /you/ compile, build 
> and run it? (Assuming that binaries are not acceptable.) Creating 
> beautiful, elegant C code would be a different project.
> 
> (At the moment, much of my C code would be auto-generated, so a lot of 
> information is lost: 'a' becomes 97; MAXPARAM becomes 42; etc.)

Understood.  As you are doing it, sounds good (using a generator to
write the C definitions for you so there's no a lot of code involved
in maintaining "a lot of code" as per its generated output of
thousands?? of lines).

Best regards,
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#66259 — Re: AVCALL (from the 'ffcall' package) really is the answer! (Was: Generic function-calling code)

On 23/07/2015 13:14, Bartc wrote:
> On 23/07/2015 12:44, Rick C. Hodgin wrote:
>> On Wednesday, July 22, 2015 at 6:47:58 PM UTC-4, Bart wrote:
>>> I'm thinking that maybe, generating a couple of thousand lines of C to
>>> handle all the call combinations needed would be simpler overall. And it
>>> would be pure C, with nothing special to do except just compile. While a
>>> dedicated ASM solution might be 100 lines of code.
>>
>> I'm working on this in my spare time using the x86 algorithm which uses
>> straight-forward assembly to prepare the stack, dispatch, and retrieve
>> the return value.  I'll get the 32-bit version completed, then the
>> 64-bit after.
>>
>> I'll try to get it completed this weekend if you would like to use it.
>> I plan right now to work on it this evening and possibly complete it,
>> but it will depend on life things so I'll add the "Lord willing" tag.
>
> Thanks, but I already know several ways of doing this without writing
> thousands of lines, or using a large, unwieldy and elusive third party
> library which probably doesn't work for Win64 anyway.

I have an idea for a C-only solution but it's a little dodgy.

* Assume first all arguments are ints or pointers (passed in GPRs) (and 
that this is for Windows)

* If there are any doubles within the first 4 arguments, then first do a 
call to a dummy function that takes 4 doubles, and returns no value. 
This ensures that any float arguments are loaded into the correct XMM 
register.

(It doesn't matter too much if there are fewer than 4 arguments or some 
are ints, but arranging multiple dummy functions isn't much trouble. 
However, I vaguely remember that on 64-bit Linux, register assignments 
are trickier, so the right pattern of dummy call might be needed.)

* Now do the call proper. Any floats will be reloaded (as int bit 
patterns) to GPRs, but that doesn't matter; hopefully the copies 
previously loaded to XMM are still there.

This depends on the C compiler going along with it, and not optimising 
out essential bits of code, or overwriting XMM registers for reasons of 
its own. That might mean turning off optimisation and/or using 
'volatile' everywhere.

(A brief test on calling 'sqrt' inside msvcrt.dll seemed to work with 
this method. I was however using my compiler for the main part, and it 
does what it's told. But the dummy function was called in real C as 
otherwise my compiler would use a non-standard call convention.

With the dummy call, it worked (sqrt(2.0) was 1.414... as expected). 
Without it, it didn't.)

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#66260 — Re: AVCALL (from the 'ffcall' package) really is the answer! (Was: Generic function-calling code)

On Thursday, July 23, 2015 at 1:02:39 PM UTC-4, Bart wrote:
> On 23/07/2015 13:14, Bartc wrote:
> > On 23/07/2015 12:44, Rick C. Hodgin wrote:
> >> On Wednesday, July 22, 2015 at 6:47:58 PM UTC-4, Bart wrote:
> >>> I'm thinking that maybe, generating a couple of thousand lines of C to
> >>> handle all the call combinations needed would be simpler overall. And it
> >>> would be pure C, with nothing special to do except just compile. While a
> >>> dedicated ASM solution might be 100 lines of code.
> >>
> >> I'm working on this in my spare time using the x86 algorithm which uses
> >> straight-forward assembly to prepare the stack, dispatch, and retrieve
> >> the return value.  I'll get the 32-bit version completed, then the
> >> 64-bit after.
> >>
> >> I'll try to get it completed this weekend if you would like to use it.
> >> I plan right now to work on it this evening and possibly complete it,
> >> but it will depend on life things so I'll add the "Lord willing" tag.
> >
> > Thanks, but I already know several ways of doing this without writing
> > thousands of lines, or using a large, unwieldy and elusive third party
> > library which probably doesn't work for Win64 anyway.
> 
> I have an idea for a C-only solution but it's a little dodgy.
> 
> * Assume first all arguments are ints or pointers (passed in GPRs) (and 
> that this is for Windows)
> 
> * If there are any doubles within the first 4 arguments, then first do a 
> call to a dummy function that takes 4 doubles, and returns no value. 
> This ensures that any float arguments are loaded into the correct XMM 
> register.
> 
> (It doesn't matter too much if there are fewer than 4 arguments or some 
> are ints, but arranging multiple dummy functions isn't much trouble. 
> However, I vaguely remember that on 64-bit Linux, register assignments 
> are trickier, so the right pattern of dummy call might be needed.)
> 
> * Now do the call proper. Any floats will be reloaded (as int bit 
> patterns) to GPRs, but that doesn't matter; hopefully the copies 
> previously loaded to XMM are still there.
> 
> This depends on the C compiler going along with it, and not optimising 
> out essential bits of code, or overwriting XMM registers for reasons of 
> its own. That might mean turning off optimisation and/or using 
> 'volatile' everywhere.
> 
> (A brief test on calling 'sqrt' inside msvcrt.dll seemed to work with 
> this method. I was however using my compiler for the main part, and it 
> does what it's told. But the dummy function was called in real C as 
> otherwise my compiler would use a non-standard call convention.
> 
> With the dummy call, it worked (sqrt(2.0) was 1.414... as expected). 
> Without it, it didn't.)
> 
> -- 
> Bartc

My biggest concern with this solution would be that an optimizing
compiler could easily dismiss that dummy call, or it could change
the calling parameters because it realizes nothing is being done
with those values, so it removes them from the call in the first
place.

Best regards,
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#66261 — Re: AVCALL (from the 'ffcall' package) really is the answer! (Was: Generic function-calling code)

On 23/07/2015 18:05, Rick C. Hodgin wrote:
> On Thursday, July 23, 2015 at 1:02:39 PM UTC-4, Bart wrote:

>> I have an idea for a C-only solution but it's a little dodgy.
>>
>> * Assume first all arguments are ints or pointers (passed in GPRs) (and
>> that this is for Windows)
>>
>> * If there are any doubles within the first 4 arguments, then first do a
>> call to a dummy function that takes 4 doubles, and returns no value.
>> This ensures that any float arguments are loaded into the correct XMM
>> register.

> My biggest concern with this solution would be that an optimizing
> compiler could easily dismiss that dummy call, or it could change
> the calling parameters because it realizes nothing is being done
> with those values, so it removes them from the call in the first
> place.

That was a quick reply!

Yes, gcc especially is likely to have a mind of its own. But it's better 
behaved with -O0 and 'volatile' sprinkled around. It does mean isolating 
this bit of code and having restrictions on how it's compiled; not so good.

I can't do a fuller test at the minute: the problems only come up with 
x64, for which I use my own language and compiler generating native code 
with small parts in real C. For x86, I generate C code, but x86 doesn't 
have the same problems!

(There is a problem targeting C code for 64-bit, as C compilers will use 
64-bit pointers and my application assumes 32-bit ones. So that has to 
be solved first. But also, any solution I use in my language that works 
for x64, will still need to compile unchanged when targetted at C/32-bit 
- and still work.)

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#66262 — Re: AVCALL (from the 'ffcall' package) really is the answer! (Was: Generic function-calling code)

On Thursday, July 23, 2015 at 1:19:51 PM UTC-4, Bart wrote:
> On 23/07/2015 18:05, Rick C. Hodgin wrote:
> > On Thursday, July 23, 2015 at 1:02:39 PM UTC-4, Bart wrote:
> 
> >> I have an idea for a C-only solution but it's a little dodgy.
> >>
> >> * Assume first all arguments are ints or pointers (passed in GPRs) (and
> >> that this is for Windows)
> >>
> >> * If there are any doubles within the first 4 arguments, then first do a
> >> call to a dummy function that takes 4 doubles, and returns no value.
> >> This ensures that any float arguments are loaded into the correct XMM
> >> register.
> 
> > My biggest concern with this solution would be that an optimizing
> > compiler could easily dismiss that dummy call, or it could change
> > the calling parameters because it realizes nothing is being done
> > with those values, so it removes them from the call in the first
> > place.
> 
> That was a quick reply!
> 
> Yes, gcc especially is likely to have a mind of its own. But it's better 
> behaved with -O0 and 'volatile' sprinkled around. It does mean isolating 
> this bit of code and having restrictions on how it's compiled; not so good.
> 
> I can't do a fuller test at the minute: the problems only come up with 
> x64, for which I use my own language and compiler generating native code 
> with small parts in real C. For x86, I generate C code, but x86 doesn't 
> have the same problems!
> 
> (There is a problem targeting C code for 64-bit, as C compilers will use 
> 64-bit pointers and my application assumes 32-bit ones. So that has to 
> be solved first. But also, any solution I use in my language that works 
> for x64, will still need to compile unchanged when targetted at C/32-bit 
> - and still work.)
> 
> -- 
> Bartc

I would create a tiny stand-alone C program with an algorithm which
iterates through all possible combinations you desire to support, and
then generate a valid .c source file using that information, and
then simply reference it in your project.

That way you really are only maintaining a few lines of source code
to maintain many thousands of lines of source code.  And because it
is all controlled from one source, changes are easy.

Best regards,
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#66269 — Re: AVCALL (from the 'ffcall' package) really is the answer! (Was: Generic function-calling code)

On 23/07/2015 18:05, Rick C. Hodgin wrote:
> On Thursday, July 23, 2015 at 1:02:39 PM UTC-4, Bart wrote:

>> I have an idea for a C-only solution but it's a little dodgy.

> My biggest concern with this solution would be that an optimizing
> compiler could easily dismiss that dummy call, or it could change
> the calling parameters because it realizes nothing is being done
> with those values, so it removes them from the call in the first
> place.

I put together the following simple test. It should be compiled under 
Windows and for 64-bits.

Without the call to dummy_fn(), it doesn't work (prints 0.0).

With the call to dummy_fn(), it works on 4 64-bit C compilers without 
optimisation (prints 0.98 or so).

With optimisation, it works on PellesC, lccwin (and TCC), but as 
expected, fails with gcc. Although the fix was easy: to put the dummy_fn 
function in another module (make it external); then it can't optimise it 
out (unless at some point it does link-time optimisation, then I'll have 
to think of something else).

(I haven't added any code that deals with a variable length argument 
list or that examines the parameter types looking for floating point 
arguments; that's just routine. And actually some of that will be taken 
care of deeper within the interpreter.)

#include <stdio.h>
#include <stdlib.h>
#include <stdint.h>

#include <windows.h>

typedef int64_t i64;
typedef double r64;

typedef union {
	i64 a;
	r64 x;
} T;

void dummy_fn(r64 a, r64 b, r64 c, r64 d){}

double callfn_r64(void* fnptr, int nparams, T* params) {
   dummy_fn(params[0].x, params[1].x, params[2].x, params[3].x);
   return ((r64 (*)(i64,i64))fnptr)(params[0].a, params[1].a);
}

int main(void) {
   HMODULE hlib=LoadLibrary("msvcrt.dll");
   void* fnptr;
   double result;
   T arglist[20]={0};

   if (!hlib) {puts("Can't load lib"); exit(0);}

   fnptr=GetProcAddress(hlib,"atan2");

   if (!fnptr) {puts("Can't load fn"); exit(0);}

   arglist[0].x=3.0;           // set up atan2(3.0,2.0)
   arglist[1].x=2.0;

   puts("Calling function:");

   result=callfn_r64(fnptr, 2, arglist);

   printf("Result = %f\n",result);
}


-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#66257 — Re: AVCALL (from the 'ffcall' package) really is the answer! (Was: Generic function-calling code)

In article <mop6fr$j1c$1@dont-email.me>, Bartc  <bc@freeuk.com> wrote:
...
>I'm thinking that maybe, generating a couple of thousand lines of C to
>handle all the call combinations needed would be simpler overall. And it
>would be pure C, with nothing special to do except just compile. While a
>dedicated ASM solution might be 100 lines of code.

Those who do not understand AVCALL are doomed to re-invent it.

Badly.

-- 
To most Christians, the Bible is like a software license. Nobody 
actually reads it. They just scroll to the bottom and click "I agree."

	- author unknown -

[toc] | [prev] | [next] | [standalone]

#66274

On 7/22/15 6:50 AM, Bartc wrote:
> On 22/07/2015 10:37, Rick C. Hodgin wrote:
>> Bart,
>>
>> Why are you passing parameters at all? Pass
>> pointers to structs you've built which convey
>> all of that information which you've manually
>> built from what you know at runtime.  Why
>> does it have to go through parameters?
>>
>> If it's a call into C from another language then
>> use three functions:
>>
>>      int mydllfunction_getHandle(void);
>>      int mydllfunction_accumulateParam(int handle, int type, void*
>> value);
>>      int mydllfunction_dispatch(int handle);
>>
>> You could use an optional 4th to release the
>> handle, but given the nature, the dispatch()
>> function could do it.
>
> It's difficult to put across the problem although luser seemed to grasp
> it instantly.
>
> But suppose you create an interpreter for a language which can access
> external DLL functions. You write the interpreter in C, and build it in
> July 2014.
>
> A year later in July 2015, someone writes a program which wants to
> access a DLL function with a dozen assorted parameters (eg.
> 'CreateWindowEx' from library 'user32.dll').
>
> Now, the interpreter can't anticipate which of tens of thousands of
> possible functions in hundreds of different libraries could be called;
> it has to work with any possibility.
>
> So how will it work? It can get the function address, it knows the
> number and types of the parameters, it knows the return value, and it
> knows the arguments the user's program will supply. But the call must
> somehow be accomplished inside the interpreter.
>
> It can be done by dropping into assembly or using all sorts of dodgy
> techniques (generating and compiling C at runtime for example). But I'm
> interested in a solution in normal code.
>
> (I'm looking at Kenny's link to FFCALL, which looks as though it
> understands the issues involved, but it looks very complicated, and it
> might not be fully updated for x64 (possibly it has come across the same
> problem I have!).)
>

Standard C doesn't provide a method to call a function with run time 
determined parameters types. If the function you are calling isn't setup 
to help (using things like unions for the parameters), then your only 
choice is to create every possible parameter pattern and select between 
them. The alternative is to build an adapter in something else (like 
assembly) that can do this.

If you are willing to go implementation specific, you can compress the 
space quite a bit by doing things that are fairly safe like assume all 
pointers are compatible, and can be passed just like some integral type 
like intptr_t (and perhaps we even know what type that is). We may even 
know that after some number of parameters, all parameters can be passed 
as an equivalent number of some base type (likely unsigned int) in a 
specific order. This says that, at least for a somewhat limited number 
of parameters, it might be in the bounds of possibility to actually 
write such a thing (but it won't be pretty).

Note that the reverse is also the same problem. You can't within the 
standard write a function that can be called with an arbitrary 
prototype. We can come close with var-args, but the essence of var-args 
is that the caller KNOWS it is using a generic interface and follows 
certain rules because of that. You can't create a function that in one 
place is called as if it was declared "int f(int);" and in another as if 
it was declared "int f(double);". And var-args won't even help you here, 
as they require that the type of the first parameter be fixed. On some 
machines you may be able to get away with using var-args to receive a 
call not with a var-args prototype, but you are in the land of undefined 
behavior (perhaps made implementation defined by the implementation).

[toc] | [prev] | [next] | [standalone]

#66152

On 22/07/2015 06:25, BGB wrote:
> On 7/21/2015 6:56 PM, Bartc wrote:
>> On 21/07/2015 22:45, luser droog wrote:

>>> My only thought is tricksy macros. But I haven't imagined yet how to
>>> organize them.
>>
>> Ah yes. But if you're planning some that will generate 2**16 different
>> call sequences, then I'll have to politely decline!
>>
>
> any specific reason beyond this?...

Well, it would just be crazy, that's one good reason! Doesn't matter if 
technically it might work.

The 30K lines (ignoring the framework needed to be able to select to the 
correct line then jump back out) would dwarf the 20K lines of the rest 
of the program, and most of the 30K lines would be quite dense too.

(Also, the modules of the project are not written directly in C, except 
for one. The rest can optionally be translated to C rather than native 
code. So a solution with macros would need to be another pure C module, 
not quite as satisfactory as using the main source language.)

But it seems now there won't be that many combinations (I don't need to 
distinguish between float/non-float beyond the 4th or 6th parameter.) 
However the number might still be uncomfortably large.

-- 
bartc

[toc] | [prev] | [next] | [standalone]

#66184

Bartc wrote:
> On 22/07/2015 06:25, BGB wrote:
>> On 7/21/2015 6:56 PM, Bartc wrote:
>>> On 21/07/2015 22:45, luser droog wrote:
>
>>>> My only thought is tricksy macros. But I haven't imagined yet how to
>>>> organize them.
>>>
>>> Ah yes. But if you're planning some that will generate 2**16 different
>>> call sequences, then I'll have to politely decline!
>>>
>>
>> any specific reason beyond this?...
>
> Well, it would just be crazy, that's one good reason! Doesn't matter if
> technically it might work.
>
> The 30K lines (ignoring the framework needed to be able to select to the
> correct line then jump back out) would dwarf the 20K lines of the rest
> of the program, and most of the 30K lines would be quite dense too.
>
> (Also, the modules of the project are not written directly in C, except
> for one. The rest can optionally be translated to C rather than native
> code. So a solution with macros would need to be another pure C module,
> not quite as satisfactory as using the main source language.)
>
> But it seems now there won't be that many combinations (I don't need to
> distinguish between float/non-float beyond the 4th or 6th parameter.)
> However the number might still be uncomfortably large.
>
This little snippet (extracted from an RPC library) of C++ will probably 
do what you want to do:

#include <dlfcn.h>
#include <stdio.h>

void
notFound( ... )
{
   puts( "not found" );
}

void*
lookup( const char* functionName )
{
   void* fn = dlsym( RTLD_DEFAULT, functionName );

   return fn ? fn : (void*)&notFound;
}

template <typename R>
R call( const char* functionName )
{
   typedef R(*Fn)();
   return reinterpret_cast<Fn>(lookup(functionName))();
}

template <typename R, typename P0>
R call( const char* functionName, P0 p0 )
{
   typedef R(*Fn)(P0);
   return reinterpret_cast<Fn>(lookup(functionName))(p0);
}

template <typename R, typename P0, typename P1>
R call( const char* functionName, P0 p0, P1 p1 )
{
   typedef R(*Fn)(P0,P1);
   return reinterpret_cast<Fn>(lookup(functionName))(p0,p1);
}

template <typename R, typename P0, typename P1, typename P2>
R call( const char* functionName, P0 p0, P1 p1, P2 p2 )
{
   typedef R(*Fn)(P0,P1,P2);
   return reinterpret_cast<Fn>(lookup(functionName))(p0,p1,p2);
}

template <typename R, typename P0, typename P1, typename P2, typename P3>
R call( const char* functionName, P0 p0, P1 p1, P2 p2, P3 p3 )
{
   typedef R(*Fn)(P0,P1,P2,P3);
   return reinterpret_cast<Fn>(lookup(functionName))(p0,p1,p2,p3);
}

int
main( int argc, char** argv )
{
   call<int>( "fputs", "hello ", stdout );

   call<int>( "puts", "there!" );

   FILE* fp = call<FILE*>( "fopen", "/tmp/xx", "wb" );

   if( fp )
   {
     call<size_t>( "fwrite", "A test", sizeof("A Test"), 1, fp );

     call<int>( "fclose", fp );
   }

   call<int>( "bollocks", 21 );
}


-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#66204

On 22/07/2015 20:44, Ian Collins wrote:
> Bartc wrote:

>> But it seems now there won't be that many combinations (I don't need to
>> distinguish between float/non-float beyond the 4th or 6th parameter.)
>> However the number might still be uncomfortably large.
>>
> This little snippet (extracted from an RPC library) of C++ will probably
> do what you want to do:

>    call<int>( "fputs", "hello ", stdout );

That's interesting, but it looks like the structure of the call needs to 
be known at compile-time.

What it needs is more like this:

void* fnptr;            // The address of the function
int nparams;            // the number of arguments provided
int paramtypes[20];     // each element is 'F','I','P' or 'V'
T arguments[20];        // The arguments provided
T result;

fnptr, nparams, paramtypes and arguments are not known until runtime. 
paramtypes[0] can be the return type; [1] onwards are the actual 
parameter types.

T is some special type that can represent any int, float, or pointer 
type (it's going to be some 64-bit value, probably a union).

A function such as:

   callfn (fnptr, nparams, paramtypes, arguments, &result);

is needed. Or, since there are few return types, specialised ones will do:

  double result;
  result = callfn_double (fnptr, nparams, paramtypes, arguments);

The AVCALL library has got the right idea. There, the arguments are 
added to a list one by one (it could be used to implement the callfn () 
above). But I'm not sure how it works; if it uses assembly, then it's 
cheating.

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#66171

On Tuesday, July 21, 2015 at 4:46:16 PM UTC-5, luser droog wrote:
> On Tuesday, July 21, 2015 at 4:05:12 PM UTC-5, jacobnavia wrote:
> 
> 
> > 
> > void *fn();
> > 
> > This prototype specifies that fn is a function that receives an 
> > underterminate number of arguments. You can pass to your function as 
> > many args as you want.
> > 
> > /tmp $ cat tfn.c
> > void *fn()
> > { return 0; }
> > 
> > int main(void)
> > {
> > 	fn(1,67.87,9756.9L,"a");
> > 	fn(2,"foo",678);
> > }
> > /tmp $ gcc -std=c99 tfn.c
> > /tmp $
> > 
> > But maybe you know this and I haven't understood what you want to do
> 
> He's doing this in the context of an interpreter, I think.
> So it needs to be a function that can receive the fn pointer 
> and a struct or array of arguments and do an Apply, calling
> any function (with appropriate signature) upon a stored set
> of actual parameters.
> 
> My only thought is tricksy macros. But I haven't imagined yet how to
> organize them.

Here's one idea for a similar but smaller problem.
http://stackoverflow.com/questions/22253686/c-void-used-as-polymorphic-function-pointer/22885676#22885676

And an even simpler situation where all the arguments
are of the same union type.
http://stackoverflow.com/questions/14867923/c-pass-variable-number-of-command-line-arguments-into-method-with-variable-num/14868282#14868282

[toc] | [prev] | [next] | [standalone]

#66172

On Tuesday, July 21, 2015 at 4:46:16 PM UTC-5, luser droog wrote:
> On Tuesday, July 21, 2015 at 4:05:12 PM UTC-5, jacobnavia wrote:
> 
> 
> > 
> > void *fn();
> > 
> > This prototype specifies that fn is a function that receives an 
> > underterminate number of arguments. You can pass to your function as 
> > many args as you want.
> > 
> > /tmp $ cat tfn.c
> > void *fn()
> > { return 0; }
> > 
> > int main(void)
> > {
> > 	fn(1,67.87,9756.9L,"a");
> > 	fn(2,"foo",678);
> > }
> > /tmp $ gcc -std=c99 tfn.c
> > /tmp $
> > 
> > But maybe you know this and I haven't understood what you want to do
> 
> He's doing this in the context of an interpreter, I think.
> So it needs to be a function that can receive the fn pointer 
> and a struct or array of arguments and do an Apply, calling
> any function (with appropriate signature) upon a stored set
> of actual parameters.
> 
> My only thought is tricksy macros. But I haven't imagined yet how to
> organize them.

Here's one idea for a similar but smaller problem.
http://stackoverflow.com/questions/22253686/c-void-used-as-polymorphic-function-pointer/22885676#22885676

And an even simpler situation where all the arguments
are of the same union type.
http://stackoverflow.com/questions/14867923/c-pass-variable-number-of-command-line-arguments-into-method-with-variable-num/14868282#14868282

[toc] | [prev] | [next] | [standalone]

#66130

jacobnavia <jacob@jacob.remcomp.fr> writes:
[...]
> void *fn();
>
> This prototype specifies that fn is a function that receives an 
> underterminate number of arguments. You can pass to your function as 
> many args as you want.

Terminology quibble: That's a declaration, but it's specifically *not* a
prototype.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#66133

Bartc wrote:
> retval = ((<cast>)fnptr) (params[0], params[1], params[2]);

The DLL function would have to be aware of the
multiple parameters, so there must be a known
variadic protocol.

Why not something like this then:

    union {
        int (*fnptr3) (void* p1, void* p2, void* p3);
        int (*fnptrN) (...);
    };

Or the fixed technique, as aound line 200 in the
struct SEvents:

    https://github.com/RickCHodgin/libsf/blob/master/source/vjr/source/vjr_structs.h 

Best regards,
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#66137

Bartc wrote:
> One problem I posted about a couple of years ago was along these lines:
>
> * You have a pointer to a function (which happens to be to an external,
> runtime-loaded dynamic library function, but I'm not sure it matters)
>
> * You know, at runtime, the number of parameters N, and the types of
> each parameter, and the return type (encoded as integers according to
> some scheme).
>
> * There is an array of arguments to be passed (consider each element to
> be a union of possible integer, float and pointer types).
>
> The problem I had then was you couldn't write, in C, a function call
> with a variable number of arguments (to a function taking a fixed
> number). It is only possible to do this:
>
>      retval = ((<cast>)fnptr) (params[0], params[1], params[2]);

If you are will to give it a try, doing this is a lot easier in C++...

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#66138

In article <mom9hn$fm3$1@dont-email.me>, Bartc  <bc@freeuk.com> wrote:
>One problem I posted about a couple of years ago was along these lines:
>
>* You have a pointer to a function (which happens to be to an external, 
>runtime-loaded dynamic library function, but I'm not sure it matters)
>
>* You know, at runtime, the number of parameters N, and the types of 
>each parameter, and the return type (encoded as integers according to 
>some scheme).

You are looking for "avcall".  Google for "ffcall".

I use it all the time.  It is very nice.

-- 

First of all, I do not appreciate your playing stupid here at all.

	- Thomas 'PointedEars' Lahn -

[toc] | [prev] | [next] | [standalone]

#66232

Very good question;
there are macros to precess incoming variable arguments,
but there's no platform-independent way to _create_ variable arguments.

When I was young, I thought va_list is something like intptr_t *,
but x86-64 clearly proved me wrong.

Of course, if you write both components (caller and called),
you might agree with yourself using intptr_t * as variable-parameters:

intptr_t mypars mypars[32], *pp= mypars;
*pp++= (intptr_t)"Hello, %s here is a double: %g";
*pp++= (intptr_t)"Jack";

/* the next part isn't meant for the weak in heart */
*(double *)pp = 3.1415926;
pp += (sizeof double + sizeof intptr_t - 1) / (sizeof intptr_t);

my_special_printf (mypars);

[toc] | [prev] | [next] | [standalone]

#66272

Bart,

I began working on this tonight, but don't have it completed.  I'll
try to complete it this weekend.

It is source code to generate all of the permutations required for
variable parameters for a variable set of parameter types.

Right now it's setup to handle void*, float, and double as separate
and distinct input parameter types, as well as the return variable
type.

    https://github.com/RickCHodgin/libsf/tree/master/source/unsorted/gencode

I'm going to add a structure at the end which allows direct dispatch
to the leading parameter grouping, and then based on the parameter
count it will dispatch to the appropriate handler, and an include
file which uses the same name with the .h extension which has all
of the function prototype declarations, and I'll probably migrate
the structures to the header as well.

I think you can see where I'm going withit, but if not you should
be able to see after it's generating source code.

Best regards,
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

Page 4 of 8 — ← Prev page 1 2 3 [4] 5 6 7 8  Next page →

Back to top | Article view | comp.lang.c

csiph-web