search for: int8_min

...these warnings: 1>e:\Jochen\Lib\lib\include\llvm/Use.h(218): warning C4624: 'llvm::AugmentedUse' : destructor could not be generated because a base class destructor is inaccessible 1>C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\stdint.h(72): warning C4005: 'INT8_MIN' : macro redefinition 1> e:\Jochen\Lib\lib\include\llvm/Support/DataTypes.h(116) : see previous definition of 'INT8_MIN' The second one is because the visual c++ codepath in DataTypes.h does not check for stdint.h which is available on vs 10 (but not inttypes.h). -Joche...

Hi! In DataTypes.h (generated from DataTypes.cmake) there is an extra code path for Visual C. This can produce macro redefinitions for INT8_MAX, INT8_MIN etc. since other headers may also define them. Therefore please protect the macros like INT8_C etc. Also it would be nice if the auto-generated HAVE_STDINT_H and HAVE_INTTYPES_H would be used also for Visual C since it is possible to add them to the global header directory (e.g. http://msinttypes....

...llvm::ConstantSInt::isValueValidForType(const llvm::Type*, long long int)': Constants.cpp:368: error: `INT8_MAX' undeclared (first use this function) Constants.cpp:368: error: (Each undeclared identifier is reported only once for each function it appears in.) Constants.cpp:368: error: `INT8_MIN' undeclared (first use this function) Constants.cpp:370: error: `INT16_MAX' undeclared (first use this function) Constants.cpp:370: error: `INT16_MIN' undeclared (first use this function) Constants.cpp:372: error: `INT32_MAX' undeclared (first use this function) Constants.cpp:372: e...

...ne LONG_LONG_MAX LLONG_MAX #define ULONG_LONG_MAX ULLONG_MAX #define QUAD_MIN LLONG_MIN #define QUAD_MAX LLONG_MAX #define UQUAD_MAX ULLONG_MAX ... --- /usr/include/limits.h --------------------- Which defintions do you think encompasses LLVMs expectations?: INT8_MAX - SCHAR_MAX //signed INT8_MIN - SCHAR_MIN //signed INT16_MAX - SHRT_MAX //signed INT16_MIN - SHRT_MIN //signed INT32_MAX - LONG_MAX //signed INT32_MIN - LONG_MIN //signed ... UINT8_MAX - CHAR_MIN //unsigned - #define _CHAR_UNSIGNED || __CHAR_UNSIGNED__ UINT8_MIN - (implicitly 0?) UINT16_MAX - USHRT_MAX //unsigned UINT16...

...ONG_LONG_MAX LLONG_MAX #define ULONG_LONG_MAX ULLONG_MAX #define QUAD_MIN LLONG_MIN #define QUAD_MAX LLONG_MAX #define UQUAD_MAX ULLONG_MAX ... --- /usr/include/limits.h --------------------- Which defintions do you think encompasses LLVM's expectations? INT8_MAX - SCHAR_MAX //signed INT8_MIN - SCHAR_MIN //signed INT16_MAX - SHRT_MAX //signed INT16_MIN - SHRT_MIN //signed INT32_MAX - LONG_MAX //signed INT32_MIN - LONG_MIN //signed ... UINT8_MAX - CHAR_MIN //unsigned #define _CHAR_UNSIGNED || __CHAR_UNSIGNED__ UINT8_MIN - (implicitly defined as 0?) UINT16_MAX - USHRT_MAX /...

...ONG_MAX > > > #define QUAD_MIN LLONG_MIN > #define QUAD_MAX LLONG_MAX > #define UQUAD_MAX ULLONG_MAX > ... > --- /usr/include/limits.h --------------------- > > Which defintions do you think encompasses LLVMs expectations?: > > INT8_MAX - SCHAR_MAX //signed > INT8_MIN - SCHAR_MIN //signed > INT16_MAX - SHRT_MAX //signed > INT16_MIN - SHRT_MIN //signed > INT32_MAX - LONG_MAX //signed > INT32_MIN - LONG_MIN //signed > ... > UINT8_MAX - CHAR_MIN //unsigned - #define _CHAR_UNSIGNED || > __CHAR_UNSIGNED__ > UINT8_MIN - (implicitly 0?) &g...

...path ... > > #endif Sorry, that doesn't show an extra code path. DataTypes.h contains stuff specific for MSVC and stuff for the rest of compilers. The #ifndef...#else does just that. Maybe you are reading #ifndef as #ifdef? >>> This can produce macro redefinitions for INT8_MAX, INT8_MIN etc. >>> since other headers may also define them. Therefore please >>> protect the macros like INT8_C etc. >>> >>> Also it would be nice if the auto-generated HAVE_STDINT_H >>> and HAVE_INTTYPES_H would be used also for Visual C since it >>> is...

...mp;end, 0); -#if INT_MAX != LONG_MAX - if (r < INT_MIN || r > INT_MAX) - errno = ERANGE; -#endif - PARSE_COMMON_TAIL; -} - -int -nbdkit_parse_int8_t (const char *what, const char *str, int8_t *rp) -{ - long r; - char *end; - - errno = 0; - r = strtol (str, &end, 0); - if (r < INT8_MIN || r > INT8_MAX) - errno = ERANGE; - PARSE_COMMON_TAIL; -} - -int -nbdkit_parse_int16_t (const char *what, const char *str, int16_t *rp) -{ - long r; - char *end; - - errno = 0; - r = strtol (str, &end, 0); - if (r < INT16_MIN || r > INT16_MAX) - errno = ERANGE; - PARSE_CO...

If we compare the "common" subdirectory between nbdkit @ 6b4178d0fdfe ("ci: Temporarily disable perl in MacOS", 2023-02-27) and libnbd @ d05cd8f384a7 ("Version 1.15.11.", 2023-02-28), we find differences. We can categorize these differences along two (orthogonal) axes: - Intentional or unintentional. Intentional differences are for example when one of the libnbd

This is the previous 5/9 patch posted earlier today, split into reviewable chunks. This passes bisection with -x 'make && make check', but I didn't work very hard on the commit messages, so I refer you back to the original patch to explain how it works: https://www.redhat.com/archives/libguestfs/2020-March/msg00248.html Rich.

...mp;end, 0); +#if INT_MAX != LONG_MAX + if (r < INT_MIN || r > INT_MAX) + errno = ERANGE; +#endif + PARSE_COMMON_TAIL; +} + +int +nbdkit_parse_int8_t (const char *what, const char *str, int8_t *rp) +{ + long r; + char *end; + + errno = 0; + r = strtol (str, &end, 0); + if (r < INT8_MIN || r > INT8_MAX) + errno = ERANGE; + PARSE_COMMON_TAIL; +} + +int +nbdkit_parse_int16_t (const char *what, const char *str, int16_t *rp) +{ + long r; + char *end; + + errno = 0; + r = strtol (str, &end, 0); + if (r < INT16_MIN || r > INT16_MAX) + errno = ERANGE; + PARSE_CO...

On Mon, Sep 23, 2019 at 12:05:11PM -0500, Eric Blake wrote: > > + int nbdkit_parse_long (const char *what, const char *str, long *r); > > + int nbdkit_parse_unsigned_long (const char *what, > > + const char *str, unsigned long *r); > > Do we really want to encourage the use of parse_long and > parse_unsigned_long? Those differ between

This is v3 of my disk series. What were previously patches 01-06 have been applied. These are the tested and updated remainder, addressing the previous comments. 1 Preparatory work. 2-4 The new parser and its documentation. 5-6 Replace old parsers with calls to the new one. 7-8 Two features, one of them essential. 9 Basic test suite for disk string parsing, as adhoc script.

This creates libnbdkit.so as discussed in the following thread: https://www.redhat.com/archives/libguestfs/2020-March/thread.html#00203 test-delay-shutdown.sh fails for unclear reasons. This series starts by reverting "tests: Don't strand hung nbdkit processes" which is because several other tests fail randomly unless I revert this patch. I didn't investigate this yet so it