|
Post by turboxray on Oct 27, 2019 3:26:15 GMT
So I downloaded the 3.99 build from the resources link here and tried to compile it under OSX 10.14. I had to add the following args to the "darwin" to get it to compile: CFLAGS += -Wno-parentheses-equality -Wno-uninitialized -Wno-empty-body -Wno-format-security And had to modify line in expr.c that was casting a long to NULL_TAG for a pointer inside a struct. I removed the casting. It compiled after that, so I compiled the example files included with the source. All compiled fine except "designer". I get an "Abort trap: 6" error. Also noticed there's a test case setup and ran that as well. Quite a bit failed (also got that error message on one of them). Just to be sure, all those test cases are supposed to pass right? Haha. Not a 'work in progress' thing? I was going to try and compile it with with valgrind cause I read that it's usually a memory out of bounds error... but apparently it's not compatible with osx 10.14 still Any suggestions before I start taking design.c example code apart?
|
|
|
Post by elmer on Oct 27, 2019 6:18:40 GMT
The HuC source is based on Ron Cain's 1980s code ... 64-bit pointers and 64-bit "long" types just weren't around then. There are a lot of things that store pointers in variables of type "long", and other joyous old-skool pre-ANSI-C code from before people used "unions" or other slightly more modern type-safe coding practices. Compiled != Working, especially when you start ignoring warnings that the compiler specifically spits out to point out problems. I believe that it just-about-works on 64-bit Linux, but it sure won't compile properly on 64-bit Windows. It's a PITA that the latest OSX completely dropped support for 32-bit apps ... but I do understand the reasons. Anyway, congratulations on getting it to actually compile on 64-bit OSX (presumably with clang) ... debugging it is now up to you! You should really look at all of the warnings, and then decide if you want to try to fix things ... the amount of work to do that on Windows is kinda offputting ... it's going to require some serious refactoring. P.S. Yes, the last time that I ran the tests (on a 32-bit compile), they all passed.
|
|
|
Post by turboxray on Oct 27, 2019 19:23:10 GMT
Hmm okay. Well, the part in design.c is a const array "piano_freqs_bw" with macros inside it. I traced it down to the preprocessor().. namely cpp(). The variables names are horrible and there's little comments in the code haha. Also, I've never see that much use of globals before . Lexer logic is pretty crazy to follow along. Probably would have made things easier to follow if the lexer was done as a first pass (tokenize everything) instead of trying to do both lexer and parser at the same time (walking the dog on a leash approach). LLDB says it's a buffer out of bounds issue, which was what I suspected. I'll keep digging away at it haha. Updated: I downloaded Code Blocks because I wanted to use a GUI debugger, and I compiled with clang option. And that build runs just fine with design.c. Interesting.
|
|
|
Post by elmer on Oct 27, 2019 20:49:51 GMT
Updated: I downloaded Code Blocks because I wanted to use a GUI debugger, and I compiled with clang option. And that build runs just fine with design.c. Interesting. That is interesting! I checked, and OSX is supposed to follow the "LP64" model, where a long is 64-bits, and so the same size as a pointer ... which means that the code should compile and work, just as it does on 64-bit linux platforms. IIRC, Uli's HuC test suite actually does all pass when HuC is built with GCC on linux. It's only Windows, with its "LLP64" model, where a long is still 32-bits, where the HuC source code falls down badly.
|
|
|
Post by dshadoff on Oct 27, 2019 21:02:36 GMT
...And people complain that HuC doesn't conform to "standard" 'C' (as though such a thing is a clearly-defined concept).
|
|
|
Post by elmer on Oct 27, 2019 21:50:19 GMT
...And people complain that HuC doesn't conform to "standard" 'C' (as though such a thing is a clearly-defined concept). C'mon Dave, there are so many exciting C standards to choose from ... K&R C, C89 (aka ANSI-C), C99, C11, and most-recently C18! Heck, it wasn't until C99 that you could be *guaranteed* that you could convert a pointer to/from a specific integer type (with the addition of the intptr_t type). That's what make C such a fun language to program in!
|
|
|
Post by dshadoff on Oct 27, 2019 23:05:41 GMT
BTW elmer, not sure if you noticed it... but I logged an issue in your huc GitHub repository... it's actually a fix for an issue I found in '_load_font' in the support library while programming recently. It's been there since the beginning, so maybe I'm the only one who ever tripped on it.
...Just FYI, in case you're in there fixing something else anytime soon.
|
|
|
Post by Arkhan on Oct 28, 2019 6:25:38 GMT
BTW elmer, not sure if you noticed it... but I logged an issue in your huc GitHub repository... it's actually a fix for an issue I found in '_load_font' in the support library while programming recently. It's been there since the beginning, so maybe I'm the only one who ever tripped on it. ...Just FYI, in case you're in there fixing something else anytime soon. can you share this issue for people who aren't using that HuC, or participating in it's development..? If it exists in other HuCs, it's worth mentioning I think.
|
|
|
Post by elmer on Oct 28, 2019 7:32:15 GMT
can you share this issue for people who aren't using that HuC, or participating in it's development..? If it exists in other HuCs, it's worth mentioning I think. It's not exactly hidden ... github.com/jbrandwood/huc/issues/3And Dave isn't actively participating in the continued developemnt of HuC AFAIK. I believe that he's still using HuC 3.21, just like you are. He just came across a bug in HuC 3.21, and was then kind enough to check if it was still in the newer version, and report it. You do realize, don't you, that Uli reported fixing more-than-70 other bugs in the old HuC while he was making his changes?
|
|
|
Post by turboxray on Oct 29, 2019 5:30:27 GMT
Okay, I found the problem. Line # 556 of preproc.c; "strncat(args[argc], &c, 1)". The error from the lldb says source destination overlap. Looked it up, and strncat was undefined behavior if source and destination overlap.
Edit: So I printed out the addresses, and while they don't exactly overlap, args[argc] is +1 offset of &c. Even though the arg is 1 character, internally strncat must increment into args[argc] space.. and whatever monitor kicks out the overlap exception. Copying c to a two char array and using that fixes the issue. So it's weird edge case that they were assigned an address just 1 byte apart.
|
|
|
Post by elmer on Oct 29, 2019 7:19:42 GMT
Okay, I found the problem. Line # 556 of preproc.c; "strncat(args[argc], &c, 1)". The error from the lldb says source destination overlap. Looked it up, and strncat was undefined behavior if source and destination overlap. Edit: So I printed out the addresses, and while they don't exactly overlap, args[argc] is +1 offset of &c. Even though the arg is 1 character, internally strncat must increment into args[argc] space.. and whatever monitor kicks out the overlap exception. Copying c to a two char array and using that fixes the issue. So it's weird edge case that they were assigned an address just 1 byte apart. Tom ... well done for finding the problem, but IMHO you've completely missed the real coding problem in what you're seeing reported. Uli, or whoever wrote that abomination, is using strncat() to add the string at c onto the end of the string at args[argc]. The problem is that both args[argc] and c are local variables on the stack, and that c isn't a fraking string at all, it's just a single char. A string implies an array of char with a terminating zero ... and there is no room for a terminating zero in a single-char variable space on the stack ... it runs into the variable that was allocated next on the stack. That's why there is an error, the operation is undefined because in reality, the strings do overlap, even though you'd believe that in most practical implementations of the strncat() library function, especially when given a max-length of "1", that it wouldn't actually matter.
|
|
|
Post by turboxray on Oct 29, 2019 7:34:38 GMT
I mean yeah, I would've never used a char for something that's supposed to be char *, but I figured 1); the length was 1, and 2) more experienced C coders wrote it so they must have known what they were doing haha. Like I said, what they tried to do just happens to work when I compile it with CB w/clang only because the address differences are greater than 1. Using the make environment, c+1 becomes the start of args[argc]. Even though it doesn't write another (with the updated address of the source), it must internally do a prefetch or something to trigger overlap warning. But yeah, quite a few weird things in the source haha.
There's an official repository to submit fixes to?
|
|
|
Post by elmer on Oct 30, 2019 5:30:36 GMT
There's an official repository to submit fixes to? If you go to my site on github (which is presumably where you got the latest source code), then you can click straight back from there to Artemio Urbina's fork (that I started from), and then back to Uli's original repository. As to who is "official" ... well Uli retired from updating HuC quite a while ago, so Artemio took over. And then when Artemio stopped making changes, I effectively took over ... but nothing is "official". Things were complicated a bit last year when Uli finally accepted a years-old merger request from Artemio, which made his version look sort-of-active again ... but my fork is the only one that is currently "actively" fixing and sometimes-improving things in the code. Anyway ... if you get the latest source code from my github, there's a good chance that it will compile on MacOSX for you. I fixed the problems with using clang to compile HuC, they had been reported ages ago by a FreeBSD user, but I'd never gotten around to checking in my fixes to the underlying problems (rather than just turning off the warnings). Anyway, HuC now builds with clang on the latest 64-bit FreeBSD, and all of the tests in the testsuite pass. 2) more experienced C coders wrote it so they must have known what they were doing haha. Oh, you don't want to trust us old-farts, we can barely figure out where we put the car-keys!
|
|
|
Post by Arkhan on Oct 30, 2019 22:34:40 GMT
You do realize, don't you, that Uli reported fixing more-than-70 other bugs in the old HuC while he was making his changes? No...because I don't pay attention to any of the shit going on in Github/lab/wherever, and don't use any of the stuff mentioned there, because it caused problems trying to build my last project. Hence me asking for a mention, for those of us that don't actively participate in the ongoing development. As I literally stated in my post. You could've just linked it without any of the other cuntery in your reply.
|
|
|
Post by turboxray on Oct 30, 2019 22:43:05 GMT
Anyway ... if you get the latest source code from my github, there's a good chance that it will compile on MacOSX for you. I fixed the problems with using clang to compile HuC, they had been reported ages ago by a FreeBSD user, but I'd never gotten around to checking in my fixes to the underlying problems (rather than just turning off the warnings) Hey! Those are literally the changes I made too haha.
|
|