K_CP437 changed to K_UTF8 with the inverted logic. If you have code/script
that can handle UTF-8 input, then you need to specify K_UTF8 in calls to
inkey, getkey, getstr. Or else, you're going to get a CP437 translated
version of any non-ASCII (UNICODE) UTF-8 chars, if there's a mapping
available. This only impacts UTF-8 terminals.

There are just so many places in Synchronet where UTF-8 input could cause
problems, it makes sense to translate UTF-8 to CP437 by default and make
true UNICODE/UTF-8 handling the exception.

Sorry Nightfox, you'll need to remove the K_CP437 detection/use code you
just added to SlyEdit.

This creates a .PHONY target for each file so that if a header is
renamed, the impact will be the files that include it being rebuilt
instead of the previous behaviour where the build would simply fail
and complain that the file doesn't exist.

SlyEdit: Support for entering UTF-8/Unicode characters; using K_CP437 to have Synchronet convert to CP437 internally

See merge request !397

SlyEdit: Support for entering UTF-8/Unicode characters; using K_CP437 to have Synchronet convert to CP437 internally

We don't want CI to die because someone somewhere upgrade a compiler.

NOTE: CI does release builds, which means that -Wall is not enabled.
      WALL=1 could be added if we want that, but it's likely too
      soon to take that step.

pointer to an element.  No way gcc has a clue about what I'm doing
then.

Maybe I'll figure out how to fix it later.

Both long long and long are reasonable for some mixes of platforms.

Just punt, cast the whole thing to int64_t, and forget about it.