Object Pascal, Memory Safety, the US Whitehouse and future programming

[ad1mt]

     void (*signal(int sig, void (*func)(int)))(int)

Marcov made sense of that ION's ago...

Good for Marcov!  But no good for most people!
In his excellent book on advanced C programming, "Deep C Secrets", Peter Van der Linden devotes a section to "unscrambling C definitions". In that section he presents a small C program that unscrambles C definition code, and converts the definition into human readable form!
What kind of language is it, that programmers need a small utility to understand the code?

[Thaddy]

The usual route I take is either write everything in C or if anyone has been creative with macro's have it expanded by the preprocessor. ( e.g. cpp -E)

In this case it is not very difficult to understand that it is a procedure that takes two parameters: a signal number and a procedural function parameter that returns an integer.

[Warfley]

What kind of language is it, that programmers need a small utility to understand the code?

You can write unreadable code in any language. But also, this is the definitiion in the standard, no C programmer actually programs like this. If you look at the definition of the signal function in the glibc you'll find:

Code: C  [Select][+][-]

1. typedef void (*__sighandler_t) (int);
2. [...]
3. extern __sighandler_t signal (int __sig, __sighandler_t __handler)

So... no, C programmes don't all sit there using programs to decipher their own code. They just write readable code

There is a simple reason why the definition in the C standard is more complex. They do not rely on intermediate typedefs, what most developers (as you can see with the glibc source) actually do, so they must nest the definitions, which get's complicated.

But thats just because it's a standard. This is the definition of a string in the Extended Pascal Standard:

A string-type shall be a fixed-string-type or a variable-string-type or the required type designated canonical-string-type. Each string-type value is a value of the canonical-string-type.

Each value of a string-type shall be structured as a one-to-one mapping from an index-domain to a set of components possessing the char-type. The index-domain shall be a nite set that is empty or that contains successive integers starting with 1.
The length of a string-type value shall be the number of members in its index-domain. The string-type value with length zero is designated the null-string.
The length of a char-type value shall be 1. The capacity of the char-type shall be 1.
The correspondence of character-strings to values of string-types is obtained by relating the individual string-elements of the character-string, taken in textual order, to the components of the values of the string-type in order of increasing index

You also need to read it like 10 times before you can understand what is written there. Does this mean Pascal is overly complicated or that standards are just not very reader friendly?

[marcov]

We actually never used signal(). The kernel call already was SYSV sigaction() based at the time, and having mostly syscall ports at the time we never bothered with the legacy signal() definition till nearly a decade later when we tried proprietary libc only targets.

[AlexK]

Personally, I believe that programming languages shouldn't manage memory.  They should not even attempt to manage memory.   That's what the programmer is for.

This is one of the reasons to dabble with Object Pascal.
Rarely mentioned feature in objpas is TComponent automatic memory management facilities, which could be a stencil for a similar implementation of your own.
Any object can be implicitly cast to an untyped Pointer. Collection classes use it.

[440bx]

One of the things a compiler should _never_ do is decide where memory will be allocated. 

The most basic principle of managing memory is first and foremost deciding where the needed structures will reside in memory.  That's part of the design the programmer is responsible for.

Once it is the compiler that makes that choice, Pandora's box is wide open.

I should not say things like that here but, every now and then reality has to be mentioned.  Everyone please, ignore this post, thank you but, do keep that "inconvenient" fact in the back of your mind.

[ad1mt]

I'm surprised to see how many people here are excusing the failings of C!
I would have thought all Pascal fans would agree with me!
It is one of the great disasters in programming history that Ada or Modula-2 did not kick C into the trashcan.
Finally, other better languages are slowly taking over, but its taking a long time.

[LeP]

I'm surprised to see how many people here are excusing the failings of C!
I would have thought all Pascal fans would agree with me!

For what my word is worth, I agree with you.
I absolutely don't like the mix of Pascal and C.

And there's no argument against those who say the conversion is easier this way: for me, either convert everything to Pascal or leave it in C and create a DLL.

[AlexK]

A short review how sound null safety looks in Dart.
I was thinking what could possibly prevent Object Pascal from implementing sound null safety.

For nullable types. If you generally don't use nullable types in object pascal, I don't see the point ?

I couldn't unambiguously interpret this reply in a form of a question.
It might have been something related to what FreePascal wiki calls "Nullable types".

"Sound Null Safety" in modern languages solves runtime "null reference exception".(in Java NullReferenceException)

At any point in some program a NIL value can fly in. Programmer has no clues by looking at the code. Compiler has no info when some variable can be nil.

"Sound Null Safety" makes all pointer/reference type NOT NILable by default. A variable of some class type can't be assigned NIL. Programmer knows that variable is never NIL and there's no need to use defensive programming style with IF checks for NIL in many places.

To allow a pointer/reference variable be assigned NIL, its type must be annotated with "?" suffix.
So when compiler sees a usage of such NILable variable without checking it for NIL value - it emits an error.

NullReferenceException at runtime is a solved comp-science problem in Dart and Swift.

[440bx]

NullReferenceException at runtime is a solved comp-science problem in Dart and Swift.

Yes and no. 

Like most problems in CS, the solution depends on imposing a number of constraints.  For instance, any language that allows using "absolute" such as FPC (or its assembler equivalent "org") cannot deterministically solve the nil pointer problem.

That said, I haven't given the problem enough thought to figure out if there is a solution in that case but, if there is one, it means more work for the compiler, consequently slower compilation.

I have to say, I watched the video you linked to and, no doubt, it is a very interesting concept.

[AlexK]

Like most problems in CS, the solution depends on imposing a number of constraints.  For instance, any language that allows using "absolute" such as FPC (or its assembler equivalent "org") cannot deterministically solve the nil pointer problem.

That said, I haven't given the problem enough thought to figure out if there is a solution in that case but, if there is one, it means more work for the compiler, consequently slower compilation.

Absolute are RARE and easily searchable in source code.

NIL safety validation is a part of type validation, it shouldn't be expensive.
"Sound Nil Safety" validation could be switched OFF in compiler when doing incremental builds, I guess.
When back to ON, the compiler would show where NIL-checks must be inserted for runtime safety and which NIL-checks are redundant.

A lot of nondeterminism with IFs can influence program's performance in some tight algorithms.

Longer explanation of "Sound Null Safety" is here: https://dart.dev/null-safety/understanding-null-safety
Bob Nystrom's usual style includes a "thought train" in the process of implementaion.

[creaothceann]

For instance, any language that allows using "absolute" such as FPC (or its assembler equivalent "org") cannot deterministically solve the nil pointer problem

absolute are RARE and easily searchable in source code

It goes beyond absolute. Casting one thing to another has the same potential. Also, taking the address of something and manipulating that address in some way, possibly with values only available at runtime, defeats checks at compile time. The only way you can protect important variables is by allocating them in the implementation part of a unit (or at runtime in extra pages aquired via the OS) and providing access only via procedures/functions/properties.

[AlexK]

So Absolute is NOT rare.

Code: Pascal  [Select][+][-]

1. procedure TMyForm.EditableChange(Sender: TObject?); // "?" means argument can be NIL
2. var
3.   edit: TEdit absolute Sender;
4.   memo: TMemo absolute Sender;
5. begin
6.   // Sender declared as a NILable parameter, it must be checked for NIL value before use.
7.   // compiler should emit error asking for Assigned(Sender) or Sender<>NIL block
8.   if Sender is TEdit then
9.   begin
10.     edit.Text := Uppercase(edit.Text);
11.   end
12.   else if Sender is TMemo then
13.   begin
14.     memo.Text := Uppercase(memo.Text);
15.   end;
16. end;

Here all these IF-ELSEs must be wrapped in outer IF Assigned(Sender) block.
Inside that block Sender is promoted by compiler to TObject without "?".

If this method was defined as TMyForm.EditableChange(Sender: TObject) where Sender is non-NILable parameter(no "?"), then compiler would reject any invocation with NILable argument, if it's not checked for <>NIL before invocation.

[440bx]

I have a question about the non nil-able feature. 

If some variable is pointing to some block of memory somewhere, what value is assigned to that variable when the memory block is freed ? or the fact that it is non nil-able means the block of memory can never be freed (except by the O/S when the app ends) ?  Additionally, before the address of a dynamically allocated block of memory was assigned to it, what value did it have if it couldn't be nil ?

How does Dart deal with those situations ? (I watched the video and read the intro to the language in the web site but... obviously that is quite insufficient to have a reasonable grasp on the language.)

Seems to me there's got to be a way to coerce a non nil-able variable into being nil and once that is done then it has all the problems associated with nil variables (particularly if the compiler believes its value cannot be nil.)

I must be missing something...

[AlexK]

If some variable is pointing to some block of memory somewhere, what value is assigned to that variable when the memory block is freed ? or the fact that it is non nil-able means the block of memory can never be freed (except by the O/S when the app ends) ?  Additionally, before the address of a dynamically allocated block of memory was assigned to it, what value did it have if it couldn't be nil ?

How does Dart deal with those situations ? (I watched the video and read the intro to the language in the web site but... obviously that is quite insufficient to have a reasonable grasp on the language.)

Dart has GC, no memory management.
"Sound Null Safety" is separate from memory management.
When a non-nullable variable is declared without initialization it must be annotated with "late" modifier and internally it is inited to null(hidden), and at each usage of that var in function body compiler inserts a run-time null-check that raises exception if var is null. Modifier "late" means - verify at run-time.
Compiler advises at the point of usage of such "late" variable that it may raise an exception if you forgot to initialize it - "you better wrap it in TRY block".

In FPC a variable may become a dangling reference even though not NIL, it's a possible "use after free" error. As usual in Object Pascal code.
"Sound Null Safety" is not about memory management.

Seems to me there's got to be a way to coerce a non nil-able variable into being nil and once that is done then it has all the problems associated with nil variables (particularly if the compiler believes its value cannot be nil.)

In Dart, no.
FPC has VAR parameters.
Declarations like this with typeless VAR parameter: FreeAndNil(var obj);
There could be special case for "?" without type: FreeAndNil(var obj?); , and compiler must not accept non-NILable argument for such VAR parameter.