C to BlitzMax equivalents

Community Forums/General Help/C to BlitzMax equivalents

Chalky(Posted 2016) [#1]
I am about to try converting a graphics conversion utility written in C to BlitzMax. The C code is not mine (but is declared public domain), and I have never written any C in my life, so it could be an interesting journey. My first task has been to go through the code and see whether I understand any of it. So far so good - although I may well be kidding myself there - only time will tell. What I do need to know, however, is the BlitzMax equivalents of the following:
int   => int
uint  => ????
short => short
char  => byte
uchar => ????

fgetc => ReadByte
fputc => WriteByte

||    => Or (logical OR)

|     => | (bit-wise OR)
&     => & (bit-wise AND)
<<    => Shl
>>    => Shr
My guesses are on the right - are they correct? Please can anyone advise me on those I have marked "????"?


Andy_A(Posted 2016) [#2]
This should do the trick

https://en.wikipedia.org/wiki/C_data_types#Basic_types


Yasha(Posted 2016) [#3]
Firstly, `uint` and `uchar` are not builtin C types. They'll be nonstandard typedefs (a type that has been renamed for more convenient usage) for `unsigned int` and `unsigned char` respectively.


Secondly, while signedness is something you can specify on most integral types in C, in BlitzMax it is fixed: Byte and Short are always unsigned, Int is always signed, no exceptions.

Luckily, on x86 there is relatively little difference between signed and unsigned numbers at the hardware level anyway: if all you want to do is store the value and add, subtract, or perform bitwise ops, the BlitzMax program will behave the same way as the C program (BlitzMax might return that the value is less than zero if asked, but the bits won't change - most uses of unsigned values are friendly to this). Take a look at the code and see if it logically looks like it should care about signedness (e.g. does it ever use `<`), or if it's treating the data as binary blobs.


Thirdly, technically the sizes of int and short are not fixed in C. They're fixed in BlitzMax because BlitzMax is designed directly to a platform, but C is supposed to be portable to all manner of weird architectures with things like 18-bit bytes or whatever, so its basic types are supposed to just do what's simplest for the hardware.

In practice, if your program ran on x86, the naive BlitzMax translation will work. But the original code might have guards on it that you don't see in Blitz code, to try to deal in a stable fashion with the fact that sizes vary from machine to machine. The actual C types corresponding to BlitzMax's types are:
uint8_t  => Byte
uint16_t => Short
int32_t  => Int
int64_t  => Long

Good C code will use these sorts of explicitly-sized number types rather than `int` and so on, when it actually cares about the specific size of the data. (Unfortunately a lot of code isn't disciplined, and there's a lot of `sizeof(int) == sizeof(void*) == 4`-assuming stuff floating around out there.)


Floyd(Posted 2016) [#4]
>>    => Shr

Maybe. BlitzMax has two flavors of right shift. Shr fills with zeroes on the left while Sar fills with copies of the sign bit.

In C the right shift >> fills with zeroes for unsigned and with copies of the sign bit for signed. Well that's probably true. Strictly speaking it's implementation specific so you should try to find out what the original code does. It may not matter, depending on how results are used.


Chalky(Posted 2016) [#5]
Excellent information. I clearly have much to learn - but the process should be fun. Many thanks for everyone's help.