You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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>intmain(intargc, char**argv) {
chara= (char)127;
charb= (char)127+ (char)1;
if (a>b) {
printf("char is signed char\n");
} else {
printf("char is unsigned char\n");
}
return0;
}
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.
The text was updated successfully, but these errors were encountered:
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.
References:
gcc
andgcc -funsigned-char
:@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.
The text was updated successfully, but these errors were encountered: