system.h: remove some macros

[bagder]

Since curl_off_t is always 64 bit these days, we can simplify and avoid using some macros.

[bagder]

Hm ,that windows CE build failure looks weird...

[bagder]

clearly that (cmake) Windows CE build gets curl_off_t of the wrong size but I can't figure out why, and the corresponding automake build does not cause those errors?

[jay]

Replacing the integer suffix macro CURL_OFF_T_C(123) with long-long suffix 123LL is probably not going work everywhere. LL is only guaranteed in C99 and besides that we don't know necessarily that it's going to be 64-bit. For example some platforms the L suffix is appropriate because longs are 64-bit, maybe LL is 128-bit (edit: seems unlikely from what I just read), or anyway you would be converting the curl_off_t long type to a long long so it's not the right suffix

[bagder]

Thanks, I'll avoid the LL suffix.

[bagder]

If I understand things correctly, in this Windows CE build that fails, it runs cmake and defines HAVE_CONFIG_H which makes the source not include config-win32.h and therefore UNDER_CE is never defined. It seems to make the build get the wrong data type for curl_off_t somehow, so the build rightfully complains and errors out.

But we have a similar build using automake that should result in the same thing, but it succeeds?

Puzzling. And Windows CE support is already marked for removal so...

[bagder]

Oh wait, UNDER_CE is never defined by us, it is a define done internally by the Visual Studio compiler.

[vszakats]

It seems gcc 4.4.0 of mingw32ce is sensitive by default to unsuffixed long long integer literals. It's causing the CMake Windows CE failures. autotools detects GNU99 mode and enables it automatically, but not CMake.

This should fix it:

--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -88,6 +88,10 @@ elseif(WIN32 AND WINCE AND CMAKE_C_COMPILER_ID STREQUAL "GNU")  # mingw32ce buil
   set(CMAKE_RC_COMPILE_OBJECT "<CMAKE_RC_COMPILER> -O coff <DEFINES> <INCLUDES> <FLAGS> <SOURCE> <OBJECT>")
   enable_language(RC)
 
+  # To compile long long integer literals
+  set_property(DIRECTORY APPEND PROPERTY COMPILE_OPTIONS "-std=gnu99")
+  string(APPEND CMAKE_REQUIRED_FLAGS " -std=gnu99")
+
   set(CMAKE_C_COMPILE_OPTIONS_PIC "")  # CMake sets it to '-fPIC', confusing the toolchain and breaking builds. Zap it.
 
   set(CMAKE_STATIC_LIBRARY_PREFIX "lib")

→ PR #17523

[jay]

Not having any suffix may also be a problem with some pre-c99 compilers because of the way c89 is written 3.1.3.2 Integer constants

   The type of an integer constant is the first of the corresponding
list in which its value can be represented.  **Unsuffixed decimal: int,
long int, unsigned long int;** unsuffixed octal or hexadecimal: int,
unsigned int, long int, unsigned long int; suffixed by the letter u
or U: unsigned int, unsigned long int; suffixed by the letter l or
L: long int, unsigned long int; suffixed by both the letters u or U
and l or L: unsigned long int .

So some compilers may try to fit the large numbers in a 32-bit long even if some 64-bit long long equivalent is available. I have no objection to #17523 but my point is it may not be the only compiler that does that

[bagder]

So some compilers may try to fit the large numbers in a 32-bit long even if some 64-bit long long equivalent is available

Sure, but we might also never run into such a compiler. I suspect our now mandatory support for a working 64 bit type removes some of the quirkiest old compilers from the equation.

[bagder]

If we find any problems with this down the line, we should fix those with a set of private macros/defines, not public ones.