Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Inconsistency in EOLs in generated files #42

Open
jhusak opened this issue Jul 12, 2024 · 5 comments
Open

Inconsistency in EOLs in generated files #42

jhusak opened this issue Jul 12, 2024 · 5 comments
Labels
bug Something isn't working

Comments

@jhusak
Copy link
Collaborator

jhusak commented Jul 12, 2024

Example test.asm:

        org $2000
main    nop
@       nop

assemble mads test.asm -hc

The result is:

#ifndef _TEST_ASM_H_
#define _TEST_ASM_H_^M

#define TEST_MAIN 0x2000
#define TEST_0@ 0x2001
^M
#endif

where ^M is 0xD additional ascii code (some are 0xa and some 0xd0xa)

@jhusak jhusak added invalid This doesn't seem right bug Something isn't working and removed invalid This doesn't seem right labels Jul 12, 2024
@laoo
Copy link

laoo commented Jul 13, 2024

@jhusak It seems to be a duplicate of #41
Please try newest version from sources

@jhusak
Copy link
Collaborator Author

jhusak commented Jul 16, 2024

Have you checked? Not a duplicate, but I have used the same example. There are many places in code with use #13#10 sequences. They are to be converted to LineEnding and the message printing system has to be simplified. I can do this, but it is rather major change, also in load_mes, so I wanted to discuss it with @tebe6502.

The proposition is to throw away mess array and do an array of string constants. Then put LineEnding everywhere instead #13#10 strings. Then files and messages generated (their format) will be system-dependent. On Unices it will be #10, On Windows #13#10, as expected.

BTW. I always use newest sources before raising issues.

@laoo
Copy link

laoo commented Jul 17, 2024

@jhusak Indeed it's a different problem. But you forgot to mention the OS on which you have the result. I've checked it and on the Windows in every line there is 0xd0xa. So I assume the first and last empty line are added as arbitrary new-line and other lines are printed in a loop in a system dependent manner. This should bring @tebe6502 closer to a solution.

BTW. You could not check it on the then newest sources as #41 has been fixed on the spot on party place (where were you? ;) )

@jhusak
Copy link
Collaborator Author

jhusak commented Jul 17, 2024

For me newest sources are on the master branch in github. Everything newer is in tests :) I did not mentioned the system, because it is obvious: not CRLF system (so not windows nor DOS).

As I said (wrote), the solution is to change the messages from byte array to array of strings. Then the compiler (well, the programmer, but compiler will allow to do this) can add LineEnding constant, which is dependent on the system. Then fix the hardcoded values in the code elsewhere. It is one-hour work, but I have to be blessed by @tebe6502 :)
I do not want to lose one hour of work of my life if he says "no" :)

@tebe6502
Copy link
Owner

tebe6502 commented Aug 1, 2024

fixed, #13#10 replaced by LineEnding

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants