AqBanking

Without that library added on Linux I get:

/bin/sh ../../libtool --tag=CC --mode=link gcc -g -O2 -Wall -Wdeclaration-after-statement -Wall -Wdeclaration-after-statement -Wall -Wdeclaration-after-statement -o gct-tool activatekey.o changepin.o create.o genkey.o showkey.o showuser.o update.o setsignseq.o setkey.o hashtree.o checktree.o showpasswords.o main.o ../../src/libgwenhywfar.la -lssl -lcrypto
libtool: link: gcc -g -O2 -Wall -Wdeclaration-after-statement -Wall -Wdeclaration-after-statement -Wall -Wdeclaration-after-statement -o .libs/gct-tool activatekey.o changepin.o create.o genkey.o showkey.o showuser.o update.o setsignseq.o setkey.o hashtree.o checktree.o showpasswords.o main.o ../../src/.libs/libgwenhywfar.so -L/usr/lib64 -lgcrypt -ldl -lgpg-error -lgnutls -lssl -lcrypto -pthread
/usr/lib64/gcc/x86_64-suse-linux/7/../../../../x86_64-suse-linux/bin/ld: main.o: in function `main':
/home/ralf.habacker/src/gwenhywfar-build/tools/gcttool/../../../gwenhywfar/tools/gcttool/main.c:244: undefined reference to `GWEN_Funcs_Find'
/usr/lib64/gcc/x86_64-suse-linux/7/../../../../x86_64-suse-linux/bin/ld: /home/ralf.habacker/src/gwenhywfar-build/tools/gcttool/../../../gwenhywfar/tools/gcttool/main.c:230: undefined reference to `GWEN_Funcs_Usage_With_Help

Also, normally we have macros in all-caps in gwen/aqbanking...

Also, normally we have macros in all-caps in gwen/aqbanking...

This macros could be be easily converted to real functions either inlined as shown below

/* Checks if a command variant exists */
#define GWEN_Funcs_Has_Call(func) (func)>func1
#define GWEN_Funcs_Has_Call_Args(func) (func)>func2
#define GWEN_Funcs_Has_Call_DB_NODE_Args(func) (func)>func3
+inline int GWEN_Funcs_Has_Call(const GWEN_FUNCS *func) { return func->func1 != NULL; }
+inline int GWEN_Funcs_Has_Call_Args(const GWEN_FUNCS *func) { return func->func2 != NULL; }
+inline int GWEN_Funcs_Has_Call_DB_NODE_Args(const GWEN_FUNCS *func) { return func->func3 != NULL; }

/* Functions to call a specified command */
#define GWEN_Funcs_Call(func) (func>func1)()
#define GWEN_Funcs_Call_Args(func,a,b) (func>func2)(a,b)
#define GWEN_Funcs_Call_DB_NODE_Args(func,a,b,c) (func>func3)(a,b,c)
+inline int GWEN_Funcs_Call(const GWEN_FUNCS *func) { return func->func1(); }
+inline int GWEN_Funcs_Call_Args(const GWEN_FUNCS *func, int argc, char **argv) { return func->func2(argc, argv); }
+inline int GWEN_Funcs_Call_DB_NODE_Args(const GWEN_FUNCS *func, GWEN_DB_NODE *node, int argc, char **argv) { return func->func3(node, argc, argv); }

or as real functions, which would make them more binary safe.

And how about the shorter element macros proposed above?

Would it be possible to use c++ here ? There would be some nice features available like polymorph functions and constructors as shown in the following uncomplete example.

#include <stdio.h>
#include <string.h>

typedef int (*func1)(void);
typedef int (*func2)(int, char**);
typedef int (*func3)(void*, int, char**);

class Funcs {
public:
    const char *_name;
    const char *_help;
    func1 _func1;
    func2 _func2;
    func3 _func3;
    Funcs() : _name(NULL), _func1(NULL) {}
    Funcs(const char *name, func1 func, const char *help = NULL) : _name(name), _func1(func), _func2(NULL), _func3(NULL), _help(help)  {}
    Funcs(const char *name, func2 func, const char *help = NULL) : _name(name), _func1(NULL), _func2(func), _func3(NULL), _help(help) {}
    Funcs(const char *name, func3 func, const char *help = NULL) : _name(name), _func1(NULL), _func2(NULL), _func3(func), _help(help) {}

    static const Funcs * get(const Funcs *funcs, const char *name)
    {
        for(const Funcs *f = funcs; f->_name; f++) {
            if (strcmp(f->_name, name) == 0)
                return f;
        }
        return NULL;
    }

    int call() const
    {
        fprintf(stderr, "%s %s\n", __PRETTY_FUNCTION__ , _help);
        return _func1();
    }

    int call(int argc, char **argv) const
    {
        fprintf(stderr, "%s %s\n", __PRETTY_FUNCTION__ , _help);
        return _func2(argc, argv);
    }

        int call(void *node, int argc, char **argv) const
    {
        fprintf(stderr, "%s %s\n", __PRETTY_FUNCTION__ , _help);
        return _func3(node, argc, argv);
    }

};

int testfunc1(void) { return 0; }
int testfunc2(int argc, char **argv) { return 0; }
int testfunc3(void *func, int argc, char **argv) { return 0; }
int testfunc4(void *func, int argc, char **argv, int something) { return 0; }

Funcs funcs[] = { 
        Funcs("entry1", testfunc1, "help1"),
        Funcs("entry2", testfunc2),
        Funcs("entry3", testfunc3, "help3"),
        // uncomment to see how the compiler catches that unsupported constructor
        //Funcs("entry4", testfunc4),
        Funcs(),
};

int main(int argc, char **argv)
{
    const Funcs *func = Funcs::get(funcs, "entry1");
    if (func)
        func->call();
    func = Funcs::get(funcs, "entry2");
    if (func)
        func->call(argc, argv);
    func = Funcs::get(funcs, "entry3");
    if (func)
        func->call(NULL, argc, argv);
    return 0;
}

The disadvantage is that all main source files of command line tools (where main() is included) must be migrated to C++ before.

Definately no. I want to stay with C, I really want to avoid the complications that arise from using C++ especially in such libraries as gwen.

Years ago I used to write in C++ (first participating in OpenHBCI, then writing OpenHBCI-TNG). I encountered many obscure problems especially when using libraries which could not be solved at that time, that's why I wrote the whole AqBanking family in C.

Probably those old problems have since been solved in gcc and stdc++, but I don't want to rewrite the existing and basically nicely working code.

0001-gcttool-restore-showing-global-options-when-using-he.patch

I think that this required patch was not applied to git master.

e43961fb7 tools/gct-tool/main.c (aquamaniac 2005-11-03 00:20:45 +0000 225) if (GWEN_Args_Usage(args, ubuf, GWEN_ArgsOutType_Txt)) {
35ce2dfde tools/gct-tool/main.c (aquamaniac 2005-07-23 09:39:42 +0000 226) fprintf(stderr, "ERROR: Could not create help string\n");
35ce2dfde tools/gct-tool/main.c (aquamaniac 2005-07-23 09:39:42 +0000 227) return 1;
35ce2dfde tools/gct-tool/main.c (aquamaniac 2005-07-23 09:39:42 +0000 228) }

The called function GWEN_Args_Usage() only appends to the given ubuf argument and depends on the following lines to output the string, which are provided by the mentioned patch.

06c85b206 tools/gcttool/main.c (Ralf Habacker 2022-02-24 22:40:02 +0100 229) fprintf(stderr, "%s\n", GWEN_Buffer_GetStart(ubuf));
06c85b206 tools/gcttool/main.c (Ralf Habacker 2022-02-24 22:40:02 +0100 230) GWEN_Buffer_free(ubuf);

0001-gcttool-use-GWEN_FUNCS-shortcuts.patch
0001-Refactor-gsa-tool-to-use-GWEN_Funcs_xxx-functions.patch

These patches were also not applied.

The translation related patches has been moved to https://www.aquamaniac.de/rdm/issues/265

The following patches where rejected bei git:
- 0001-Refactor-gsa-tool-to-use-GWEN_Funcs_xxx-functions.patch
- 0001-gcttool-use-GWEN_FUNCS-shortcuts.patch

Mostly because of changes in de.po.

- 0001-gcttool-use-GWEN_FUNCS-shortcuts.patch

Seems to be applied with https://www.aquamaniac.de/rdm/projects/gwenhywfar/repository/revisions/80863a328553ed54fa62ad9720e68545afba45c7

New patch applied to git, thanks!

Regards
Martin