Hi, new user here, not a bot.
GoAsm is sensitive to the type of line endings in a source file? Using Unix style EOL causes GoAsm to fail :(
Hi blakkkrabbit
Welcome to the forum!
Yes you are right - GoAsm expects line ends to be indicated by a carriage return character (0Dh), and line feeds (0Ah) are ignored.
Thanks for the reply, that explains a lot. Is there any chance of either being accepted in a future version or would it break something? Not having to worry about the input format would be nice (for work reasons my editor defaults to Unix/UTF8 no BOM)
Hi blakkkrabbit
I'm afraid it would be a nightmare to change GoAsm to support linefeed-only EOLs.
GoAsm does accept UTF8 files (and UTF16 for that matter), but it does require a BOM as mentioned in the help files.
If you are stuck with using an editor which uses Unix type EOLs maybe your best bet is to create a batch file which runs a converter first to create a new file based on your source but with nice DOS-type CR/LF end of lines. Then let GoAsm assemble the new file so created instead of your original source. The line numbers in any error messages should be correct too.
There appear to be several converters available as freeware if you search for "Unix EOL" or the like.
Hi Jorgon,
No worries, Notepad++ handles various combinations of Dos/Unix/Mac EOL and UTF variants - the main issue for me is remebering to switch before assembling :bg
it would be a simple little project to make a silent "inline" program that creates a file in the TEMP folder or something
you could even have it set a temporary environment variable to the path\filename for the assembly batch
Here is a little converter. It expects file ending *.asu and writes *.asm