On Feb 1, 2009, at 7:34 AM, Maurí cio wrote:

> Hi,
>
> When building sqlite 3.6.10 amalgamation, I get
> a warning message saying:
>
> attention : ignoring return value of ‘write’, declared with  
> attribute warn_unused_result
>
>   /* On OS X on an msdos filesystem, the inode number is reported
>   ** incorrectly for zero-size files.  See ticket #3260.  To work
>   ** around this problem (we consider it a bug in OS X, not SQLite)
>   ** we always increase the file size to 1 by writing a single byte
>   ** prior to accessing the inode number.  The one byte written is
>   ** an ASCII 'S' character which also happens to be the first byte
>   ** in the header of every SQLite database.  In this way, if there
>   ** is a race condition such that another thread has already  
> populated
>   ** the first page of the database, no damage is done.
>   */
>   if( statbuf.st_size==0 ){
>     write(fd, "S", 1);
>     rc = fstat(fd, &statbuf);
>     if( rc!=0 ){
>       pFile->lastErrno = errno;
>       return SQLITE_IOERR;
>     }
>   }
>

This is a rare example of a case where a compiler warning was actually  
helpful.  We usually find that warnings from compilers and other  
static analysis tools do not indicate real bugs.  Sometimes, however,  
in our efforts to remove compiler warnings so that people won't  
complain, we make the warning go away by introducing real bugs into  
the code.  (For an example of this, see 
http://www.sqlite.org/cvstrac/tktview?tn=3618) 
   We find in particular that some brands of compilers emit huge  
numbers of silly and pointless warnings.  (Let us not name specific  
brands here.)

In this case, though, the compiler warning does point to a potential  
problem, though the problem is very obscure.  The problem can only  
result on OSX when trying to create a new SQLite database on an MSDOS  
filesystem where the filesystem is full.  And even then, the problem  
is likely to be detected later on in the process, so it is not at all  
clear that this problem could ever impact an actual application.  But  
it seems worth fixing, all the same.

We'll probably put the whole block of code within #ifdef __APPLE__.

D. Richard Hipp
d...@hwaci.com



_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Reply via email to