Supervisor stack size?

[Minuous]

@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.

[Thomas Richter]

Originally Posted by Bruce Abbott

So not very useful then - and also a disgusting kludge. Though I guess it's better than expecting users to type a 'stack' command before running programs from the CLI, and then unceremoniously crashing when they don't.

Oh, so you say that you can never add a new feature because old versions would not support it? That does not sound very useful for me.

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?

[meynaf]

Originally Posted by Bruce Abbott

So not very useful then - and also a disgusting kludge. Though I guess it's better than expecting users to type a 'stack' command before running programs from the CLI, and then unceremoniously crashing when they don't.

More than a disgusting kludge, it's totally useless, and worse, dangerous. Because programs will still unceremoniously crash whereever it's not supported.

Originally Posted by Minuous

I don't think there are many users still running without any Boing Bags installed.

There is at least me.

Originally Posted by Thomas Richter

Oh, so you say that you can never add a new feature because old versions would not support it? That does not sound very useful for me.

Not all new features are dirty, useless little things

Originally Posted by Thomas Richter

Do you call the $VER: cookie a discusting kludge?

Programs don't crash if $VER is not supported.

Originally Posted by Thomas Richter

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?

Average Joe user isn't using AmigaOS at all.
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.

Originally Posted by Thomas Richter

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.

That would have nevertheless been more clever. This way, programs would not run at all under previous OS versions. The cookie isn't backward compatible anyway because if stack size is ignored, the program will crash.

Originally Posted by Thomas Richter

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?

From OS V37 we have something called StackSwap.

[grond]

Originally Posted by meynaf

More than a disgusting kludge, it's totally useless, and worse, dangerous. Because programs will still unceremoniously crash whereever it's not supported.

Why would that be? I guess you could still check the stack size assigned to your program and allocate some extra stack if the original stack isn't enough. Of course, you can do this in earlier OS versions, too, but with the $STACK cookie you can at least avoid wasting the memory allocated for the original stack.

[meynaf]

Originally Posted by grond

Why would that be? I guess you could still check the stack size assigned to your program and allocate some extra stack if the original stack isn't enough. Of course, you can do this in earlier OS versions, too, but with the $STACK cookie you can at least avoid wasting the memory allocated for the original stack.

But the $STACK cookie has to restore original stack size at the end of the program as well, so why wouldn't it also waste original stack space ?
And if it does not, why can't the program itself do the same thing ?

[Thomas Richter]

Originally Posted by meynaf

But the $STACK cookie has to restore original stack size at the end of the program as well, so why wouldn't it also waste original stack space ?
And if it does not, why can't the program itself do the same thing ?

No, it does not. You do not know how AmigaOs handles the stack. To remind you: The "STACK" command does not allocate any stack at all. It just records the stack size in the CommandLineInterface structure. The stack is allocated *every time* you execute a program from the shell (or the workbench), anew. Thus, whether you use the STACK command, or the $STACK cookie makes no freaking difference whatsoever.

[Thomas Richter]

Originally Posted by meynaf

More than a disgusting kludge, it's totally useless, and worse, dangerous. Because programs will still unceremoniously crash whereever it's not supported.

It's up to you to write programs that do not crash.

Originally Posted by meynaf

Programs don't crash if $VER is not supported.

Programs neither crash if $STACK is not supported - if the STACK is set manually.

Originally Posted by meynaf

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.

As you haven't suggested any, I suppose you are not aware of any.

Originally Posted by meynaf

That would have nevertheless been more clever. This way, programs would not run at all under previous OS versions. The cookie isn't backward compatible anyway because if stack size is ignored, the program will crash.

Not if the user has set STACK or the program allocated stack at all.

Originally Posted by meynaf

From OS V37 we have something called StackSwap.

Oh wow, but *this* (unlike $STACK) will indeed require the memory of the originally allocated stack *PLUS* the size of the additionally allocated stack. Unlike the STACK command o the $STACK cookie.

