Another Xcode warning

(1) By oneeyeman on 2023-02-11 21:02:30 [source]

Hi, ALL,

I also receive multiple

Implicit conversion loses integer precision

warnings building SQLite from source inside Xcode {9.4}.

One such place - the first one is:

sqlite3.c@24155:

          do{
            DateTime new;
            memset(&new, 0, sizeof(new));
            iGuess -= iErr;
            new.iJD = iGuess;
            new.validJD = 1;
            rc = toLocaltime(&new, pCtx);
            if( rc ) return rc;
            computeJD(&new);
            iErr = new.iJD - iOrigJD; // Xcode points at this line
          }while( iErr && cnt++<3 );

I presume it is fine, but I'd like to know if I can suppress those warnings.

Neither Windows build with MSVC, nor Linux build with gcc/Makefile produce anything like this.

TIA!!

P.S.: Just for completeness - I'm building on OSX 10.13.6 High Sierra.

(2) By Richard Hipp (drh) on 2023-02-11 21:17:10 in reply to 1 [link] [source]

Implicit conversion loses integer precision

Indeed - the loss of precision will cause an incorrect results whenever your local time differs from UTC by 597 hours or more (nearly 25 days). Of course, that never actually happens, but it is too much to expect Xcode to know that. So the resolution of the LHS of the assignment has been increased to 64 bits. That should resolve the issue.

(3) By oneeyeman on 2023-02-12 03:56:57 in reply to 2 [link] [source]

Hi, Richard,

There are other places where Xcode complains about precision loss.

Implicit conversion loses integer precision: i64 (aka long long) to int

        if( needQuote ) bufpt[j++] = q;
        bufpt[j] = 0;
        length = j;                       // Xcode points here (line 3069)
        goto adjust_width_for_utf8;

Implicit conversion loses integer precision: sqlite3_int64 (aka long long) to VList (aka int)

  if( pIn==0 || pIn[1]+nInt > pIn[0] ){
    /* Enlarge the allocation */
    sqlite3_int64 nAlloc = (pIn ? 2*(sqlite3_int64)pIn[0] : 10) + nInt;
    VList *pOut = sqlite3DbRealloc(db, pIn, nAlloc*sizeof(int));
    if( pOut==0 ) return pIn;
    if( pIn==0 ) pOut[1] = 2;
    pIn = pOut;
    pIn[0] = nAlloc;               // Xcode points here (line 35151)
  }

Implicit conversion loses integer precision: size_t (aka long) to int

  if( statbuf.st_size==0 && (pFile->fsFlags & SQLITE_FSFLAGS_IS_MSDOS)!=0 ){
    do{ rc = osWrite(fd, "S", 1); }while( rc<0 && errno==EINTR );     // Xcode points here (line 30050)
    if( rc!=1 ){
      storeLastErrno(pFile, errno);
      return SQLITE_IOERR;
    }
    rc = osFstat(fd, &statbuf);
    if( rc!=0 ){
      storeLastErrno(pFile, errno);
      return SQLITE_IOERR;
    }
  }
#endif

Implicit conversion loses integer precision: unsigned long long to int

    if( pFile->eFileLock==EXCLUSIVE_LOCK ){
      rc = afpSetLock(context->dbPath, pFile, SHARED_FIRST, SHARED_SIZE, 0);
      if( rc==SQLITE_OK && (eFileLock==SHARED_LOCK || pInode->nShared>1) ){
        /* only re-establish the shared lock if necessary */
        int sharedLockByte = SHARED_FIRST+pInode->sharedByte;       // Xcode points here (line 39799)
        rc = afpSetLock(context->dbPath, pFile, sharedLockByte, 1, 1);
      } else {

Implicit conversion loses integer precision: ssize_t (aka long) to int

#if defined(USE_PREAD)
    got = osPread(id->h, pBuf, cnt, offset);     // Xcode points here(line 39450)
    SimulateIOError( got = -1 );
#elif defined(USE_PREAD64)

Those are first couple.

I can probably send you the full log privately if you want.

Let me know...

Thx.