TODO: test compatibility with the new code
- test on an uninitialized (not zeroed tape)
- 8 bit cells
- overflow of the tape or the cells forbidden (with warning output)
=> make something like selftest.bfx which calls all possible stuff, so you can test if everything internally works correctly (TESTCASE)

---------------------------------

Compatibility problems regarding to cell OVERflows -> safe addition

With an 8 bit interpreter, this loop will never end

	for xx=1:3 {
		for yy=1:255 {
			// yy will go from 1 to 255, but xx will always stay at 1 !!!!
			printd xx; prints "/"; printd yy; prints "\n";
		}
	}

This loop will exit normally:

	for xx=1:3 {
		for yy=1:254 {
			printd xx; prints "/"; printd yy; prints "\n";
		}
	}

=> THERE ARE VALUE OVERFLOWS at stopFor():
    addTo(var, step); // TODO: value overflow -> for loop will never end
    assign(flag, le(var, stop));
=> see my new patch which will fix this issue

A "safe" addition method is necessary. addTo() is called from:
- addToElement => WONTFIX
- add => WONTFIX: the user expects overflowing, otherwise (255+1)-1 != 255
- multiply => UNKNOWN if causing overflows
- logicOr => UNKNOWN if causing overflows
- stopFor => FIXED with the patch of Daniel Marschall. Without the fix, "for i=0:255" would never end
- printd => UNKNOWN if causing overflows

---------------------------------

Bugreport (mail 02.06.2013): CODE COMPATIBILITY (8 bit cells, normal overflow/underflow behavior)

BFX generated BF code is not portable because "-" asserts that a cell value may never become below 0.
Also, some internal calculation values require that the cell is larger than 8 bit.

Probably unsafe calls of "-":
1. lt() and gt()
    d_out << "-";
              ^
   => FIXED: both fixed by using safeDecr()
2. subtractFrom()
    d_out << "-";
              ^
   this function is called by following operations:
	a) subtract (1 call)
	   => WONTFIX: SHOULD NOT BE SAFEDECR, otherwise (0-1)+1=1
	b) Joren's division (3 calls)
	   => FIXED: converted into safeDecr (2 calls) in Daniel's implementation
	c) Joren's modulo (1 call)
	   => FIXED: converted into safeDecr (2 calls) in Daniel's implementation
	d) eq (1 call)
	   => **UNKNOWN** if there are incompatibilities
	e) not (1 call) 
	   => **UNKNOWN** if there are incompatibilities
3. assignToElement()
    d_out << "[>>[->+<]<[->+<]<[->+<]>-]";
                                      ^
    d_out << "[[-<+>]<-]<";
                      ^
   => **UNKNOWN** I don't know if these calls are safe or not
4. arrayValue()
    d_out << "[>[->+<]<[->+<]>-]";
                              ^
    d_out << "[<[-<+>]>[-<+>]<-]<";
                              ^
   => **UNKNOWN** I don't know if these calls are safe or not

Functions which are 8-bit incompatible
- Joren's implementation of divideBy() => FIXED with a new algorithm by Daniel
- (Unknown if there are more)

---------------------------------

Please remove the "magic number" 48 from printd() and replace it with '0'
- setValue(48);
+ setValue('0');

---------------------------------

Memory cell swapping

- Instead of assign(idx1, tmp) there should be more switching of memory cells during compilation time
- For example, all "By"-functions (addTo, multiplyBy, moduloBy, subtractFrom, divisionBy) should return only void.

Please change the return value from int to void for following functions and remove the "return" statements of the functions (They are not necessary anymore):
- assign
- assignFromPointer
- printc
- printd
- prints
- scan
- addTo
- subtractFrom
- multiplyBy
- divideBy
- moduloBy

---------------------------------

8-Bit Problem

Please implement my divmod algorithm => much shorter BF code + 8 bit compatibility

---------------------------------

Errors in the manual

