[solved] Gdb changes a parameter?

[Joanna]

Static (i.e. const something) variables are at least in effect put on the heap when their declaration is first encountered. From that point onwards their value is retained, but they're only visible inside the function where they're declared even though their scope could be considered as similar to globals.

Interesting, since the initial value is known, I assume it is compiled into the executable file. I’m curious How is the initial value stored within the exe so that it can be used? Also is declaration first encountered when the code execution calls the procedure that the static constant is in?

[MarkMLl]

Static (i.e. const something) variables are at least in effect put on the heap when their declaration is first encountered. From that point onwards their value is retained, but they're only visible inside the function where they're declared even though their scope could be considered as similar to globals.

Interesting, since the initial value is known, I assume it is compiled into the executable file. I’m curious How is the initial value stored within the exe so that it can be used? Also is declaration first encountered when the code execution calls the procedure that the static constant is in?

How that works might, in practice, be implementation-defined. However it's reasonable to assume that if it's a simple numeric it will show up in the assembler output (i.e. which you could look at if so inclined :-) while if it's a more complex data structure it will be in one of the initialised sections of the relevant object file (.obj, .o etc. depending on the toolchain) hence in an initialised group of the executable (.exe or ELF, again depending on the toolchain and OS) and it will be later copied into working storage.

"Static constant"... horrid terminology, I believe we've got Turbo Pascal to blame for that. In any event it was omitted from Wirth's Pascal even though present (as "own" variables) in ALGOL-60, and that was one of the things on Kernighan's "why I hate Pascal" list.

Anyway, going back to where we were: I /think/ that it's copied onto the heap when encountered in a function (i.e. doesn't occupy space unless used), but it could be equally initialised by the compiler itself... the latter case would potentially reduce the risk of memory fragmentation. PascalDragon could obviously set us right there.

That might be fairly easily tested: define a large static data structure in a function, and check the size of the heap before and after using it.

However the thing that really matters is that in Pascal (and Rust), even if something is "in scope" if considered in the context of stack frames, the compiler does not necessarily permit it to be accessed i.e. "make it visible"... /unless/ of course you decide to try something clever by messing with pointers which is rarely a good idea. C doesn't usually distinguish between scope and visibility (and encourages pointer abuse), which is why the improvements in Rust are causing a stir.

Cowgol is interesting: it's designed for small (very small) computers and the compiler allocates /everything/ into heaplike storage without using a stack: in short it's like Rust but more so. That sacrifices recursion, which was of course one of the selling points of ALGOL when compared with FORTRAN; however (a) it's rare to even consider recursion in resource-limited systems and (b) compiler technology has improved a lot since the mid-50s.

MarkMLl

[Joanna]

Thanks for the explanation
Maybe pascal uses const because initial value is known when compiled however I’m not sure how it enables the typed constant to be used like a variable.

I definitely would not want to give up recursion..

[MarkMLl]

Thanks for the explanation
Maybe pascal uses const because initial value is known when compiled however I’m not sure how it enables the typed constant to be used like a variable.

I definitely would not want to give up recursion..

Some argue that Borland was so intent on saving space that they didn't want the overhead of defining and handling a "static" token and felt that reusing "const" was adequate: early Turbo Pascal was, after all, expected to operate in an amount of memory which by today's standard would be considered miniscule.

Alternatively, they added structured constants at about the same time as they allowed non-trivial function return values, and by happy coincidence it worked out like ALGOL's "own".

Whichever way, I share Kernighan's dismay that facilities which were in ALGOL-60 were omitted from Pascal.

Apropos recursion: it's generally agreed that undisciplined use of recursion and of the heap are unwise in resource-constrained systems, but IMO there's definitely situations where cautious use is appropriate. However Cowgol is very much an outlier, since the implementer has intentionally simplified it and kept the size down to a sufficient extent that it can not only run but also self-compile on an 8-bit system.

MarkMLl

[Joanna]

I would prefer to have a reserved word static as well. I maybe there is a way to add it to Fpc whilst keeping typed constants for backwards compatibility.

I usually use recursion for things like accessing child controls. Yes I know it’s possible with iteration but recursion seems easier to understand.

[MarkMLl]

I would prefer to have a reserved word static as well. I maybe there is a way to add it to Fpc whilst keeping typed constants for backwards compatibility.

An easy fix would be to define "static" as a macro, expanding to "const". However there's the usual caution about not introducing non-standard facilities which might confuse readers of your code, plus the obvious risk of FPC adding "static" which would obviously clash... I can't remember whether anything's on the cards there.

I'd add that Pascal's use of const, type, var and so on applying to multiple declarations but not requiring an explicit end is very similar to COBOL's "sections" which are almost universally derided (including by many Pascal programmers).

I usually use recursion for things like accessing child controls. Yes I know it’s possible with iteration but recursion seems easier to understand.

Maybe, maybe not. A case where I do use it on occasion is where a function has been passed a default or null parameter, is able to fill in an appropriate, and then calls itself recursively to get the job done i.e. rather than using a goto (which Wirth considered harmful) or a contrived continue (which wasn't in Pascal as originally defined). That can, obviously, be proven to go no more than two levels deep: anything more than that should be approached cautiously if software is to be reliable (unless writing in Lisp, where the "R" in the name stands for reliability).

MarkMLl

[Joanna]

I'd add that Pascal's use of const, type, var and so on applying to multiple declarations but not requiring an explicit end is very similar to COBOL's "sections" which are almost universally derided (including by many Pascal programmers).

I’ve never really thought about those needing an end. I like the way it assumes what it is after the first declaration until told otherwise.
I used to think that things had to be declared in a specific order const, type, var, but apparently they can be in any order as long is dependencies are declared first. The typed const doesn’t bother me too much but I do wish that there was a way to initialize variables in a similar way. The main reason for this is that Class variables are unique for each class instance but  typed constants are shared.

I’ve never felt the need to use goto with pascal, however I’m quite fond of  using exit () and break/continue in loops. I tend to use mostly for loops

[MarkMLl]

I used to think that things had to be declared in a specific order const, type, var, but apparently they can be in any order as long is dependencies are declared first.

I think that originally- J&W edition 1- the order was fixed. However once constants could include named values from enumerations it /had/ to be flexible.

...however I’m quite fond of  using exit () and break/continue in loops. I tend to use mostly for loops

Neither break nor continue existed in J&W, and I'm not sure about exit. I'd add that they complicate compiler writing significantly when used in conjunction with a finally block, and things are even worse when exceptions are involved.

MarkMLl

[Joanna]

I avoid that try .. finally stuff I prefer to check for error conditions beforeHand