1. if allocate() returned -1 on failure...
- Posted by petelomax 1 week ago
- 243 views
...how much legacy code would break?
Obviously any if mem=NULL would need to become if mem<=NULL - while 32-bit always returns +ve successes, I might also need to tweak 64-bit to do the same.
Or perhaps make that if odd(mem)... - which has a certain ring to it!
One trick I often use is pMem4 = allocate()/4: since it is always dword-aligned (or qword-aligned on 64-bit), no bits are lost and it is guaranteed to fit in a 31/63-bit integer.
It certainly simplifies hll-allocated memory for use by inline assembly, which just has to shl 2 rather than suck a >31/63 bit address out of an IEEE754.
If allocate returned -1 on failure, instead of the 0 it currently does, that trick would also automatically typecheck on error...
2. Re: if allocate() returned -1 on failure...
- Posted by andreasWagner 1 week ago
- 331 views
Hallo,
Honestly, I don't understand what you mean. It's probably my fault. No hard feelings.
3. Re: if allocate() returned -1 on failure...
- Posted by petelomax 1 week ago
- 219 views
Honestly, I don't understand what you mean.
If you don't use allocate() a ton of times, you're probably not in a position to answer the question anyway. Don't worry, it's probably a bit of a niche question.
Currently, allocate() returns 0 when it fails, either because you've already allocated so much memory there is no more to give, or you've asked it for a silly value, like -1 (aka MAXINT).
Many programs won't bother to check, and just crash as soon as they try to peek() or poke() it. Most programs never get anywhere near hitting the problem.
I'm thinking of changing it to return -1 on failure, the question is: of the (few?) programs that do actually check it, how many will be badly affected?
If I make that change, there's a trivial fix once you know what you have to change, but how painful might it be before you make that change?
In other words, are there any significant objections to me making that change?
4. Re: if allocate() returned -1 on failure...
- Posted by ghaberek (admin) 1 week ago
- 193 views
In cases like this, I typically refer to the principle of least surprise:
For those parts of the system which cannot be adjusted to the peculiarities of the user, the designers of a systems programming language should obey the "Law of Least Astonishment." In short, this law states that every construct in the system should behave exactly as its syntax suggests. Widely accepted conventions should be followed whenever possible, and exceptions to previously established rules of the language should be minimal.
In short: "a thing should do what I expect it to do." Although the corollary may be more important here: "a thing should not do what I would not expect it to do."
In my experience, functions that return a memory address almost universally return zero or null on error. Or if the language supports it, they throw an exception of some kind.
I think the historical and/or low-level reason for this is that memory addresses are typically stored as unsigned pointer-aligned integers, making zero the lowest possible value.
An alternative might be to return either a valid memory address (positive) or an error number (negative), and maybe zero represents an invalid result or "undefined" behavior.
Personally, I would not change it.
-Greg
