While looking up information about secure coding practices, I came across a few articles that recommend you avoid a bunch of different standard functions due to some security flaws that they have.

In the PDF below, they give a list of functions to avoid.

Which brings me to the main question, how secure is Allegro?

Allegro's string functions use bstrlib internally and so should be completely "safe".

[edit:] hm, it seems the docs on allegro.cc don't handle unicode chars, linking to liballeg docs instead (it seems to be a bug in firefox though)

Those functions are only "insecure" if you use them in the wrong way, with the exception of gets, which is as good as always a bad idea to use. The real problem with them is that it is easier to use them the wrong way than the right way, and that using them the wrong way can open your code to buffer overflow attacks.

Allegro relies on external libraries like libpng, GDI+, etc to be secure. If any of those have bugs, then Allegro will have bugs. On top of that, Allegro's own code could have security related bugs. e.g., I doubt every al_malloc() is checked to see if it is non NULL.

Then there's user code. If I supply your program with an invalid bitmap, and Allegro returns NULL, and you do nothing about it, then your program will crash. If Allegro were built with security as a primary focus, then every function would check for NULL pointers, etc. But that's your responsibility.

If a user provided a 1000MB allegro.cfg file, then Allegro would probably choke while trying to load the config file. For Allegro's intended purpose, stuff like that doesn't really matter. But if you are running Allegro as part of some online image processing service, then some of these things come into play.

PS: This is, of course, not an exhaustive list. I'm just pointing out that there are many ways to crash a program that doesn't technically have bugs.

If failing to validate input and output leads to a crash, I consider it a bug. It reminds me of this time I was dealing with a laptop manufacturer about a blue screen of death that would occur every time a data logging application my company uses made a particular modem API call. The support got escalated to some customer representative that handled our region of the USA. He kept arguing (wrongly) that it was a bug in the application based on the evidence that was the software that was running when the BSOD occurred. I countered (correctly) that it was a driver bug because a user application shouldn't have the level of system access necessary to crash the OS and the application worked on every other laptop and desktop computer that was made by another manufacturer. I even got the application's developer in touch with the rep, who confirmed that he'd come to notice that Conexant modems used in various different laptops were prone to crashing in this way. I'd gotten on the rep's case enough that eventually the company's engineers released a driver update to address it, although they had the gall to indicate in the release notes that it was to address a crash that occurred when using the data logging application in question. At that point, they can't save face even though they'd like to pretend it wasn't their bad programming at fault.

Validating user's input is generally a waste of time in the context of Allegro. Failing to check the return value of malloc would be a bug.

Validating user input doesn't help, e.g. if you look at the 'safe' string functions you can still pass invalid pointers.

Sometimes it's appropriate to code defensively and constantly check the validity of arguments at every step along the stack, but that will weigh-in on performance. If performance isn't a concern of yours then you're probably doing it wrong coding in C in the first place.

It may be wrong, but it is really the only thing I know. My knowledge of C and C++ and the code I write can be summed up in two words: Hacked Together.

I failed my college C course, (I dropped out ), but feel I've learned enough to get by. And C++, well, that was "taught" to me by some friends and glances through a book to two, which bored me to tears practically. I can't tell the difference between C and C++ code, and really, I don't care either way.

With security in mind, the less holes in the code, the better.

I just discovered loading functions do not check for a null as filename argument. I was more surprised to see a libc function causing it (strrchr); contrary to a bstrlib, like mentioned here. Won't cause overrun, but it's funny nevertheless.

Use the debug version of the library if you want the extra checks. Once they all pass, switch to the release version for performance.