Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

signedness of char #23

Open
cpressey opened this issue Oct 4, 2018 · 2 comments
Open

signedness of char #23

cpressey opened this issue Oct 4, 2018 · 2 comments

Comments

@cpressey
Copy link
Member

cpressey commented Oct 4, 2018

References:

  • Befunge-93 cells were not unsigned, contrary to what the Funge-98 specification states.
  • Several examples that don't appear to work are due to the fact that they assume the interpreter uses unsigned char for playfield cells.
  • When I audited compilability I should have checked what char signedness each of those compilers assumes. I plan to do that as part of this issue, using this program, which appears to do the right thing with gcc and gcc -funsigned-char:
#include <stdio.h>

int main(int argc, char **argv) {
    char a = (char)127;
    char b = (char)127 + (char)1;
    if (a > b) {
        printf("char is signed char\n");
    } else {
        printf("char is unsigned char\n");
    }
    return 0;
}

@j4james If you could check the version of MSVC you used with this too, that would be lovely.

As for what to do about it: I don't plan to do anything officially - at the end of the day, signedness of playfield cells in Befunge-93 is just as undefined as signedness of char in C. It's not a great situation for real software engineering, but this isn't real software engineering (cockamamie is our watchword!) and it's been like this for 25 years so why switch horses now?

In practice, if you have a Befunge-93 program that relies on it, you can test it just like the C program tests it (use ` and branch - in fact I think I'll write a Befunge-93 example program that does just that, to demonstrate). Granted, that uses up precious playfield space, so you can just document that it relies on it instead.

In essence there are two minor variations of the language, "Befunge-93 with signed playfield cells" and "Befunge-93 with unsigned playfield cells", which co-exist. Some programs are polyglots that run the same in either variant. Some aren't.

But I would like to do more research on it, and possibly document it somehow, because if there is a distinct bias towards a particular signedness out in the wild (catseye/Funge-98#2 argues the bias is towards signed), it won't hurt to raise attention to it as a potential de facto standard. This will also help contextualize what some example programs do / are supposed to do, in #20.

@cpressey
Copy link
Member Author

cpressey commented Oct 4, 2018

Here are my results so far.

Compiler Default signedness Compiler option to change default signedness
gcc 5.4.0 (Ubuntu 16.04) signed -funsigned-char
gcc 4.5.3 (NetBSD 6.1.5) signed -funsigned-char
DICE C 3.15 (AmigaDOS 1.3) signed not possible(?)
DJGPP 2.05 gcc 8.1.0 (FreeDOS 1.1) signed -funsigned-char
Borland C++ v3.1 (FreeDOS 1.1) signed -K
Microsoft Visual C++ 14.15 signed(?) /J(?) (guesses based on this article)
Metrowerks CodeWarrior (MacOS) signed Use Unsigned Chars (see page CL-52)

@j4james
Copy link

j4james commented Oct 4, 2018

I can confirm that MSVC is signed by default, and /J or -J enables the unsigned option.

For Befunge programmers concerned about portability, it's worth noting that there actually quite a lot of variations. It's not just signed vs unsigned - the size can also vary between 8 bit, 16 bit and 32 bit. If I want to be portable I find it's often easiest to assume 7 bit unsigned is all I have to work with.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants