Welcome, Guest. Please login or register.

Author Topic: Counting on AllocVec's size memo..  (Read 13625 times)

Description:

0 Members and 1 Guest are viewing this topic.

Offline tboeckel

  • Newbie
  • *
  • Join Date: Jun 2006
  • Posts: 9
    • Show all replies
Re: Counting on AllocVec's size memo..
« on: December 22, 2006, 02:50:11 PM »
OS4 didn't break it!!

Please, *NEVER* rely on such "facts" that hold for OS2/3 or MOS just by pure luck.

It was never documented that AllocVec() stores the size of the allocation at a specific position or at all.

OS4's memory system doesn't need to store the allocation size at all, because its internal structures already cover the size information. Hence it is illegal to peek at ptr-4.

If your application *really* needs to know the size of an arbitrary allocation, then write your own wrapper functions to AllocMem()/FreeMem() and store the allocation size yourself. That will save you *very* much trouble in the future.
 

Offline tboeckel

  • Newbie
  • *
  • Join Date: Jun 2006
  • Posts: 9
    • Show all replies
Re: Counting on AllocVec's size memo..
« Reply #1 on: December 22, 2006, 04:36:46 PM »
How can you break something that was never documented? Peeking unallocated memory region was very common practice on 68k system, but will surely crash with OS4. So, does OS4 break this, too?

Ok, the location of AllocVec()'s size storage has become something like a "fact". But that's the point: it never really was a fact.

I think the Frieden brother told more than once, that the size at ptr-4 was removed for various good reasons:
1. it was never documented to be there
2. it was no longer necessary with the new memory system
3. PPC cache lines have different alignment than 68k cache lines and an additional offset of 4 would slow things down
4. so far it did only break one major application (GoldED) and that has been fixed already
5. OS4 tries to enforce certain programming rules and punishes hacking.

The advantages of removing the size information by far outnumbered the disadvantages. And that's why it has been done. Compatibility is a big thing to maintain, but keeping undocumented features, which lead to hacking, is not always very wise.

If MOS could keep up the compatibility to OS3.x's AllocVec() without sacrificing any advantages then its perfect legal to keep this. But relying on undocumented features should never be encouraged.
 

Offline tboeckel

  • Newbie
  • *
  • Join Date: Jun 2006
  • Posts: 9
    • Show all replies
Re: Counting on AllocVec's size memo..
« Reply #2 on: December 22, 2006, 05:43:26 PM »
I think you perfectly know how beginners start programming. Take a program with source and see how other people solved certain problems. Sometimes you look into the Autodocs, but most of the time you get inspriration from "outside". At least that's the way I started programming many years ago. And if a beginner learns from such hacking it is sometimes very hard to convince this person from the oposite.

Good programming manuals are always welcome, but the biggest programming manual are available source codes, even if they are not perfect.

I don't say "let all the old applications crash and burn". I say "keep (wrong) compatibility as long as it is bareable, but sacrifice it if that would prevent really necessary improvements". And the new memory system really is a big step forward!

Surely it is not ok to sarcifice compatibility just to make old programs crash, but during all the beta testing of OS4 GoldED really was the *only* bad application. I think the Friedens would have decided the other way if more than this single program had been affected. But that was not the case.