It might be the best to change the ImVector size type to size_t to get rid of the warning(s). Signed integer overflows can be really dangerous, if conditions might be optimized away, especially by GCC.

I have removed all size_t maybe two months ago, along removing the possibility to replace ImVector<> by user's implementation (or std::vector). It made the code much shorter, actually faster, less casts everywhere for cope with all platforms, smaller storage space, also allowing us to make the ImVector class better with extra helpers, it was a definitive win.

I don't know what you mean by "signed overflow can be really dangerous". Those operators requires a valid index anyway. Does casting i to (unsigned int)i fixes the warning?

I have removed all size_t maybe two months ago, along removing the possibility to replace ImVector<> by user's implementation (or std::vector). It made the code much shorter, actually faster, less casts everywhere for cope with all platforms, smaller storage space, also allowing us to make the ImVector class better with extra helpers, it was a definitive win.

How about unsigned int instead of size_t?

I don't know what you mean by "signed overflow can be really dangerous". Those operators requires a valid index anyway.

Signed integer overflow invokes undefined behavior and is a great source for troubles.

Quoting the LLVM blog:

Signed integer overflow: If arithmetic on an 'int' type (for example) overflows, the result is undefined. One example is that "INT_MAX+1" is not guaranteed to be INT_MIN. This behavior enables certain classes of optimizations that are important for some code. For example, knowing that INT_MAX+1 is undefined allows optimizing "X+1 > X" to "true". Knowing the multiplication "cannot" overflow (because doing so would be undefined) allows optimizing "X*2/2" to "X".

Does casting i to (unsigned int)i fixes the warning?

Yes, there are no warnings with:

diff --git a/imgui.h b/imgui.h
index 7e3bf64..bb2d063 100644
--- a/imgui.h
+++ b/imgui.h
@@ -775,8 +775,8 @@ public:
    inline int                  size() const                    { return Size; }
    inline int                  capacity() const                { return Capacity; }

-    inline value_type&          operator[](int i)               { IM_ASSERT(i < Size); return Data[i]; }
-    inline const value_type&    operator[](int i) const         { IM_ASSERT(i < Size); return Data[i]; }
+    inline value_type&          operator[](int i)               { IM_ASSERT((unsigned int)i < (unsigned int)Size); return Data[i]; }
+    inline const value_type&    operator[](int i) const         { IM_ASSERT((unsigned int)i < (unsigned int)Size); return Data[i]; }

    inline void                 clear()                         { if (Data) { Size = Capacity = 0; ImGui::MemFree(Data); Data = NULL; } }
    inline iterator             begin()                         { return Data; }

How about unsigned int instead of size_t?

That still leads to lots of signed/unsigned casting in the code and in user's code, with higher warning settings that sort of casting never ends to spread. I initially had the code strictly use unsigned value for sizes and wondered why e.g. stb_ libraries tends to mostly use 'int' but I eventually drifted toward that, it made things really easier and neater.

I'm really puzzled by the fix, I wonder if it stem from an inline extension.

That still leads to lots of signed/unsigned casting in the code and in user's code, with higher warning settings that sort of casting never ends to spread. I initially had the code strictly use unsigned value for sizes and wondered why e.g. stb_ libraries tends to mostly use 'int' but I eventually drifted toward that, it made things really easier and neater.

The C++ standard libraries are all using unsigned size types (AFAIK).

I'm really puzzled by the fix, I wonder if it stem from an inline extension.

Most likely, would at least explain the wrong line numbers.

As a workaround, you could check for __OPTIMIZE__ and make the assertions a no-op in "release" mode.

Not great either, but it would silence the warnings.

The C++ standard libraries are all using unsigned size types (AFAIK).

Yes they do. It makes it really tedious to maintain 32+64 bits code with high level of warnings.
(I was referring to the stb library not std)

I'm still puzzled as to why casting both operands to (unsigned int) makes a difference at all. What does IM_ASSERT expand to for you?

Yes they do. It makes it really tedious to maintain 32+64 bits code with high level of warnings.
(I was referring to the stb library not std)

Yes, I know, was just an example 😃.

However, unsigned int shouldn't be much of a problem as long as the user code is mostly using unsigned int too.

I'm still puzzled as to why casting both operands to (unsigned int) makes a difference at all. What does IM_ASSERT expand to for you?

Need to cast both operands to avoid signed/unsigned comparison.

Otherwise you would get tons of warnings:

In file included from ../../imgui.h:24:0,
                from ../../imgui_demo.cpp:12:
../../imgui.h: In instantiation of ‘const value_type& ImVector<T>::operator[](int) const [with T = float; ImVector<T>::value_type = float]’:
../../imgui.h:1239:134:   required from here
../../imgui.h:779:93: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
    inline const value_type&    operator[](int i) const         { IM_ASSERT((unsigned int)i < Size); return Data[i]; }
                                                                                            ^
