Re: Fwd: Problem with SQLite 3.7.6

[Alan Barrett <apb%cequrux.com@localhost>]

On Mon, 18 Apr 2011, Matthias Drochner wrote:
> adam%NetBSD.org@localhost said:
> > Can you tell me how to reproduce the problem so that we can 
> > debug it?
>
> This looks amd64 specific, and highly dependent on compiler 
> version and optimization level.
>
> Casting a function pointer from varargs-using to 
> non-varargs-using is generally not innocuous. The calling 
> conventions can be different.

Around line 24410 of sqlite3.c (in sqlite version 3.0.7.2) appears 
this code:

 24410 static struct unix_syscall {
 24411   const char *zName;            /* Name of the sytem call */
 24412   sqlite3_syscall_ptr pCurrent; /* Current value of the system call */
 24413   sqlite3_syscall_ptr pDefault; /* Default value */
 24414 } aSyscall[] = {
 24415   { "open",         (sqlite3_syscall_ptr)open,       0  },
 24416 #define osOpen      ((int(*)(const char*,int,...))aSyscall[0].pCurrent)

So, any call to the osOpen() macro will attempt to call the open() 
function as if it were declared as

  int open(const char *, int, ...);

However, NetBSD declares open() as

  int open(const char *, int, mode_t);

As Matthias Drochner explained, those two declarations of open() 
are not compatible, so taking a pointer to one of them, casting it 
to the other type, and then calling through the pointer, may not 
work.

POSIX specifies that open(2) is a varags function, so I think 
NetBSD is not compliant here.  However, it would probably make 
sense for sqlite to add an autoconf test for this, and to define 
osOpen with either "..." or "mode_t" in the relevant position 
according to the result of the test.

--apb (Alan Barrett)