Cactus loops endlessly if given the same name for aliased function and actual implementation

Create issue
Issue #1376 closed
Frank Löffler created an issue

Currently, if an aliased function is declared in interface.ccl with

PROVIDES FUNCTION fun WITH fun LANGUAGE C

Cactus goes into an infinite loop when calling that function. It does so because it creates a function 'fun' (the first) itself, which then calls (fun) the second.

Instead, Cactus should already produce an error for above declaration. The two 'fun' must be different for this to work, and Cactus should catch this.

Keyword:

Comments (8)

  1. Erik Schnetter
    • removed comment

    On a related note: In this setup, there should have been two functions called "fun", and the linker should have complained as well.

  2. Erik Schnetter
    • removed comment

    (Annoyed because Trac ate my first comment since anonymous replied in the mean time.)

    The error message is slightly confusing because it is worded as if the two functions had different names. I would write instead "In thorn $thorn, the aliased function $function cannot be provided by a function with the same name."

    Also, the following suggestion contains a typo: "be" -> "by". I would also add "it" (i.e. "prefixing it").

  3. Roland Haas
    • removed comment

    I updated the patch to be more explicit. I removed the "eg" from the hint to make it fit inside 80 characters (avoids line breaking).

    Usually when trac rejects my comments due to someone else having commented first, the text of my comment is still present and and can save it by copying it to the clipboard and re-insert into a new comment form. Did it not offer this option to you?

  4. Roland Haas
    • removed comment

    Replying to [comment:1 eschnett]:

    On a related note: In this setup, there should have been two functions called "fun", and the linker should have complained as well. Would the linker complain with default options? The thorns and flesh appear as libraries to the linker and multiply defined functions in libraries are fine aren't they? This is the way one overrides eg malloc when linking with a debugging library? A quick experiment with two different functions "fun" in two different static libraries returns no error. Just adding --whole-archive makes the link fail but with errors due to libgcc so I am not doing '''that''' the right way it seems. I have used:

    ==> main.c <==
    int fun(int a);
    
    int main(void) {
      fun(1);
      return 0;
    }
    
    ==> a.c <==
    #include <stdio.h>
    int fun(int a) { printf("a\n"); }
    
    ==> b.c <==
    #include <stdio.h>
    int fun(int a) { printf("b: %d\n", a); }
    
    gcc -c -o b.o b.c && ar  -cvq libb.a b.o
    gcc -c -o a.o a.c && ar  -cvq liba.a a.o
    gcc -o main main.c -L. -l a -l b # this uses the function in a
    gcc -o main main.c -L. -l b -l a # this uses the function in b
    
  5. Log in to comment