[canucker2016]

None of my college CS courses used programming languages that featured FAR pointers.

The above example would cause an infinite loop on Win16's seg:off far memory model, but compiling on Win32 would not cause an infinite loop.

Problem is that far pointers only affect the offset, not the segment. So decrementing a 0 value offset would just wrap around to 0xFFFF and the segment would stay the same, so you're going from mem[0] to mem[65535] not mem[-1].

[jlokier]

My point is the example code has a generic C bug, not depending on FAR, which is why it should be taught in good C courses.

Although the code worked on Win32, and works on most modern C compilers, it's not guaranteed to work on modern C compilers, especially with aggressive optimisation turned on.

[canucker2016]

I'm not disputing your point.

I'm explaining why the infinite loop actually occurs for those who haven't encountered the problem.

The problem would happen for an array whose beginning element starts at offset 0 for a particular segment and an iteration stop condition that uses ">= 0th element" that scans down the array. I used a 64K allocated array to ensure that the array base would match offset 0.

Problem would also occur if the end of the array aligns with the segment limit and the iteration end condition was "<= end element" and the scan moves up the array.

For either situation, the array could be < 64KB. One byte would be sufficient.