On 2/7/20 3:14 PM, Jens Alfke wrote:

On Feb 7, 2020, at 9:11 AM, chiahui chen <chiahuich...@gmail.com> wrote:

/usr/include/sqlite3ext.h:437:53: note: expanded from macro

#define sqlite3_vsnprintf              sqlite3_api->vsnprintf

                                       ~~~~~~~~~~~  ^

/usr/include/secure/_stdio.h:75:3: note: expanded from macro 'vsnprintf'

  __builtin___vsnprintf_chk (str, len, 0, __darwin_obsz(str), format, ap)

This appears to be your problem. The system header <secure/_stdio.h> is 
defining `vsnprintf` as a macro that expands to a compiler builtin. This is 
conflicting with a struct field named `vsnprintf` in the SQLite extension API.

I've never heard of <sys/_stdio.h> before, although it does exist in the macOS SDK. 
Looking through the normal <stdio.h>, it does include that header at the end:

        #if defined (__GNUC__) && _FORTIFY_SOURCE > 0 && !defined (__cplusplus)
        /* Security checking functions.  */
        #include <secure/_stdio.h>

So it looks like the trigger is that you're somehow building with 
_FORTIFY_SOURCE defined, and the others are not.

Anyway, I think you could work around the problem by editing csv.c and 
inserting something like this at the top:
        #include <stdio.h>
        #undef vsnprintf
Or else figuring out how to turn off _FORTIFY_SOURCE.


PS: Your use of `gcc` in the command line confused me briefly — turns out `gcc` 
on macOS is simply an alias for `cc`, so it invokes Clang. If you really want 
GCC for some reason you'd have to install it yourself and put it in your $PATH 
before /usr/bin.

It looks like that header (sys/_stdio.h) is non-conforming. The C Standard does allow the stdio.h header to define a macro for the name vsnprintf, but that macro must be a *function-like* macro (7.1.4p1 in the C17 Standard) which it appears not to be (as that shouldn't cause a problem with the shown code).

Richard Damon

sqlite-users mailing list

Reply via email to