I tried it with some of my 1983-vintage code and found a problem: when the mystrcpy macro pre-terminates the new string it writes beyond the end of the allocated buffer.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for giving the assembler a try.
My 6800 source code is not producing any writes beyond allocation.
Could you show some of your lines where this occurs, and describe the output you are getting?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
where the second, duplicated symbols have a surplus character appended. Sometimes printable, sometimes not. And sometimes the assembler crashes without any output. This is on Linux: Fedora 26.
There's only one use of the macro mystrcpy, in strsave. length+1 bytes are allocated for newword and the macro is invoked as:
where the second, duplicated symbols have a surplus character appended.
Sometimes printable, sometimes not. And sometimes the assembler crashes
without any output. This is on Linux: Fedora 26.
There's only one use of the macro mystrcpy, in strsave. length+1 bytes
are allocated for newword and the macro is invoked as:
So the null character is placed beyond the end of allocated memory.
Changing the macro to have dest[len-1] fixes the problem. Though I'd be
inclined to do away with the macro and revert to using strcpy.
Going back over the reasons I wrote that macro, dest[ len - 1 ] was
probably what I intended. Falsely saved by loose libraries.
But I might have been thinking about calling it with strlen() + 2
allocated, instead. Probably failed to make up my mind.
I'm sure no longer the hot dog programmer I used to think I was.
The reason for the macro was that I wanted to purge dangerous and evil
functions from the source, particularly for compiling on openbsd when they
were running a campaign against often misused standard functions. But
looking at it more objectively now, the danger point is the first call to
strlen(), anyway. And strncpy() is maybe even easier to fail to use
correctly.
I may just go back to using my own bounded string routines.
For now, take your pick. The test files can tell you whether it works.
This is very odd. I don't see this behavior on my system -- Debian Wheezy, gcc 4.7.2 as of now.
If you look at, say, fig-forth/fig-forth.list.goal, you should be able to see the results I get.
I hope you'll be patient with me about this, because it would be a big favor if I could ask you to descend into the test-stuff directory and the fig-forth directory and do a make and make test in each of those, preferably with a fresh copy of the source, and tell me what the diffs say.
And I've left this out of the tests in test-stuff/Makefile, but could you take a look at the output of assembling test-stuff/exptest.68c and tell me what you see?
And could you tell me your version of gcc and/or clang?
I do have a reason for that rather odd macro, but it will be easier to explain, and to figure out what I should do with the code once I have an idea what is actually happening there.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
On Fedora 26 I have gcc 7.1.1 and glibc 2.25. It's a 64-bit system.
I've now built and used the assembler on a 32-bit CentOS 6 system with gcc 4.4.7 and glibc 2.12. In this case my source assembled without incident. Clearly it's system-dependent.
On both Fedora and CentOS Valgrind identifies the problem. With my suggested change to the macro Valgrind doesn't report any runtime errors.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for releasing this assembler.
I tried it with some of my 1983-vintage code and found a problem: when the mystrcpy macro pre-terminates the new string it writes beyond the end of the allocated buffer.
Thanks for giving the assembler a try.
My 6800 source code is not producing any writes beyond allocation.
Could you show some of your lines where this occurs, and describe the output you are getting?
Here's a really, really basic source file:
This produces output like:
where the second, duplicated symbols have a surplus character appended. Sometimes printable, sometimes not. And sometimes the assembler crashes without any output. This is on Linux: Fedora 26.
There's only one use of the macro
mystrcpy, instrsave.length+1bytes are allocated fornewwordand the macro is invoked as:which expands to:
So the null character is placed beyond the end of allocated memory.
Changing the macro to have
dest[len-1]fixes the problem. Though I'd be inclined to do away with the macro and revert to usingstrcpy.On the other hand,
2017/08/10 3:53 "Ron Yorston":
Going back over the reasons I wrote that macro, dest[ len - 1 ] was
probably what I intended. Falsely saved by loose libraries.
But I might have been thinking about calling it with strlen() + 2
allocated, instead. Probably failed to make up my mind.
I'm sure no longer the hot dog programmer I used to think I was.
The reason for the macro was that I wanted to purge dangerous and evil
functions from the source, particularly for compiling on openbsd when they
were running a campaign against often misused standard functions. But
looking at it more objectively now, the danger point is the first call to
strlen(), anyway. And strncpy() is maybe even easier to fail to use
correctly.
I may just go back to using my own bounded string routines.
For now, take your pick. The test files can tell you whether it works.
Last edit: Joel Rees 2017-08-10
This is very odd. I don't see this behavior on my system -- Debian Wheezy, gcc 4.7.2 as of now.
If you look at, say, fig-forth/fig-forth.list.goal, you should be able to see the results I get.
I hope you'll be patient with me about this, because it would be a big favor if I could ask you to descend into the test-stuff directory and the fig-forth directory and do a make and make test in each of those, preferably with a fresh copy of the source, and tell me what the diffs say.
And I've left this out of the tests in test-stuff/Makefile, but could you take a look at the output of assembling test-stuff/exptest.68c and tell me what you see?
And could you tell me your version of gcc and/or clang?
I do have a reason for that rather odd macro, but it will be easier to explain, and to figure out what I should do with the code once I have an idea what is actually happening there.
Thanks for looking at this.
On Fedora 26 I have gcc 7.1.1 and glibc 2.25. It's a 64-bit system.
I've now built and used the assembler on a 32-bit CentOS 6 system with gcc 4.4.7 and glibc 2.12. In this case my source assembled without incident. Clearly it's system-dependent.
On both Fedora and CentOS Valgrind identifies the problem. With my suggested change to the macro Valgrind doesn't report any runtime errors.
And likewise.
Sorry I was so slow to take a real look at it. It'll be a few weeks, at
least, before I can push a fix in. Wish I had more time to work on it.
Want to set it up to handle some of the other Motorola 8-bit processors,
but I'd probably do better to rewrite it from scratch.
Okay, I finally got the proper fix for this into the repository.