Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Saiko Kila]

Maybe this is a know bug (though I couldn't find it), but even if so it is funny. I find that memorial engraving is finicky in comparison to some older versions of DF, because it has much less targets, and some obvious targets don't show up on the list.

But recently I got reversal of the situation. My stonecrafters started to engrave slabs for their new colleagues, guys who came with the king. Even a liaison got her memorial slab. I intend to install it in her room, as a memento mori. For some reason only three legendary soldiers and the liaison got the slabs, but it's better than nothing.

The liaison's slab reads "Outpost Liaison of Salves of Chancing 250 to -1". It may be worth noticing that the current year is 255. So it seems value 255 is treated as signed char, hence -1. But I prefer to believe that my dwarves are practical jokers, and just want to make some cheap laughs at the expense of newcomers.

[BoredVirulence]

That's one young liaison...

I'm not particularly familiar with the difference between unsigned and signed char, but I can't see why 0xFF would represent -1 rather than, say, -127, when it would represent 255 when unsigned. I would rather see -1 as a potential error thrown. Totally right, 0xFF in a signed char is -1, I'll have to review the actual encoding. Returning special values as an error code is common in C and C++, and throwing exceptions fairly uncommon.

Spoiler: Rant on exceptions, and error handling. (click to show/hide)

Personally, aside from the performance loss associated with exceptions, the philosophy bothers me. It regularly requires the caller of a function to handle the exception when it usually should be handled by the function itself. The function could handle the exception, but that makes it difficult to pass back a failure. I sometimes like to return structs as a complex data type that indicates the actual returned value, and if it was successful. There are other methods, such as passing a pointer to modify and returning a bool, or doing the opposite, and having a class have status flags. But its not difficult to define a few structs that have any status flags, and whatever primitive data field you need, because error codes are ugly, except where you can return signed variables but only expect unsigned values and don't need the full storage of unsigned variables.

Although I'm assuming -1 indicates an error that wasn't properly caught, I do find it difficult to consider the year 255 as coincidence. Maybe it has to do with it.
Edit: It could still be an error code, but I doubt it. It would be a funny coincidence if a value of 255 is supposed to return -1 as an error code when it could also be a signed char to int conversion.

This probably belongs on the bug tracker somewhere. I'm assuming year shouldn't be cast into a signed char, and its definitely a bug.

[Quietust]

Years in DF are stored as 32-bit integers, not 8-bit, and the number -1 is explicitly used to denote a lack of meaningful value - an event which happens in the year -1 happened "before time began", and a death year of -1 just means it hasn't died yet.

The fact that you saw -1 at the year 255 was a complete and total coincidence and has nothing to do with 8-bit integer size.

[Saiko Kila]

Yes, I know years are stored in 32-bit integers, and I had slabs with much higher years than 255 (in older versions), but I thought it not impossible to be a bug, like wrong casting somewhere. Since the slab engraving code is different to what it was, there was possibility to introduce some new bugs. I also thought it possible it may be a mere coincidence, sure. I had a child which was born in future in the same fort, I named it "NegaChild" because of that, but it had nothing to do with year 255.