Counting on AllocVec's size memo..

[Karlos]

The only thing one should ever depend on is that the memory allocation system is a black box about which you should never assume anything other than what is officially documented.

This is true for every operating system. Making assumptions of this kind is bad development. When you allocate storage for x bytes, you are only guarenteed that you have at least that much; it could be more.

[Karlos]

"Killing" any register not known to be defined as volatile on any specification is bad. Do what the hell you want to a register in your own code but be sure to save/restore anything not volatile.

Unless you are a bad coder of the type that makes dangerous assumptions about everything you come across.

I think there's a touch of melodrama in this thread. Some applications may break because they were badly written or had at least one majorly bad assumption.

Any code that makes these kind of assumptions will eventually fall over as the system moves on. There are applications that bail on every major operating system at some stage due to their age. Saying this is always the fault of the OS is a bit unfair when it is down to the actions of the developer.

Would you blame the C/C++ compiler's compatibility here or the developer if we substituted the word "AllocVec" with "malloc" or "operator new[]()" ?


If we look at the issues in context for a moment. There are apps that won't work. If they are very old, the chances are the services they provide have been replaced by newer applications. If they are new apps, the chances are they can  be fixed.

Similar problems with compatibility existed moving from 1.3 to 2.0 and that was a much smaller technical step than the changes from 3.9 to OS4 / MOS.

[Karlos]

@itix

It appears you missed my point. Regardless of how long AllocVec() behaved the way it did and regarless of how long memory lists are stored it is *not* within the developers remit to assume anything about it.

A given compiler may handle malloc() the same way. If it did, for years and years, would you regard it as acceptable practise to operate on the assumption and use it within your code? I certainly would not, under any circumstances, ever.

If you need to care about the allocation size, perhaps in some system with a lot of dynamic allocation going on, then you wrap the allocator routines yourself or use pools, you sure as hell don't go around poking into negative pointer offsets from the base address, regardless of how long it might have worked historically. You sure as hell wouldn't do it in ANSI-C/C++, there's no reason to do it when using exec either. People only get tempted to do this because most of the structures used by the OS are visible in one header or another and fail to appreciate that they are private to the system regardless.

The point has been raised that there was no need to do this and break compatibility and that for compatibility sake it could have been left alone. Regardless of wether this is true or not, I think criticising the OS in this case is a bit of a strawman attack. The real issue is that developers shouldn't habitually point loaded guns at their own feet and wonder why they might lose some toes one day ;-)

[Karlos]

I have to say, this is pretty bad :-(

I still stand by the view that the developer was at fault for assuming things about the underlying memory subystem. There's no need for it. Certainly I've never needed to. Feel free to prove me wrong on that count. For a major application, this practise is inexcusable.

Amiga developers need to understand what APIs are and when they must use them. Banging the metal or underlying OS implementation internals may have been acceptable in the 80's but things change.

[Karlos]

I wonder just how difficult it would be to add this value back to ptr-4 with the new system.

Ok it isn't clean, but it shouldn't be that hard to do. Just clone the value from wherever else it is stored.