LiveCode Forums.

Wonder why it was done that way originally?

Also is there a reason we can't just include stdint.h other than the fact that we are using an old version of MSVC that doesn't have it? There's a public domain one here for windows if we need it: http://snipplr.com/view/18199/stdinth/

Memory overhead... A malloc'd block typically has between 8-16 bytes of overhead (depending on the system), so if you allocate 3 that 24-48 bytes gone immediately without any space for the data. Also, they are typically rounded up to the nearest 8 or 16 byte boundary size wise. At the time MCPath was written I had envisaged it being used much more than it actually is so it seem prudent to make it efficient.

In terms of using stdint.h the reason it isn't used is because it was never widely enough available at the time for it to be usable. Instead, the appropriate definitions were pulled into typedefs.h (then core.h - libcore was an attempt at a platform uniformization library to help write portable code) and we carried on. Unless there's a significant need to change that now (everything works quite well the way it is) then I'd recommend leaving things as is (at least until after the refactoring project which includes a fair amount of improvement / restructuring to the base-level on which the rest of the engine is coded against).

The other reason I can think of is that it reduces the probability of error leaks if there's only one free() to take care of. But after playing around with the magic numbers in an attempt to figure out the intent of the routine, I decided it was more expedient just to rewrite it.

It was just a case of me perpertrating premature optimization. Originally I had thought MCPath objects might be (a) more frequently used and (b) been around for long periods of time. As it turns out, they only ever ended up being transient, making trying to save a few bytes (at the expense of code clarity) unnecessary

In regards to the 64-bit changes (just to repeat what I said on the pull request) - we aren't going to have time to integrate this for 6.0.1 but can pull it in as a feature branch so more than one person can submit pull requests against it. Thoughts?

Anybody able to help could do so by sending mwieder a pull request I guess... but probably more people will see the feature branch on your repo

Very true...

I'll leave it up to Mr Wieder and see what he wants to do

Yeah, I like the idea of a separate branch. The 64-bit branch is definitely not ready for the 6.0.1 release, so more time to poke at it and more eyes on the source would be useful.

I also didn't add error checking to the MCPath::allocate method - there wasn't any error checking on the malloc in the original, and I'm not sure what error condition would be appropriate at this level. It could possibly fail under low memory conditions and that's bound to have repercussions at some point.

I'm at the point now where I'm tracking down the cause of the graphics effects problem: both the source and destination pointers are getting set to negative values. I've tracked it with gdb now as far back as MCX11Context::getImage and they're still messed up, so it's not just the rendering functions with the problem, they just act on it. If I don't try to use graphic effects then everything seems functional so far (and that probably means I haven't tested enough).

I reverted the parentheses changes.

You mean the ones that cause compiler warnings? && etc Damn... was hoping that would get into the engine. Maybe it should be a separate pull request...

Yes, those.
I messed up the parenthese, so I got rid of the changes. Mark caught my error and I've got other things do do right now instead of fixing them.

fair enough... perhaps a dedicated compiler warning cleanup branch is in order... I've got 79 when I build

I'm not going to deny... The source-code could generally do with a 'warning cleanup' on the various different compilers that are used!

Looks like the 64-bit branch in Mark's repo is going well so perhaps best to leave it there for now... We'll keep an eye on the pull-request and when it seems mature enough we'll look to integrate and start producing 64-bit Linux builds (the latter will require a little bit of work internally to integrate another engine type into the build process!).

I think the "warning cleanup" task should be a separate branch. I'm going to try to keep the 64-bit compile branch clean if possible. It's already got one bug fix in it, but that's the only anomaly at the moment.

Finally got a clean install of XCode 3.2.6 to respond. Now I get 3887 warnings. But it's progress.