[meynaf]

Originally Posted by Thomas Richter

No, it does not. You do not know how AmigaOs handles the stack. To remind you: The "STACK" command does not allocate any stack at all. It just records the stack size in the CommandLineInterface structure. The stack is allocated *every time* you execute a program from the shell (or the workbench), anew. Thus, whether you use the STACK command, or the $STACK cookie makes no freaking difference whatsoever.

Then the called program can do the same. Why wouldn't it be able to ?
And this means we have two stacks already : the one of the CLI process itself, and the one of the currently running program...

Originally Posted by Thomas Richter

It's up to you to write programs that do not crash.

This implies not using the cookie but using instead a proper way to handle the stack.

Originally Posted by Thomas Richter

Programs neither crash if $STACK is not supported - if the STACK is set manually.

Right of course, the program won't crash if the cookie isn't supported and would have had no effect (and is therefore useless). Big deal.

Originally Posted by Thomas Richter

As you haven't suggested any, I suppose you are not aware of any.

I have suggested two, actually... That you rejected one for a minor shortcoming does not invalidate it. Better wasting 4k than taking the risk of a very bad crash, no ?
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
(That's 3 better ways than the cookie already, btw.)

Originally Posted by Thomas Richter

Not if the user has set STACK or the program allocated stack at all.

But the purpose of the cookie is precisely to avoid the fact the user has to set the stack !
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.

Originally Posted by Thomas Richter

Oh wow, but *this* (unlike $STACK) will indeed require the memory of the originally allocated stack *PLUS* the size of the additionally allocated stack. Unlike the STACK command o the $STACK cookie.

Right, and ?
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 ?

[grond]

@meynaf: you act like you are forced to use the STACK cookie...

[meynaf]

Originally Posted by grond

@meynaf: you act like you are forced to use the STACK cookie...

Nonsense. I can perfectly tell something is a bad idea without being forced to use it in any way. Please refrain speaking about people, especially those you do not know.
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.

[Thomas Richter]

Originally Posted by meynaf

Then the called program can do the same. Why wouldn't it be able to ?

Did you read what I have written? Because that requires both the original stack size as memory *plus* the stack the program allocated manually. With $STACK, it requires only the correct stack size.

Originally Posted by meynaf

And this means we have two stacks already : the one of the CLI process itself, and the one of the currently running program...

Right, which is what we have since the stone age of Tripos. Do you now finally get it? The stack the shell gets is in no relation to the stack the programs get that are executed by it. This is not at all new - it has always been like that. Tripos, AmigaOs from Kickstart 1.0 on, creates a custom stack for every executable it launches, and this stack is separate from the stack of the shell itself. Yes, really, there are two stacks: The stack of the shell, and the stack of the programs executed by the shell, and STACK and the stack cookie only control the size of the latter. The shell only has a quite minimal stack for itself, which is separate and unrelated to the program stack.

Originally Posted by meynaf

Right of course, the program won't crash if the cookie isn't supported and would have had no effect (and is therefore useless). Big deal.

The "deal" is that programs that check their stack size upon entry do not need to allocate a new custom stack and thus leave the stack allocated for them by the shell unused. Is that really so hard to understand?

Originally Posted by meynaf

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).

A non-working one. That would have meant that all the legacy tools we have would not be able to process such binaries, Mr. Smartipants. Or loose the stack information when processing them. The cookie can be easily checked, and can be easily embedded, and there is no chance of loosing it.

Originally Posted by meynaf

Anyway... code properly, and you won't need big stacks at all.

With the 4K default stack, you already run into limitations right ahead. Probably you don't know, but various intuition functions (such as OpenWindow() & friends, OpenScreen() & friends, the auto requesters) and various datatypes (the picture datatype, the animation datatype and so on) already contain a stack check and stack exchange code to avoid stack problems when run from programs with 4K stack only. All that stack code will detect whether there is sufficient stack space, and won't swap if there is. This swapping you can avoid with adjusting the stack properly in first place.

Originally Posted by meynaf

So either the user does, in that case the cookie is utterly useless.

And if the user does not, it is quite useful.

Originally Posted by meynaf

Or he does not, in that case the program crashes.

Not in case the program is run under a 3.9 shell, or something later than the 3.9 shell. So, I call that "useful" and "a good deal".

Originally Posted by meynaf

In both cases the cookie does not fare very well.

I call "avoiding a crash" a good deal.

Originally Posted by meynaf

Of course if the program itself allocated a stack, the cookie becomes redundant and more useless than ever.

Again, no. It avoids a memory allocation, and wasteful use of resources.

Originally Posted by meynaf

Right, it could check if the cookie worked before allocating anything, but it's a lot simpler to allocate the stack in all cases.

It is wasteful, whereas the stack cookie requires 10 bytes in the executable. I call that a good deal.

Originally Posted by meynaf

If your program uses huge 300kb stack, are you really after 4k ?

If I can get them that easily, yes.

Originally Posted by meynaf

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...

It avoids spending a lot of *time*, which is an important resource. Time developing and time debugging. Besides, the code is quite good in most cases if you know how to handle the compiler.

Originally Posted by meynaf

Furthermore, what happens if we copy original stack contents and do not restore the old stack upon exit ?

You crash. And your point is? The stack cookie works like the stack command. It does not require the program to take any action. The dos.library RunCommand() takes care of the stack allocation and stack release, the shell takes care of supplying it with the right arguments. The stack argument to this call is the maximum of the current stack size noted in the command line interface structure and the contents of the stack cookie, should it exist.

[grond]

Originally Posted by meynaf

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.

Um, I thought we had discussed this already. Use the $STACK cookie, check actual stack size on startup to see whether your program really got enough stack (either by being run on an OS version that does support the cookie or because the user has set enough stack), if not enough stack is present, allocate your own and optionally output a message that asks for the correct stack size for future use. How difficult can this be?

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.

[meynaf]

Originally Posted by Thomas Richter

Did you read what I have written? Because that requires both the original stack size as memory *plus* the stack the program allocated manually. With $STACK, it requires only the correct stack size.

Yes of course i have read what you have written, but what you have written did not answer the question. The called program can still free the allocated stack and allocate a bigger one. The question was : what could prevent it from doing so.

Originally Posted by Thomas Richter

Right, which is what we have since the stone age of Tripos. Do you now finally get it? The stack the shell gets is in no relation to the stack the programs get that are executed by it. This is not at all new - it has always been like that. Tripos, AmigaOs from Kickstart 1.0 on, creates a custom stack for every executable it launches, and this stack is separate from the stack of the shell itself. Yes, really, there are two stacks: The stack of the shell, and the stack of the programs executed by the shell, and STACK and the stack cookie only control the size of the latter. The shell only has a quite minimal stack for itself, which is separate and unrelated to the program stack.

Ok, but if the purpose of the cookie is to spare an extra stack, why not merging the stack of the shell with the one of the program, while we're here ?

Originally Posted by Thomas Richter

The "deal" is that programs that check their stack size upon entry do not need to allocate a new custom stack and thus leave the stack allocated for them by the shell unused. Is that really so hard to understand?

It is not hard to understand. But it is not new. No need for a stack cookie for it.
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.

Originally Posted by Thomas Richter

A non-working one. That would have meant that all the legacy tools we have would not be able to process such binaries, Mr. Smartipants. Or loose the stack information when processing them. The cookie can be easily checked, and can be easily embedded, and there is no chance of loosing it.

No chance of loosing it, huh ? This is simply not true. It will be lost any time some bozo uses a cruncher - yes, a legacy tool - to reduce the size of your executable. A quite likely situation, more likely than with any other type of tool having to parse hunks.
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.

Originally Posted by Thomas Richter

With the 4K default stack, you already run into limitations right ahead. Probably you don't know, but various intuition functions (such as OpenWindow() & friends, OpenScreen() & friends, the auto requesters) and various datatypes (the picture datatype, the animation datatype and so on) already contain a stack check and stack exchange code to avoid stack problems when run from programs with 4K stack only. All that stack code will detect whether there is sufficient stack space, and won't swap if there is. This swapping you can avoid with adjusting the stack properly in first place.

As if a stack swap could take a significant amount of time... Compare that to the time taken by every program run, by merely scanning the first code hunk (especially in large programs where the cookie is simply not there).

Originally Posted by Thomas Richter

And if the user does not, it is quite useful.

Maybe, but that remains a rare case.

Originally Posted by Thomas Richter

Not in case the program is run under a 3.9 shell, or something later than the 3.9 shell. So, I call that "useful" and "a good deal".

But the problem is that it is silently ignored if not supported. Important things shall not be ignored.

Originally Posted by Thomas Richter

I call "avoiding a crash" a good deal.

Should be. But it only does that in a limited number of cases. In the others -- gives a false impression of safety.

Originally Posted by Thomas Richter

Again, no. It avoids a memory allocation, and wasteful use of resources.

Not if that memory can be freed by the called program (i'm not saying it can, but i still see no reason why it can't).

Originally Posted by Thomas Richter

It is wasteful, whereas the stack cookie requires 10 bytes in the executable. I call that a good deal.

I don't call a good deal, a deal that only works in a very limited number of cases.
(I'm trying here to resist the temptation of saying 10 bytes is actually not enough...)

Originally Posted by Thomas Richter

If I can get them that easily, yes.

Even if the cost is extra risk of crashing on other people's setups ?

Originally Posted by Thomas Richter

It avoids spending a lot of *time*, which is an important resource. Time developing and time debugging. Besides, the code is quite good in most cases if you know how to handle the compiler.

Time developing, yes. Time debugging, i doubt.
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.

Originally Posted by Thomas Richter

You crash.

And why ? A stack is allocated when running the program and freed afterwards, why would changing it during the program crash anything ?
Is the stack address and size stored in other place than in exec task structure, where it can be changed ?

Originally Posted by Thomas Richter

And your point is? The stack cookie works like the stack command. It does not require the program to take any action. The dos.library RunCommand() takes care of the stack allocation and stack release, the shell takes care of supplying it with the right arguments. The stack argument to this call is the maximum of the current stack size noted in the command line interface structure and the contents of the stack cookie, should it exist.

And who reads the stack cookie ?
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).

Originally Posted by grond

Um, I thought we had discussed this already. Use the $STACK cookie, check actual stack size on startup to see whether your program really got enough stack (either by being run on an OS version that does support the cookie or because the user has set enough stack), if not enough stack is present, allocate your own and optionally output a message that asks for the correct stack size for future use. How difficult can this be?

It's not difficult but it only works if all users of the cookie actually do it this way. And i expect it might eventually not be the case.

Originally Posted by grond

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.

I'm not complaining. I'm just saying the cookie isn't a proper solution, and ThoR did not agree, hence what we have here.

[Don_Adan]

Originally Posted by meynaf

I'm not complaining. I'm just saying the cookie isn't a proper solution, and ThoR did not agree, hence what we have here.

Right, for me ths is dirty hack only, not very useful too. The only good and clean solution is updating dos.library routine LoadSeg for new hunk type StackSize. Maybe exec.library must be updated too, i dont remember.

[Thomas Richter]

Originally Posted by Don_Adan

Right, for me ths is dirty hack only, not very useful too. The only good and clean solution is updating dos.library routine LoadSeg for new hunk type StackSize. Maybe exec.library must be updated too, i dont remember.

Ok, so you update the programs that work on the Amiga hunk structure, would you? Please start with SLink, and let me know when you are done. Until then, I stick to the stack cookie.

[Thomas Richter]

Originally Posted by meynaf

Yes of course i have read what you have written, but what you have written did not answer the question. The called program can still free the allocated stack and allocate a bigger one. The question was : what could prevent it from doing so.

The stack allocation of RunCommand() is private, and places there a couple of data structures for the BCPL runtime. You cannot deallocate the stack yourself as the way how it was allocated depends on the way how the program was run.

Originally Posted by meynaf

Ok, but if the purpose of the cookie is to spare an extra stack, why not merging the stack of the shell with the one of the program, while we're here ?

Because that requires touching a lot of legacy code, the BCPL runtime (emulation) within the dos.library and the working of the shell.

Originally Posted by meynaf

It is not hard to understand. But it is not new. No need for a stack cookie for it.
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.

Once again: Nothing against checking the stack size - but the cookie avoids the reallocation of the stack.

Originally Posted by meynaf

No chance of loosing it, huh ? This is simply not true. It will be lost any time some bozo uses a cruncher - yes, a legacy tool - to reduce the size of your executable.

Then it would rather be the job of the cruncher to take care of the cookie or your "customized hunk structure" either. None of that survives the process.

Originally Posted by meynaf

A quite likely situation, more likely than with any other type of tool having to parse hunks.

Heck no. Development touches hunks. The linker touches hunks. Worse, it would make the program non-loadable on older versions of the Os.

Originally Posted by meynaf

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.

Sounds more like an argument against crunching.

Originally Posted by meynaf

As if a stack swap could take a significant amount of time... Compare that to the time taken by every program run, by merely scanning the first code hunk (especially in large programs where the cookie is simply not there).

First, I do not care about the time so much - but the memory is wasted - for nothing. The scan is actually quite smart. It only has to read every 7th byte of the first hunk.

Originally Posted by meynaf

Should be. But it only does that in a limited number of cases. In the others -- gives a false impression of safety.

A brilliant argument. There is no safety in AmigaOs to begin with. If you want that, go for a serious operating system.

Originally Posted by meynaf

Not if that memory can be freed by the called program (i'm not saying it can, but i still see no reason why it can't).

Then tell me how, Mr. Smartipants. There is more on the initial stack RunCommand() puts there, and depends upon. Well, go ahead, write a "stack swapper" that works robustly no matter how the program was run.

Originally Posted by meynaf

I don't call a good deal, a deal that only works in a very limited number of cases.

In an increasing number of cases given that the feature costs almost nothing and is trivial to add to programs.

Originally Posted by meynaf

Even if the cost is extra risk of crashing on other people's setups ?

The stack cookie never crashes anything. It can only increase the stack.

Originally Posted by meynaf

Time developing, yes. Time debugging, i doubt.

Then you never actually wrote and debugged a larger program.

Originally Posted by meynaf

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.

Some compilers can inject stack checking code at the start of each function. Which has a run-time penalty. It's not turned on in any Os component since the checking cost is considered harmful. It is "modestly safe" in the sense of "it works as long as a single function does not eat the entire stack at once".

Originally Posted by meynaf

Is the stack address and size stored in other place than in exec task structure, where it can be changed ?

Yes, it is. There is more data on this "stack segment" that you seem to know. It all depends on how the program was launched, but there is, depending on the startup, *) an additional BPCL cookie at the start of the stack *) a pointer to that for the Exit() function in the process structure, *) potentially the name of the program, pointed to by the task structure *) potentially a small startup stub to emulate a segment if the stack was created through CreateNewProc()... ...and multiple other things. How exactly the stack was allocated, and which other structures where allocated along with it depends a lot on how the program was launched. There is more than one method. You cannot get rid of the stack. Only the (implicitly called) exit code of the task or process or command can. There are at least three different ways how the stack could have been created, and they are not easily distinguished from within the running program.

Originally Posted by meynaf

And who reads the stack cookie ?

The shell and the workbench, apparently. The same argument can be raised about the stack size in the "icon". This is also read by the workbench, and implemented by the workbench. If programs don't look there... well, then they don't look there. Same goes for the stack cookie. Except that things are even worse for the icon. Change it, or edit it, and loose the information. Here, at least, the cookie is bundled directly with the program, without the chance of getting lost or replaced.

Originally Posted by meynaf

I'm not complaining. I'm just saying the cookie isn't a proper solution, and ThoR did not agree, hence what we have here.

There is no "proper" solution for an Os that does not support stack overflow identification. There are only methods that simplify the workflow.

[grond]

Originally Posted by Don_Adan

Right, for me ths is dirty hack only, not very useful too.

It's only not very useful because it wasn't introduced with say Kick 1.3 or 2.0 but with something even after 3.1. If it had been introduced much earlier, it would be a perfectly acceptable (because widely accepted) solution for something that was broken from the start.

[meynaf]

Originally Posted by Thomas Richter

Once again: Nothing against checking the stack size - but the cookie avoids the reallocation of the stack.

Scanning every program upon startup just to avoid a simple reallocation on a few of them does not sound very useful to me.

Originally Posted by Thomas Richter

Then it would rather be the job of the cruncher to take care of the cookie or your "customized hunk structure" either. None of that survives the process.

Of course, but a mere call to StackSwap does survive the process.
The hunk structure is more the way it should have been done initially.

Originally Posted by Thomas Richter

Heck no. Development touches hunks. The linker touches hunks. Worse, it would make the program non-loadable on older versions of the Os.

Right, did not think about this. But then, the linker does not necessarily know it has to put the cookie in the first code hunk...
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).

Originally Posted by Thomas Richter

Sounds more like an argument against crunching.

Maybe. But i've seen a lot more crunched programs than i've seen stack cookies.

Originally Posted by Thomas Richter

First, I do not care about the time so much - but the memory is wasted - for nothing. The scan is actually quite smart. It only has to read every 7th byte of the first hunk.

Reading every 7th byte won't make it 7 times faster because said byte needs to be compared against several possible values.
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.

Originally Posted by Thomas Richter

A brilliant argument. There is no safety in AmigaOs to begin with. If you want that, go for a serious operating system.

Being already not very safe, isn't a reason to add more on top of it.
Rather, we should do our possible to make it reasonably safe.

Originally Posted by Thomas Richter

Then tell me how, Mr. Smartipants. There is more on the initial stack RunCommand() puts there, and depends upon.

I didn't claim it was possible, just that i did not see a reason why it wouldn't, Mr. Smarty Pants.

Originally Posted by Thomas Richter

Well, go ahead, write a "stack swapper" that works robustly no matter how the program was run.

Let me think... a stack swapper that works robustly no matter how the program was run... hey, wait. Yes it's a mere pair of calls to StackSwap !

Originally Posted by Thomas Richter

In an increasing number of cases given that the feature costs almost nothing and is trivial to add to programs.

Not that trivial i'm afraid. The compiler may eventually remove it altogether because it was unused data (and the linker put it at the wrong place, as stated above).

Originally Posted by Thomas Richter

The stack cookie never crashes anything. It can only increase the stack.

Not the stack cookie itself, of course
It can only increase the stack, but the point is for when it does not !

Originally Posted by Thomas Richter

Then you never actually wrote and debugged a larger program.

A bloatware, indeed i haven't.

Originally Posted by Thomas Richter

Some compilers can inject stack checking code at the start of each function. Which has a run-time penalty. It's not turned on in any Os component since the checking cost is considered harmful. It is "modestly safe" in the sense of "it works as long as a single function does not eat the entire stack at once".

I was just speaking about compilers using normal stack swap as part of their startup code.

Originally Posted by Thomas Richter

The shell and the workbench, apparently. The same argument can be raised about the stack size in the "icon". This is also read by the workbench, and implemented by the workbench. If programs don't look there... well, then they don't look there. Same goes for the stack cookie. Except that things are even worse for the icon. Change it, or edit it, and loose the information. Here, at least, the cookie is bundled directly with the program, without the chance of getting lost or replaced.

If your icon editor deletes information it ought not, you should switch to another one
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.

Originally Posted by Thomas Richter

There is no "proper" solution for an Os that does not support stack overflow identification. There are only methods that simplify the workflow.

Agreed.
It's just that i prefer methods that work regardless of the setup.

Originally Posted by grond

It's only not very useful because it wasn't introduced with say Kick 1.3 or 2.0 but with something even after 3.1. If it had been introduced much earlier, it would be a perfectly acceptable (because widely accepted) solution for something that was broken from the start.

Not even. It would still have been a hack.
Why having to scan a whole hunk of data for an info which can be put directly in the header ?

[grond]

Originally Posted by meynaf

Of course, but a mere call to StackSwap does survive the process.

The drawback is that if the programmer calculated the need for stack wrong (e.g. when dealing with unexpectedly large objects), stack size can't be increased from the outside without patching the binary.

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.

[Thomas Richter]

Originally Posted by meynaf

Of course, but a mere call to StackSwap does survive the process.
The hunk structure is more the way it should have been done initially.

I'm not *against* stackswap. it's just wasteful.

Originally Posted by meynaf

Right, did not think about this. But then, the linker does not necessarily know it has to put the cookie in the first code hunk...

You, as the author, have to use the tools such that the cookie appears at a location that is accessible. Which is not particularly difficult. Hint:

 static const char *stack="$STACK:8192\n";

works nicely for the default configuration. Just place in any source code you like. This is quite "$VER:". As this is a constant string, it ends up in the TEXT segment, like any other constant string.

Originally Posted by meynaf

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).

Heck, no. Why do you continue to tell such nonsense. The program is fully fine. It is just that under such circumstances, you have to deliver either an icon with the proper stack size set, or tell the user "please use the stack command to increase the stack to .. XXX bytes" if run from the shell.

Originally Posted by meynaf

Maybe. But i've seen a lot more crunched programs than i've seen stack cookies.

Which is not a miracle given that 3.9 is from a time where floppy disks became obsolete, and thus the need for crunching.

Originally Posted by meynaf

Reading every 7th byte won't make it 7 times faster because said byte needs to be compared against several possible values.

Nope. A single read and a table lookup is sufficient. This is not quite as stupid as you seem to imagine.

Originally Posted by meynaf

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.

Then that's you. I prefer that programs tell which resources they require.

Originally Posted by meynaf

Being already not very safe, isn't a reason to add more on top of it.
Rather, we should do our possible to make it reasonably safe.

And for that we have a stack cookie, exactly.

Originally Posted by meynaf

Let me think... a stack swapper that works robustly no matter how the program was run... hey, wait. Yes it's a mere pair of calls to StackSwap !

You cannot release the stack. You allocate a new one on top.

Originally Posted by meynaf

Not that trivial i'm afraid. The compiler may eventually remove it altogether because it was unused data (and the linker put it at the wrong place, as stated above).

See above, no. Give it global lifetime, non-static linkage, constant string, and you will be fine. Slink does not attempt to remove data with external linkage. Things are really easy.

Originally Posted by meynaf

I was just speaking about compilers using normal stack swap as part of their startup code. 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.

In other words: Evolution of AmigaOs is worthless because you don't care. That's not an argument against adding functionality.

Originally Posted by meynaf

It's just that i prefer methods that work regardless of the setup.

Then setup properly. It's not that 3.9 is *that* new.

Originally Posted by meynaf

Not even. It would still have been a hack.

Then $VER is the same hack.

Originally Posted by meynaf

Why having to scan a whole hunk of data for an info which can be put directly in the header ?

Because there is no room in the header. The Tripos HUNK structure does not reserve a hunk for it, quite simple. Of course, scanning ends earlier if you put it near the top of the hunk (which is neither hard to arrange).