API changes that do not impact ABI

[Ben Woodard]

We’ve been discussing API changes which probably don’t make any ABI difference but reflect changing language idioms. Consider the two files below. 

---- a.c
char *chop( char *buf){
  return buf+2;
}

---- b.c
void *chop( void *buf){
  return buf+2;
}


$ abidiff a.o b.o 
Functions changes summary: 0 Removed, 1 Changed, 0 Added function
Variables changes summary: 0 Removed, 0 Changed, 0 Added variable

1 function with some indirect sub-type change:

  [C] 'function char* chop(char*)' at b.c:1:1 has some indirect sub-type changes:
    return type changed:
      in pointed to type 'char':
        type name changed from 'char' to 'void'
        type size changed from 8 to 0 (in bits)
    parameter 1 of type 'char*' changed:
      in pointed to type 'char':
        type name changed from 'char' to 'void'
        type size changed from 8 to 0 (in bits)

$ echo $?
4

This is totally an API change but Is this really an ABI change? They both compile to the same machine code.

        push    rbp
        mov     rbp, rsp
        mov     QWORD PTR [rbp-8], rdi
        mov     rax, QWORD PTR [rbp-8]
        add     rax, 2
        pop     rbp
        ret

I was thinking that we should probably add special logic that evaluate char* and void* changes to be harmless when the language is C. When the language is C++ their linkage name mangles differently (unless the functions are given C linkage) and pointer arithmetic on void pointers is not allowed by default so we don’t need to worry about it there. The error reported in that case makes more sense:

$ abidiff a.o2 b.o2 
Functions changes summary: 1 Removed, 0 Changed, 1 Added functions
Variables changes summary: 0 Removed, 0 Changed, 0 Added variable

1 Removed function:

  [D] 'function char* chop(char*)'    {_Z4chopPc}

1 Added function:

  [A] 'function void* chop(void*)'    {_Z4chopPv}

Can anyone see a problem with that?

-ben