Current-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Fwd: Problem with SQLite 3.7.6

On Mon, 18 Apr 2011, Matthias Drochner wrote: 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 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)

Home | Main Index | Thread Index | Old Index