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

Offline barbudreadmon

  • Administrator
  • *****
  • Posts: 1091
  • Karma: +59/-1
  • Helper
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 Barry Harris

  • dontbeabarry
  • *
  • Posts: 1785
  • Karma: +0/-65535
  • I'm Barry Harris and I like to f*** people over
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.
Account of Barry Harris; the traitor.
Send me an e-mail at barry@fbalpha.com letting me know how big of a piece of sh** I am.

Offline iq_132

  • Administrator
  • *****
  • Posts: 3728
  • Karma: +411/-0
  • Definitely not Dink!
    • 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

  • Administrator
  • *****
  • Posts: 1091
  • Karma: +59/-1
  • Helper
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

  • Administrator
  • *****
  • Posts: 1091
  • Karma: +59/-1
  • Helper
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.

Online dink

  • Administrator
  • *****
  • Posts: 5014
  • Karma: +449/-1
  • pie? I nearly bought one!
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

  • New Member
  • *
  • 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.