Just to be clear, this post is not going to be about the float vs. float comparison. Instead, it will be about trying to compare a floating point value with an integer value in an accurate, precise way. It will also be about why just doing int_value == float_value in some languages (C, C++, PHP, and some other) doesn't give you the result you would expect - a problem which I recently stumbled on when trying to fix a certain library I was using.

Some time ago I was reading a random Python JSON parsing library which was partly implemented in C. At one point I thought I spotted a bug in custom float number parsing - I've written a short PoC to trigger it and it worked (i.e. crashed Python), but behaved differently than I expected it to and seemed to work only on Windows. So I got back to looking at the code and in the end decided it was only my imagination - there was no bug. So… why did that PoC actually work? It turned out that in some cases the library fell back to using the good-old strtod for float parsing instead and yes, there was a bug - in the underlying msvcrt.dll strtod implementation.

Sometimes it's fun to forget about why an Undefined Behavior in C is bad and just write some code that works here & now, but not necessarily will work tomorrow (with a different compiler version or different compiler settings) or in another place (another platform/system/architecture). A few weeks ago I had a chance to do such fun coding due to a thread "Hello world bez bibliotek i asm" (eng: "Hello world without libraries or asm") on a Polish programming forum - the thread creator was asking if it's possible to create a program writing out "Hello World" without using any libraries (including includes) or inline assembly. While at the beginning the thread was still about proper C, it soon moved to low-level code (still written as C) that depended on the underlying system, CPU architecture or even the way the compiler does its job. In this post I present my idea on how to write out "Hello World" to a GNU/Linux console; also it might be worth to take a look at the thread itself (I guess you won't need to know Polish just to look at C code ;>).

I've never given too much thought to the problem of initialization of a local variable with static storage in C++ (and C). I just blindly assumed that the static variable works identically to a global variable, but is directly accessible (using language provided means) only in the block of code (and its child blocks) in which it was declared/defined. This is partly true - the big difference is that the global variable is initialized either at compilation time (constant/zeroed) or before the entry point, and the static variable is initialized either at compilation time (constant/zeroed) or when the execution first reaches it's declaration/definition. The interesting parts here are "how does the variable know if it has been initialized?", "can initialization fail and need to be rerun?", "what about concurrent multi-threading?" (the latter has some minor stability/security consequences). Let's take a look at GCC and Microsoft Visual C++ and how do they handle these issues...

A few years ago I would answer the above question with "because NULL is defined as a void pointer to 0", which is only half correct (and close to being wrong). The answer to this question is much more complicated and thus much more interesting.

I've received the title riddle from furio and I found it interesting enough to pass it during the next few days to everyone that might be even remotely interested in C/C++ problems. The interesting thing here is the Undefined Behavior (UB), well... actually two UBs, thanks to which there are three possible correct answers: 11, 12 and 13.

While discussing a few days ago a piece of code with aps, we've encountered some interesting (imho) differences in the implementation of atoi and [sf]scanf between different versions of msvcrt (Microsoft C-Runtime Library), glibc (GNU C Library) and the libc used on OSX. The said differences are observed when a number in the provided string cannot be represented as an integer, i.e. it's larger than INT_MAX (which is 0x7fffffff, or 2147483647 decimal) or smaller than INT_MIN (0x80000000, -2147483648 decimal).

Recently I'm working on some C++ code that (ab)uses many language features in a deep way, and hence, I found it necessary to do some digging to check if a given behavior is a result of standard fulfillment (i.e. it's defined in the language standard), defined compiler behavior (i.e. it's defined in the compiler (GCC in this case) documentation, but not necessarily in the language standard) or it's totally UB (i.e. it's not defined in any official documentation and cannot be relied on in any other version or compiler). So, this post is basically a data dump about some feature (preprocessor macro resolving to be exact) and probably seasoned programmers can skip it.

Well, this was supposed to be another "Random" post, but as the typing went on, it grew quite long, so I've decided to post this as a normal post. So, today's post will be about some new (i.e. new for me) extensions in GCC I've dig up, and a random rant on what I still miss in C/C++ (and no, I don't have templates of templates of templates in mind ;f).

As promised, It's time to reveal the technical story behind the Syndicate Wars Port. The story is divided into two parts - the first, and the second attempt to port this game. Comments are welcomed!

Syndicate Wars is a game published in 1996, created by Bullfrog. The game was written in C (Watcom) for the DOS4GW DOS extender. And of course it has stopped working natively (i.e. without emulators like DOSBox) when the modern operating systems, like GNU/Linux or Windows NT series, emerged. A few years ago my friend, Unavowed, told me about proposition of a project to create a port of Sydicate Word for modern OS'es like the two previous one I've mentioned. The port was to be done by decompiling the original executable file, locating all the functions from the standard C library, locating the DOS4GW and I/O (sound, keyboard, gfx, mouse, etc) dependencies, replacing them with modern native libc function call and libSDL/OpenAL libraries (sometimes using simple wrappers, other times by creating converters), and finally, recompiling it all to form native executables for the modern systems. Yesterday, we've (it was Unavowed who was the clear leader of this project) finished this project, and we've published executables, not only for GNU/Linux and Windows, but also for Mac OSX :)

Today I'll write about an interesting mistake (or misinterpretation in this case) I've spoted in my friends code, and also I'll mention a certain link I found in the referers. I'll start with the link...

For some random reasons my blog became quiet recently, but don't worry, it's only temporary. It's time to catch up, and write about this and that.

Two days ago j00ru informed me that my cmd.exe add-on (the one that adds the ultra important feature - colors!) does not work on Windows 7 RC - so I decided to have a look, and so version 0.004d came into being!

Long, long time ago, in the DOS times that is, one could configure the command prompt to be colorful, one could echo colorful messages, etc. And one could do all that thanks to the ANSI escape codes - short commands echoed to the "screen" (stdout/stderr that is) that caused the colors to change, the cursor to move, or the screen to be cleaned. ANSI escape code well working quite well in DOS, and they even worked in Windows 95/98. However, with the arrival of the NT family, the ANSI support in the console ceased to exist (well, it was still available in the command.com interpreter, but it's 16-bit running under NTVDM, what makes it not the best choice, not to mention that the NTVDM is not available in the 64-bit Windows versions). (A short offtopic: on *nix systems ANSI escape code well available almost always, and they are still available today).

Recently I've talked with my teammate oshogbo about the format bug (aka format string attack), and when we got to testing a sample code, a thing that should work - the %n tag, didn't work at all. What's more interesting, this behavior was Vista specific, since everything else worked well on XP. I've decided to take a look inside, and here's what I've found out...

Todays post will be an out of order one, and it will be dedicated to the function gettimeofday on the Windows system, or to be precise, the lack of this function.

Inspired by noglorps post on OpenRCE I've finally decided to play with Windows fibers, and I found out that it's quite an interesting topic.

Recently I was creating in C++ (MinGW g++) a small library for runtime-patching. A need came to create an assembler-only functions, without any additions from the compiler - a "naked" function. However, even if compilers from Redmond support __declspec(naked) attribute for the x86 [Visual C++ Language Reference - naked (C++)], GNU compilers don't - they only support "naked" in ports for ARM, AVR, IP2K and SPU [Using the GNU Compiler Collection (For GCC version 4.3.0) - Function Attributes]. The problem had several possible solutions: