@BruceAbbott:
Why is it "not very useful"? Because it requires BB2 rather than BB0? I don't think there are many users still running without any Boing Bags installed. |
Quote:
Do you call the $VER: cookie a discusting kludge? Do you expect that average Joe User knows how much stack a particular program needs? Do you expect that average Joe User *remembers* to set the stack in the shell? Tripos and the Tripos executable format (aka AmigaDOS) is not extensible without breaking backwards compatibility, so there is no room for such meta-information without stopping old versions of the segment loader to break with such extensions, or without additional tools accidentally removing them. Or, put in different words: Do you have anything better to suggest? Provided that a) it works transparently with older Os releases, b) it embeds information such that it cannot get lost easily, and c) it can be easily detected? |
Quote:
Quote:
Quote:
Quote:
Quote:
But granted, programs shouldn't force the user to think about these details. There are, however, better ways to do that than stupid $STACK cookie. Quote:
Quote:
|
Quote:
|
Quote:
And if it does not, why can't the program itself do the same thing ? |
Quote:
|
Quote:
Quote:
Quote:
Quote:
Quote:
|
Quote:
And this means we have two stacks already : the one of the CLI process itself, and the one of the currently running program... Quote:
Quote:
Quote:
And you silently rejected the other - yes, a change in the hunk structure would have been a more intelligent way (not that it is clever in the absolute, but still better than the stack cookie). Anyway... code properly, and you won't need big stacks at all :p (That's 3 better ways than the cookie already, btw.) Quote:
So either the user does, in that case the cookie is utterly useless. Or he does not, in that case the program crashes. In both cases the cookie does not fare very well. Of course if the program itself allocated a stack, the cookie becomes redundant and more useless than ever. Right, it could check if the cookie worked before allocating anything, but it's a lot simpler to allocate the stack in all cases. Quote:
If your program uses huge 300kb stack, are you really after 4k ? The mere fact of using a compiler to build your program wastes a magnitude more than that due to significantly larger code - but you would still defend doing it... Furthermore, what happens if we copy original stack contents and do not restore the old stack upon exit ? |
@meynaf: you act like you are forced to use the STACK cookie...
|
Quote:
Besides, the problem is far from being located there. The problem would be if someone actually uses it, i run the program believing the stack size is automatically handled, but it crashes because in reality it is not. |
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
|
Quote:
Actually all your complaining is about how AmigaOS was lacking severely with regard to stack handling right from the start and how this got fixed (more or less) when AmigaOS was already a dead fish in the water. I don't see how Thomas is the right person to complain to. |
Quote:
Quote:
Quote:
It would have been fine if programs did not need to check their stack size at all. But they sometimes need to, and no amount of cookies will change this. Quote:
And now the cookie is hidden in crunched data and thus is not able to do what it has been designed to do. Congratulations, flotsam. Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
(I'm trying here to resist the temptation of saying 10 bytes is actually not enough...) Quote:
Quote:
Especially when some users will complain the program crashes and you take a lot of time in debug just to discover their setup did not support the cookie. If you want to spare time by using a compiler, at least let the compiler setup the stack by more compatible means - i think they can do this. Quote:
Is the stack address and size stored in other place than in exec task structure, where it can be changed ? Quote:
Certainly not the one calling RunCommand directly. So what about file managers, or worse, debuggers ? Are all possible paths for program execution patched to check the cookie ? I doubt. And now the stack cookie gets ignored in some cases, leaving the user wonder why his program crashes (whereas mere stackswap would have worked everywhere). Quote:
Quote:
|
Quote:
|
Quote:
|
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
|
Quote:
|
Quote:
Quote:
The hunk structure is more the way it should have been done initially. Quote:
And if relying on the cookie alone, the program is non-loadable on older versions of the OS (well, actually it is loadable and will fail silently). Quote:
Quote:
But even if it's fast, what do we have ? Well, the memory wasted is small, the amount of time wasted is small. Seems it's equal at the end. I still prefer using the memory, though, as at least it's always safe. Quote:
Rather, we should do our possible to make it reasonably safe. Quote:
Quote:
Quote:
Quote:
It can only increase the stack, but the point is for when it does not ! Quote:
Quote:
Quote:
And if programs don't look there... well, they're broken because it's quite standard way of doing things since very long - which is not the case for the cookie. Quote:
It's just that i prefer methods that work regardless of the setup. Quote:
Why having to scan a whole hunk of data for an info which can be put directly in the header ? |
Quote:
The argument with the slow loading of the program doesn't seem very convincing because, again, it is up to the user whether he wants to use an updated loader that needs to search the binary for the cookie or not. For all I know typical 3.9BB users aren't of the A500 with 1MB RAM kind. |
Quote:
Quote:
Code:
static const char *stack="$STACK:8192\n"; Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
|
All times are GMT +2. The time now is 07:14. |
Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.