Author Topic: Using "char" instead of "signed char" seems bad for portability  (Read 915 times)

Offline barbudreadmon

  • Expert
  • *****
  • Posts: 282
  • Karma: +8/-0
  • lr-fbalpha developer
Using "char" instead of "signed char" seems bad for portability
« on: October 21, 2016, 06:48:22 am »
Is there a reason why you don't use the following typedef defined in burn.h everywhere it applies :
Code: [Select]
typedef unsigned char UINT8;
typedef signed char INT8;
typedef unsigned short UINT16;
typedef signed short INT16;
typedef unsigned int UINT32;
typedef signed int INT32;
typedef signed __int64 INT64;

My main issue is that sometimes, "char" is used as an alias of "signed char", but that's wrong on some platform (on arm, "char" is a "unsigned char"). I think replacing every "char" by "INT8" in fba (if you think it's failsafe ?) could improve portability of fba.

See this post

Offline Treble Winner

  • FBA Dev
  • ******
  • Posts: 1805
  • Karma: +104/-0
  • FB Alpha Team
    • http://www.barryharris.me.uk
Re: Using "char" instead of "signed char" seems bad for portability
« Reply #1 on: October 21, 2016, 08:02:38 am »
Is there a reason why you don't use the following typedef defined in burn.h everywhere it applies :
Code: [Select]
typedef unsigned char UINT8;
typedef signed char INT8;
typedef unsigned short UINT16;
typedef signed short INT16;
typedef unsigned int UINT32;
typedef signed int INT32;
typedef signed __int64 INT64;

My main issue is that sometimes, "char" is used as an alias of "signed char", but that's wrong on some platform (on arm, "char" is a "unsigned char"). I think replacing every "char" by "INT8" in fba (if you think it's failsafe ?) could improve portability of fba.

See this post

Agreed. The whole burn library and cpus, etc. were updated to this a while ago. Newer submissions may need updating though. Feel free to provide patches against the latest release source.

Offline iq_132

  • Administrator
  • *****
  • Posts: 3565
  • Karma: +374/-0
  • Just a lion with a sword
    • NeoSource
Re: Using "char" instead of "signed char" seems bad for portability
« Reply #2 on: October 21, 2016, 12:00:00 pm »
I don't go through large blobs of code that I port and change these. For sure the NEC core bug was my fault :*/.


Offline barbudreadmon

  • Expert
  • *****
  • Posts: 282
  • Karma: +8/-0
  • lr-fbalpha developer
Re: Using "char" instead of "signed char" seems bad for portability
« Reply #3 on: November 02, 2016, 07:16:56 am »
Fixing everything will be hard, because a change in a file call for another change in another file, and i can't really provide one full patch for everything, it would be a pain in the ass for everyone :).

For now i can at least tell you this one is needed (d_cclimber.cpp) :
http://pastebin.com/raw/cXgB6rKE

fba on arm won't build with gcc-6.X without it

Offline barbudreadmon

  • Expert
  • *****
  • Posts: 282
  • Karma: +8/-0
  • lr-fbalpha developer
Re: Using "char" instead of "signed char" seems bad for portability
« Reply #4 on: November 02, 2016, 07:23:33 am »
Also, while fixing this one, i was wondering what's your current standard for twinstick game inputs ? I have seen some game using "p(X+2) <direction>" for second stick, and some other using "pX <direction> 2" (i think the second one is better). I'm interested in having the same standard for all those games, so i could provide you a patch to normalize this.

Offline dink

  • Administrator
  • *****
  • Posts: 2624
  • Karma: +224/-0
  • feed the horse yumyum
Re: Using "char" instead of "signed char" seems bad for portability
« Reply #5 on: November 02, 2016, 07:23:56 pm »
Thanks for the cclimber patch, it's been integrated.

re: dual stick games, I'm with you on the second option as well.

re: sbm, fsoccerb & fsoccerba: marked as unworking for now.

best regards,
- dink

Offline danielt3

  • Newbies
  • *
  • Posts: 1
  • Karma: +0/-0
Re: Using "char" instead of "signed char" seems bad for portability
« Reply #6 on: November 22, 2016, 03:00:14 pm »
Actually it is much better to use the following types: uint8_t, uint32_t, etc. These are readly avaliable from stdint.h in standard C library. I will try to make a patch against 0.2.97.39 sources.