Bugz everywhere!!! I must squash them!

Spot the bug :

for (unsigned int i = (unsigned int)((int)list.size() - 1) ; i >= 0 ; --i) {
   printf("%u\n" , i);
}

If size() returns 0, then i would be 4 billion (too lazy to look up the number), assuming the cast to unsigned treats negative numbers that way.

I feel like that's not the bug you're asking us to find though.

When i reaches 0 and it substracts 1, it wraps around to the maximum value of unsigned int. Therefore, the loop never ends.

GCC knows!

(strangely, clang does too but it's not reported, even with -W -Wall)

SDL_Init(SDL_INIT_EVERYTHING);

Ohhh, can we have al_init_everything()? Instead of:

al_init();
al_init_image_addon();
al_install_keyboard();
al_install_mouse();
al_init_primitives_addon();
al_install_joystick();
al_init_acodec_addon();
al_install_audio();
al_init_font_addon();
al_init_ttf_addon();

Maybe with a bonus version that also creates a display and timer and event queue with everything attached, and a call to al_reserve_samples?

queue = al_init_everything_ex(1280, 720, 60);
// can get the created display with al_get_current_display()

That #call-to-action button::before to prevent image loading when hover/clicked causing a very brief flicker...

You can do what I did. I wrapped them up in a function and used flags.

//pseudo code
int init(int flags)
{
    if (!al_init()) return -1
    if (flag & FLAG_IMAGE_ADDON) ...
}

The correct code would have been :

for (unsigned int i = list.size() ; i > 0 ; --i) {
   printf("%i\n" , (int)i - 1;
}

It's not often you see underflows, but they're there.

EDIT
Eagle init code (verbatim)

Allegro5System* a5sys = GetAllegro5System();
if (EAGLE_FULL_SETUP != a5sys->Initialize(EAGLE_FULL_SETUP) {
   EagleWarn() << "Not all modules initialized. Warning.\n";
}
EagleGraphicsContext* win = a5sys->CreateGraphicsContext(800,600 , EAGLE_WINDOWED | EAGLE_OPENGL);
if (!(win && win->Valid())) {
   EagleCritical() << "Failed to create window.\n";
}

3 line setup for a window. It serves me right. No more lame queue creation and registration every time you want a window with input. Multiple thread safe windows and more.

....Eagle anyone?....no? well ok then.

That was not an example of a bug, just init code.

Post your bugs!

{"name":"612991","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/8\/8\/88c3874f8b5efb365312ba84dabe7fe5.png","w":462,"h":201,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/8\/8\/88c3874f8b5efb365312ba84dabe7fe5"}
From the init code of a microcontroller

Sweet. Hope that microcontroller didn't do anything important.

Then I also want al_destroy_everything()

That exists but only people above our pay-grade are allowed to used it.

Here's a bit of a shocker that I did not know about until today, from man abs

SYNOPSIS
     #include <stdlib.h>

     int
     abs(int i);

DESCRIPTION
     The abs() function computes the absolute value of the integer i.

RETURN VALUES
     The abs() function returns the absolute value.

So far, so good, but then:

BUGS
     The absolute value of the most negative integer remains negative.

That's because signed integers have an extra negative number compared to positive numbers, for example, for an 8 bit value, we have -128 to 127.

You know this and I know this. But I'm sure I've never written code to account for it

x = abs(x);
if (x >= 0) {
 something(x);
} else {
 error();
}

I don't think there's a better option either, returning zero or INT_MAX or anything else would also lead to silent errors. And C doesn't usually raise a signal for integer arithmetic (? does it?)

I'm trying to think if a way in which the negative number issue with abs would matter anyway. With signed 8-bit, if -128 is a possible value, what's stopping you from getting -150 before you call abs? I think the times you need to worry about the minimum number being passed to abs, you have to worry about the value being out of range for the integer type you are using anyway.