../../imgui.h:779:67: note: in expansion of macro ‘IM_ASSERT’
    inline const value_type&    operator[](int i) const         { IM_ASSERT((unsigned int)i < Size); return Data[i]; }
                                                                  ^
../../imgui.h: In instantiation of ‘ImVector<T>::value_type& ImVector<T>::operator[](int) [with T = ImFont*; ImVector<T>::value_type = ImFont*]’:
../../imgui_demo.cpp:214:46:   required from here
../../imgui.h:778:93: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
    inline value_type&          operator[](int i)               { IM_ASSERT((unsigned int)i < Size); return Data[i]; }
                                                                                            ^
../../imgui.h:778:67: note: in expansion of macro ‘IM_ASSERT’
    inline value_type&          operator[](int i)               { IM_ASSERT((unsigned int)i < Size); return Data[i]; }
                                                                  ^
../../imgui.h: In instantiation of ‘ImVector<T>::value_type& ImVector<T>::operator[](int) [with T = float; ImVector<T>::value_type = float]’:
../../imgui_demo.cpp:675:37:   required from here
../../imgui.h:778:93: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
    inline value_type&          operator[](int i)               { IM_ASSERT((unsigned int)i < Size); return Data[i]; }
                                                                                            ^
../../imgui.h:778:67: note: in expansion of macro ‘IM_ASSERT’
    inline value_type&          operator[](int i)               { IM_ASSERT((unsigned int)i < Size); return Data[i]; }
                                                                  ^
../../imgui.h: In instantiation of ‘ImVector<T>::value_type& ImVector<T>::operator[](int) [with T = ImVec2; ImVector<T>::value_type = ImVec2]’:
../../imgui_demo.cpp:1665:58:   required from here
../../imgui.h:778:93: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
    inline value_type&          operator[](int i)               { IM_ASSERT((unsigned int)i < Size); return Data[i]; }
                                                                                            ^
../../imgui.h:778:67: note: in expansion of macro ‘IM_ASSERT’
    inline value_type&          operator[](int i)               { IM_ASSERT((unsigned int)i < Size); return Data[i]; }
                                                                  ^
../../imgui.h: In instantiation of ‘ImVector<T>::value_type& ImVector<T>::operator[](int) [with T = char*; ImVector<T>::value_type = char*]’:
../../imgui_demo.cpp:1695:27:   required from here
../../imgui.h:778:93: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
    inline value_type&          operator[](int i)               { IM_ASSERT((unsigned int)i < Size); return Data[i]; }
                                                                                            ^
../../imgui.h:778:67: note: in expansion of macro ‘IM_ASSERT’
    inline value_type&          operator[](int i)               { IM_ASSERT((unsigned int)i < Size); return Data[i]; }
[... and so on]

But both i and Size are 'int' I don't understand why they would need a cast at all. int < int is valid. That static-overflow warning wouldn't even apply here. That's why I was wondering if your IM_ASSERT macros or the underlying assert macro is expanding to something that create the behavior?

But both i and Size are 'int' I don't understand why they would need a cast at all. int < int is valid. That static-overflow warning wouldn't even apply here.

Yes, i < Size is valid - but after inlining you may have something like:

IM_ASSERT(INT_MAX + 1 < Size);

which may be optimized to always "false".

Anyway, it could be a bogus warning too, it wouldn't be the first time for GCC to show wrong warnings.

That's why I was wondering if your IM_ASSERT macros or the underlying assert macro is expanding to something that create the behavior?

Preprocessed [] operator:

    inline value_type& operator[](int i) { 
# 778 "../../imgui.h" 3 4
                                                                ((
# 778 "../../imgui.h"
                                                                (unsigned int)i < (unsigned int)Size
# 778 "../../imgui.h" 3 4
                                                                ) ? static_cast<void> (0) : __assert_fail (
# 778 "../../imgui.h"
                                                                "(unsigned int)i < (unsigned int)Size"
# 778 "../../imgui.h" 3 4
                                                                , "../../imgui.h", 778, __PRETTY_FUNCTION__))
# 778 "../../imgui.h"
                                                                                                              ; return Data[i]; }

Yes, i < Size is valid - but after inlining you may have something like:
IM_ASSERT(INT_MAX + 1 < Size);
which may be optimized to always "false".
Anyway, it could be a bogus warning too, it wouldn't be the first time for GCC to show wrong warnings.

If it follows inlining this way I don't quite understand why we don't have warnings everywhere in the code every ten lines. It sounds like a bogus warning to me but I'm really curious.

The IM_ASSERT expansion looks ok.

If it follows inlining this way I don't quite understand why we don't have warnings everywhere in the code every ten lines.

It definitely looks like a backend warning, if it would be a frontend warning, then the correct line numbers would be shown.

Might be a gcc 5 regression, gcc 4.9 doesn't show up any warnings.

I've been keeping this open as I felt there's always going to be some useful idea in there, but considering how time has passed it's not realistic :) beside if anything we are not likely be pushing makefiles much.