Here memset isn't going to do the job, since it operates on bytes, and regrettably the world has moved on from 256-bit displays the only reason it works in this case (and a few others) is because "black" happens to translate to all-zeroes, but in general colors of a modern framebuffer don't fit in a byte.

So what you should do is find the size of a pixel, in bytes (probably 4 bytes since you have a uint32_t in your code), and have a loop that goes over every 4-byte block in the m_FrameBuffer (representing a pixel's color) and set it to the proper color code. Your language/framework should have some sort of function to convert an RGB triplet to its 4-byte representation (really, it's just one byte for red, green, blue, and one last byte for alpha or reserved, but the order of those bytes is not standardized, it could be RGBA, BGRA, ARGB, ...). Something like this:

uint32_t color = toRGBA(your_color);
uint32_t *ptr = m_FrameBuffer;

for (size_t y = 0; y < m_Height; ++y)
  for (size_t x = 0; x < m_Width; ++x)
    *(ptr++) = color;

Your language may already come with a block-copy function which does the same thing as the code above, and is safer/more optimized.

Or, alternatively, look for an SDL function that does the same thing in a cross-platform manner, because writing to raw pixel memory does not always give the same results everywhere, due to byte order issues, alignment, scanline stride (in case you're dealing with, say, 24-bit framebuffers) and so on.

tl;dr there is probably a better way to clear the framebuffer in SDL, but the above answers your immediate question.

How about using std::fill ? How it would be used for clearing the buffer then ?

Well, I suppose you'd work out the length of the buffer (height * stride) and then use std::fill to fill it with the value you want. (?)

It doesn't hurt anything to write in the padding area, if that's what you're worried about.