Chapter 1:
	-ptr;   => --ptr;
	-*ptr;  => --*ptr;

Change manual for all 0.50 changes (especially changed behavior and algorithms like division and safeDecr)

---------------------------------

Bugreport (mail 02.06.2013)

The following code will crash bfx during compilation:
-> Can only reproduce on a Win64 with mingw32 4.7.2 (UMA)

function main() {
	scan e;
	prints e;
	printd e; // crash
}

---------------------------------

Bugreport (mail 02.06.2013)

"Syntax errors" appear if there are unbalanced brackets inside COMMENTS or STRINGS.

---------------------------------

FIXED: "scan e; prints e;" segfault -> not a string

---------------------------------

Improvement suggestions

(Mail 31.05.2013 10:33)
1. global variables
   global/local CONSTANTS (replaced during pre-compilation time)
   local scope vars/consts (only visible inside super-blocks, useful for garbage collection)
2. inline __bf() and maybe also [not in mail:] __movePtr()
   -> for comments or inline bf code
   -> > and < need to be balanced inside each bracket. OK: [><], NOT OK: [>]<
3. Syntax error - make output more verbose
4. trim lines to max 72 chars
5. switch, while, do-while, repeat-until loops --> replace with IF statements => pre-compilation
6. infinite loop => for i=0:0:1

(Mail 31.05.2013 17:22)
7. Underscores (_) are not allowed as variables or function names.

---------------------------------

In case on an syntax error:
- return an errorlevel, so post-compilation processes can be aborted in an batch script
- don't create an incomplete *.bf file! instead, delete the existing one!

---------------------------------

Bug? No, valid C behavior.
top = 0 || 1;
printd top; // 000
prints "\n";
top = (0 || 1);
printd top; // 001
prints "\n";

---------------------------------

maybe adding an Windows/Delphi IDE and an BF interpreter to the package (since gcc can't compile large bfx generated code -> out of memory, even when -O0)
- kate XML
- nanorc

---------------------------------

I don't know if this is a bug or an expected behavior (but it seems to be a nice feature):
function x = change1(x) { /* do nothing to the output parameter. it should be left to zero, but somehow it "magically" gets copied from the input parameter with the same name. */ };
function y = change2(x) { /* do nothing to the output parameter. it is left to zero. */ };
function main() {
	x = change1(42);
	printd x; // 042
	x = change2(42);
	printd x; // 000
}

---------------------------------

printd should not print anything larger than 999, instead of printing stuff like "D00"

---------------------------------

bf2c:
- "scanf" ist böse, da es nur zahlen einliest. lieber ascii eingabe.
- "scanf" fehler: wenn man z.B. "x" eintippt, dann wird jede zukünftige scanf abfrage durchgelassen
- besser eine direkteingabe ohne "enter" drücken zu müssen.

---------------------------------

Please change following in bf2c.c

"Public version" with the standard BF behavior:

        while ((c = getc(in)) != EOF) {
        switch (c) {
            ...
//          case '-': fprintf(out, "\t\tif (*ptr) --*ptr;\n"); break;
            case '-': fprintf(out, "\t\t--*ptr;\n"); break;
            ...

"Debug version" which will show us if there are further decrease assertion errors:

        int e=0;
        while ((c = getc(in)) != EOF) {
        e++;
        switch (c) {
            ...
//          case '-': fprintf(out, "\t\tif (*ptr) --*ptr;\n"); break;
            case '-': fprintf(out, "\t\tif (*ptr) { --*ptr; } else { printf(\"DECREASE ERROR at %d\\n\"); }\n", e); break;
            ...

---------------------------------

QUE: 20-1 = 19 ? precompiler?
(k) Wodurch entsteht [-][-] ?
3rd party: ascii art vorlage transformer als post-compilation
ist es notwendig, dass getTemp() immer setValue(0) aufruft? ggf optimierungsbedarf bei werten wo es nicht notwendig ist.
einrückung von bf2c.c output