SQLite Forum

Please avoid all use of the "LL" suffix for long-long integer literals

Please avoid all use of the "LL" suffix for long-long integer literals

(1) By Nick Gammon (nickgammon) on 2021-04-07 01:36:11 [link] [source]

I recently upgraded SQLite3 from version 3.16.2 to 3.35.3.

Somewhere in those changes were introduced compiler errors for my compiler (MS Visual Studio 6.0) on four lines, namely the ones with long-long constants with the LL suffix.

In the (current) amalgamation (3.35.4) these lines are, in sqlite3.c:

32373:    if( v>4294967296LL ){ *pI = 0; return 0; }

77185:           && i >= -2251799813685248LL && i < 2251799813685248LL);

88849:       if( pIn1->u.i<=140737488355327LL && pIn1->u.i>=-140737488355328LL ){

89051:       }else if( uu<=140737488355327LL ){

I request that the suffix LL be removed from these four lines (and neighouring ones calling testcase - however that is not impacting me personally), in order to avoid the compiler error: C2059 'bad suffix on number'

According to the C standard, decimal integer constants without a suffix are automatically promoted to int, long int or long long int as required to hold the value in the constant. Thus the explicit use of LL is not required.

I note that there was previously a ticket along similar lines:

https://github.com/sqlite/sqlite/commit/5c905d6e9188c62a216cd94c90894504de6b0ec5 "Avoid all use of the "LL" suffix for long-long integer literals.".

This is referenced here:


Doing this would not impact more modern compilers, and would avoid compiler errors on older compilers.

Thanks in advance.

(2) By Warren Young (wyoung) on 2021-04-07 02:01:34 in reply to 1 [link] [source]

Ironically, not having them also causes problems.

Visual Studio 6.0 is from 1998. Are you absolutely certain you can't upgrade? Current Microsoft tools have been free for quite a long time now.

(3.1) By Nick Gammon (nickgammon) on 2021-04-07 04:12:52 edited from 3.0 in reply to 2 [link] [source]

Lol, some people want LL and some don't! You can't win, eh?

I can upgrade, it's just a pain as I usually use Ubuntu for my development, and I have Visual Studio installed in a virtual Windows image. There isn't enough disk free to install later versions. I know that's my problem, but if it could be fixed in the source that would have been good.

I can always fix those 4 lines manually from time to time.

I should point out that there is another place in the source where a long long constant is not so qualified. So right now, neither party is satisfied. At sqlite3.c at line 44310:

  sqlite3_int64 t64;
  t64 = *t;
  t64 = (t64 + 11644473600)*10000000;   // <---- HERE

(4) By Warren Young (wyoung) on 2021-04-07 05:06:25 in reply to 3.1 [link] [source]

There isn't enough disk free to install later versions.

Two suggestions:

  1. Switch to the Ubuntu-hosted MinGW cross-compiler.

  2. Install the Build Tools package, which is the command-line only version of VC++. To replace the IDE bits, you could run whatever text editor you like on the Ubuntu side, then Alt-Tab over to the VM to build.

I can always fix those 4 lines manually from time to time.

Better, clone the SQLite source repo, make your changes, then commit the changes to a branch. Then you simply pull the upstream changes from time to time and merge them into your branch:

$ fossil clone https://sqlite.org/src/sqlite3     # needs Fossil 2.14+
$ cd sqlite3
$ vi src/whatever.c                               # make your changes
$ ./configure && make sqlite3.c                   # test it
$ fossil set autosync pullonly                    # needed once only
$ fossil ci --branch my-special-version -m "initial version commit message"

Then later, automatically merge your changes into the current version:

$ fossil merge trunk                              # pull upstream & merge
$ make sqlite3.c                                  # test again
$ fossil ci -m "updated to latest upstream"       # commit once happy

This will work automatically as long as the upstream version doesn't also change your changed lines, or anything sufficiently close to them. If you get a merge conflict, you can do the manual merge once, then probably be fine for years again.

(5) By Keith Medcalf (kmedcalf) on 2021-04-07 05:18:16 in reply to 3.1 [link] [source]

The current MinGW64/GCC (10.2) compiler set for Windows is just over 1 GB in size and includes the C/C++/ADA compiler sets.


Other versions can be found here:


Note that this is the compiler sets only and not the MSYS/MSYS2 thing.

(6) By Nick Gammon (nickgammon) on 2021-04-07 07:28:28 in reply to 5 [link] [source]

Thank you everyone for your very kind suggestions. :)

Unfortunately I am <sigh> using MFC so it isn't as simple as just finding a compiler that runs on Ubuntu.

I think I'll just live with changing four lines every 6 months or so, as I don't upgrade to the latest SQLite code as soon as it is released.

One suggestion though: Could the five constants in question be placed in a suitable place, guarded by #if defined(_MSC_VER) so that two versions could exist: one with LL and one without? Then the defined versions could be used in the code rather than the literal constants. The constants being:

 4294967296         //  2**32
 2251799813685248   //  2**51
-2251799813685248   // -2**51
 140737488355327    //  2**47 - 1
-140737488355328    // -2**47

Doing this looks better than using "magic numbers" in the code, and the comments could be used to explain why that number and not some other one.

(7) By dab on 2021-04-13 01:06:32 in reply to 6 [link] [source]

If it makes you feel better, I am also a VC6 user (for complex reasons).
You are not alone.

(8) By Scott Robison (casaderobison) on 2021-04-13 01:30:11 in reply to 6 [source]

Or use a macro to qualify them on a platform basis:

#if defined(_MSC_VER)
#define LL(x) (x##I64)
#define LL(x) (x##LL)

if (somevar == LL(123456789012)) { somecode }