OSDev.org

Schol-R-LEA wrote:This brings to mind something else I forgot to mention: given the specific address used in the example, I am guessing that the correct type declarations probably should be more along the lines of:
[...]
This syntax is just something off of the top of my head, but it should give you a general sense of what you could use.

Kevin wrote:

Schol-R-LEA wrote:This brings to mind something else I forgot to mention: given the specific address used in the example, I am guessing that the correct type declarations probably should be more along the lines of:
[...]
This syntax is just something off of the top of my head, but it should give you a general sense of what you could use.

Something like this, yes. The important part for making things type-safe is that your pointer knows the size of the object it points to (and if you want to do pointer arithmetics like in C, the size of the array it is part of), i.e. not just a pointer to the first u8 of the video memory, but a pointer to an array with a specific size.

u8 b[80*25] = 0x000B8000;

glauxosdever wrote:

Code: Select all

u8 b[80*25] = 0x000B8000;

u8 b[3] = { 1, 2, 3 };

Rusky wrote:How is this not a type error?

Rusky wrote:For that matter, why bother sticking with C's nonsense type syntax at all?

If the compiler can't ensure the divisor is non-zero, it will error right at compilation time.

glauxosdever wrote:Hi,

Rusky wrote:How is this not a type error?

As you showed yourself, array elements are enclosed in curly brackets. But, yes, I may pick a better syntax for this. Some ideas for this, if interested?

Rusky wrote:For that matter, why bother sticking with C's nonsense type syntax at all?

What do you suggest adopting instead?

var
    a: char;
    b: char^;

(* unlike Pascal, Modula-2 is case-sensitive, 
   and all keywords are in ALLCAPS *)
VAR        
    a: CHAR;
    b: POINTER TO CHAR;

declare
    type char_access is access character;   
    -- because Ada does not permit type equivalence, you never declare a
    -- a single variable as 'access foo', because that would make it a
    -- unique type; two variables, each declared 'access foo' but in
    -- separate declarations, would not be considered to be of the 
    -- same type.

    a: character;
    b: char_access;

simeonz wrote:Proving that a pointer is non-null could be as complex as proving that a number is always a perfect number.

simeonz wrote:Because the pointer may turn out to be non-null when the variable holds a perfect number.

Schol-R-LEA wrote:Then again, I also prefer the Algol/Pascal/Ada assignment operator := , too; it makes it clear that you are setting a value, rather than asserting equality. A left arrow or left-bracket/hyphen combination <- would make even more sense to me, though.

glauxosdever wrote:Shouldn't the programmer always check for null pointers? I would be interested to hear some examples where a programmer knows a pointer is non-null and the compiler does not.

Rusky wrote:

glauxosdever wrote:Shouldn't the programmer always check for null pointers? I would be interested to hear some examples where a programmer knows a pointer is non-null and the compiler does not.

A better idea might just be to provide a non-null pointer type that enables the compiler to enforce that no null value is ever constructed to begin with, and provide optional values some other way- an Option<T> or T? type, for example, depending on how deeply you want to integrate it into the language.

u8* range(0x00000000, 0xFFFFFFFF] ptr = something_non_null;

glauxosdever wrote:

simeonz wrote:Proving that a pointer is non-null could be as complex as proving that a number is always a perfect number.

Shouldn't the programmer always check for null pointers? I would be interested to hear some examples where a programmer knows a pointer is non-null and the compiler does not.

glauxosdever wrote:For a pointer that will never be null, the solution is to exclude the value 0 from the pointer's range. Something like...

Code: Select all

u8* range(0x00000000, 0xFFFFFFFF] ptr = something_non_null;

...can be used to define a pointer that will never be null.

Shouldn't the programmer always check for null pointers? I would be interested to hear some examples where a programmer knows a pointer is non-null and the compiler does not.

• Extend the core language with a fine-grained type system. You have to consider the utility of user-defined types and compare the trade-offs. Anything that the core types do not validate will force run-time checks.
• Provide correctness rules. But those will have limited scope, and you will have to fall back to run-time checks as well.
• Use static analysis and leave the correctness of the program open to interpretation. The programmer will not be able to asses the validity of the program independently of the compiler.

Rusky wrote:

glauxosdever wrote:For a pointer that will never be null, the solution is to exclude the value 0 from the pointer's range. Something like...

Code: Select all

u8* range(0x00000000, 0xFFFFFFFF] ptr = something_non_null;

...can be used to define a pointer that will never be null.

Seems like a lot of extra work for something that should be the default, and non-portable work at that.

u8* range(0x00000000, PTR_MAX] ptr = something_non_null;

simeonz wrote:

Shouldn't the programmer always check for null pointers? I would be interested to hear some examples where a programmer knows a pointer is non-null and the compiler does not.

A simple circular list. You will have to show that, because each node points to another node or itself, there can be no null "next" pointer while iterating.

simeonz wrote:Another example. A dynamic object is created during initialization. How do you know that the initialization has occurred at least once before the call? The programmer could know.

u8 a;

simeonz wrote:If we are not talking about simply making a more fine-grained type system, but about actual inference, the programmer cannot know that the program will be validated. That is, if I write a program and the static analysis deems it correct, the program is correct. If the static analysis cannot deliver, it is not correct. This means that the code validity depends on the dynamic choices of the compiler.

The way I see it, there are three options:

• Extend the core language with a fine-grained type system. You have to consider the utility of user-defined types and compare the trade-offs. Anything that the core types do not validate will force run-time checks.
• Provide correctness rules. But those will have limited scope, and you will have to fall back to run-time checks as well.
• Use static analysis and leave the correctness of the program open to interpretation. The programmer will not be able to asses the validity of the program independently of the compiler.

There are other options that I favor. Like making interactive environments with structured source code storage. This may offer better user experience. But this is a different method entirely.