fixed return values for ti_(Rewind/Tell/GetSize) and fixed ftell

[ZERICO2005]

Fixes the issues outlined in #634

int ti_Rewind returns -1 or EOF on failure.
ti_Tell and ti_GetSize return (uint16_t)-1 or 65535 on failure, which is larger than OS_VAR_MAX_SIZE or 65512.

ftell calls ti_Tell, so I made sure that it will return -1L when an error occurs.

[ZERICO2005]

as pointed out by calc84maniac, ti_SetGCBehavior had no bugs to begin with. I will also put the other optimizations in a separate PR

[ZERICO2005]

Fixed a bug in int ti_SetArchiveStatus(bool archive, uint8_t handle), which tested archive != 0 instead of archive & 0x1.

[mateoconlechuga]

Fixed a bug in int ti_SetArchiveStatus(bool archive, uint8_t handle), which tested archive != 0 instead of archive & 0x1.

Not a bug. Don't do this.

[ZERICO2005]

Fixed a bug in int ti_SetArchiveStatus(bool archive, uint8_t handle), which tested archive != 0 instead of archive & 0x1.

Not a bug. Don't do this.

We would only test archive != 0 if we were calling int ti_SetArchiveStatus(uint8_t archive, uint8_t handle)

Under the C calling convention, bool is true if the LSB is set, and false if the LSB is cleared. So 2, -2 and 86 would all be considered false.

If we have func(bool), and try to pass in func(value), the compiler would emit the equivalent of func((value != 0) ? true : false).

[mateoconlechuga]

No. I don't freaking care what the complier does, the libraries are not "tied to the compiler". There are countless programs out there that use ICE, old ZDS complier code, etc that are not the current compiler that you just so happen to define. We are not breaking backwards compatibility for a frivolous check.

[ZERICO2005]

gotcha, will undo then

[ZERICO2005]

should we change the prototype to uint8_t, so the compiler is aware that we are testing archive != 0 instead of archive & 1?

[mateoconlechuga]

Sure that seems fine

[ZERICO2005]

The prototype has now been changed:

int ti_SetArchiveStatus(bool archive, uint8_t handle);
int ti_SetArchiveStatus(uint8_t archive, uint8_t handle);

However, this means that ti_SetArchiveStatus(256, handle) would be treated as false, so I also added a macro to fix this issue.

#define ti_SetArchiveStatus(archive, handle) \
ti_SetArchiveStatus((bool)(archive), (handle))

I also duplicated the documentation for ti_SetArchiveStatus to the macro

[ZERICO2005]

ti_AllocString and ti_AllocEqu didn't check if the allocation routine returned NULL, which has now been fixed.