Re: [sqlite] Warning message in amalgamation

[D. Richard Hipp]

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, );
> 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

Re: [sqlite] Warning message in amalgamation

[Michael Comperchio]

Roger Binns wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Michael Comperchio wrote:
>   
>> in io.h write returns an int - number of bytes written. Declare an int 
>> and catch the return value.  :)
>> 
>
> And then the compiler will complain that the variable assigned the value
> is not used elsewhere.  You get to keep playing whack-a-mole.
>
> Roger
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iEYEARECAAYFAkmHrB0ACgkQmOOfHg372QQnqQCcCL7HE3aZujFZV/Mn6o+LPYWL
> VdUAnAlbcTWBuZZUCI+G3mEnAybh0gkU
> =jNZ5
> -END PGP SIGNATURE-
> ___
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>
>   
And, since the code in question is to fix a problem, me thinks that, 
perhaps, the developer should be checking to see that, in fact, he got 
his single byte written.

int rc;
rc = write(dahdadah);
if (!rc)
{
print_out_i_didn't_write_message("Call the fantastic developer, who 
not being quick or dead, remembered to check the return codes from file 
i/o functions to make sure that they did what they were supposed);
exit(GO_HOME_EARLY_AND_DRINK_BEER);
}

Today's compilers are some of the best tools available for quality 
software development. If we pay attention to those 'whack-a-mole' 
issues, and think about them, we are probably, 99% of the time, going to 
find that the compiler IS on our side. I remember days when I could hand 
code better assembler and machine code than the compilers, but those 
days are long gone

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

Re: [sqlite] Warning message in amalgamation

[Mike Shal]

On 2/2/09, Roger Binns  wrote:
>  Maurí­cio wrote:
>  > I know this is not a problem, but I would like to
>  > remove this warning since it's not important for
>  > the rest of the code. What could I do?
>
>
> The usual method is to cast the result to (void) but gcc still whines.
>  I suggest you just live with it.  With many people reporting warning
>  issues the assumption seems to be that somehow the compiler is reporting
>  an important insight that the developers missed and could cause SQLite
>  to trivially malfunction.  The opposite is actually true - SQLite
>  functions just fine and the compilers are making mistaken claims.
>  Consider those warnings pointing out an inadequacy in the compiler and
>  get the compiler people to fix their program!
>
>   http://sqlite.org/testing.html
>

I would hope the "usual method" would be to check the return value of
the write call to make sure that it actually wrote. Looking at the
file in question, a later pwrite() call correctly checks the return
value to see if it is negative (indicating an error), and also checks
to see if fewer bytes were written than was requested. So why should
this write() be different? The comment doesn't seem to indicate why we
can assume this particular write() will always succeed, or why we
don't care if it doesn't. The testing page you linked to suggests that
sqlite is tested under full-disk conditions, which is somewhat
reassuring, though without digging into the testing internals too
significantly I am not convinced that we could have a case where a
disk fills up just before the write() call, causing it to fail to
write the one byte and forcing the inode returned by fstat() to be the
bizarre 9 thing again. Can you explain why that shouldn't be a
concern? If so, it would be nice to comment that in the source.

Also, if you truly believe the unused result warning to be an error,
you would want to take it up with your libc maintainers, not the
compiler maintainers. The __warn_unused_result gcc attribute is a
useful facility - I think you're just questioning its use in the
write() call in libc.

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

Re: [sqlite] Warning message in amalgamation

[Roger Binns]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Michael Comperchio wrote:
> in io.h write returns an int - number of bytes written. Declare an int 
> and catch the return value.  :)

And then the compiler will complain that the variable assigned the value
is not used elsewhere.  You get to keep playing whack-a-mole.

Roger
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkmHrB0ACgkQmOOfHg372QQnqQCcCL7HE3aZujFZV/Mn6o+LPYWL
VdUAnAlbcTWBuZZUCI+G3mEnAybh0gkU
=jNZ5
-END PGP SIGNATURE-
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Warning message in amalgamation

[Michael Comperchio]

Roger Binns wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Maurí­cio wrote:
>   
>> I know this is not a problem, but I would like to
>> remove this warning since it's not important for
>> the rest of the code. What could I do?
>> 
>
> The usual method is to cast the result to (void) but gcc still whines.
> I suggest you just live with it.  With many people reporting warning
> issues the assumption seems to be that somehow the compiler is reporting
> an important insight that the developers missed and could cause SQLite
> to trivially malfunction.  The opposite is actually true - SQLite
> functions just fine and the compilers are making mistaken claims.
> Consider those warnings pointing out an inadequacy in the compiler and
> get the compiler people to fix their program!
>
>   http://sqlite.org/testing.html
>
> Roger
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iEYEARECAAYFAkmHdq4ACgkQmOOfHg372QQKAgCffeIn0vTBdSvx4MSD1owN8mg/
> K3EAn2ueJoNLXwfvnE52iiM6lf53FSe5
> =jjfQ
> -END PGP SIGNATURE-
> ___
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>
>   

in io.h write returns an int - number of bytes written. Declare an int 
and catch the return value.  :)

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

Re: [sqlite] Warning message in amalgamation

[Roger Binns]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Maurí­cio wrote:
> I know this is not a problem, but I would like to
> remove this warning since it's not important for
> the rest of the code. What could I do?

The usual method is to cast the result to (void) but gcc still whines.
I suggest you just live with it.  With many people reporting warning
issues the assumption seems to be that somehow the compiler is reporting
an important insight that the developers missed and could cause SQLite
to trivially malfunction.  The opposite is actually true - SQLite
functions just fine and the compilers are making mistaken claims.
Consider those warnings pointing out an inadequacy in the compiler and
get the compiler people to fix their program!

  http://sqlite.org/testing.html

Roger
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkmHdq4ACgkQmOOfHg372QQKAgCffeIn0vTBdSvx4MSD1owN8mg/
K3EAn2ueJoNLXwfvnE52iiM6lf53FSe5
=jjfQ
-END PGP SIGNATURE-
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

[sqlite] Warning message in amalgamation

[Maurí­cio]

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

This is on a small piece of code related to ticket
#3260, according to the source documentation. (See
the code below.)

I know this is not a problem, but I would like to
remove this warning since it's not important for
the rest of the code. What could I do?

Thanks,
Maurício

   /* 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, );
 if( rc!=0 ){
   pFile->lastErrno = errno;
   return SQLITE_IOERR;
 }
   }

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