-5

I found bug in clang, and i post it here because it's very difficult to find how to do it in clang system. I think this information in useful - i saw similar questions in web.

So, clang makes wrong linking. It's OpenBSD 6.3 amd64, stable.

When one of modules has global variable with the same name as library function - it links library function call to variable, even when variable has type "int". Example:

Main (simple) module "socket.cpp" with call to socket():

#include <stdio.h>
#include <sys/socket.h>

int
main(int argc, char * argv[]){
    int result = socket(AF_INET, SOCK_DGRAM, 17);

    printf("result = %d\n", result);

    return 0;
}

Second module "add.cpp" with global variable named "socket":

int socket = 5;

You make compile and link them with makefile/clang without warnings. But when you run this program - you receive "Segmentation fault".

If i see executable in disassembler, i see - there are no calls to system function "socket". It "calls" this variable by ugly way.

If anybody knows how to make this bug report to clang community, please...

UPDATE 1

clang was called by following:

clang -o test  socket.o add.o

UPDATE 2

Well, this is expected, I presume. How linker is supposed to differentiate between two socket symbols? – arrowd

How Microsoft Compiler distinguish it? Very difficult technic? This code works fine in Visual Studio. It is not problem there.

UPDATE 3

The code then "calls" it, what produces a crash. This is not a bug. – arrowd

In programmer's logic this is BUG. How variable "int" can be called? This design specific has bad ergonomics.

Why linker says nothing about "calling" the variable "int". It's nonsense. It's bad design of system.

MUST BE WARNING OF AMBIGUITY DURING LINKING. SILENT BEHAVIOR - SPRING OF ERRORS.

  • How do you call clang to link this code? – arrowd Oct 30 '18 at 16:00
  • @arrowd clang socket.cpp var.cpp would do it. – Kusalananda Oct 30 '18 at 16:01
  • 1
    I'm unsure of how useful it is to migrate a humdrum violation of the One Definition Rule to Stack Overflow, when it has so many questions and answers about it already. – JdeBP Oct 30 '18 at 16:17
  • 1
    Actually, it's not the ODR. It's a violation of an explicit constraint on programs in dcl.link, no diagnostic required. – JdeBP Oct 30 '18 at 16:28
  • 1
    The first rule of compiler bugs: it's not a compiler bug, it's your code. The second rule of compiler bugs: it's still not a compiler bug, it's still your code. – Philip Kendall Oct 30 '18 at 16:34
2

It happens, because you are trying to execute integer as a function. int socket = 5; has the same name as function socket() There is an esier way to acheve this, by something like this:

$ cat main.c
int main = 9;
$ clang -Wall main.c
$ ./a.out
Segmentation fault

Update: as @Kusalananda mentioned in comment it happens not only on clang.

  • 2
    Also, this is not dependent on clang as the compiler. – Kusalananda Oct 30 '18 at 16:23
2

Linker resolves socket symbol to your integer variable. The code then "calls" it, what produces a crash. This is not a bug.

It happens to work with Microsoft compiler due to special mangling scheme used to decorate all exported symbols. In this scheme C functions and global variables are decorated differently (?socket@@YAHHHH@Z vs ?socket@@3HA), which leads to different symbol names. On *nix systems no mangling is used for plain C functions and global variables.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.