OSDev.org

Brendan wrote:Ah - now I understand. The underscore character on line 70 ("_ -> /* no rsdt */") is your renamed NULL.

Actually, no. I don't understand the line above it ("real_rsdt: acpi_rsdt* -> parse_acpi_tables(real_rsdt)") which looks like it creates a variable called "read_rsdt" of type "acpi_rsdt*" and assigns the value returned by "parse_acpi_tables(real_rsdt)" to the variable. In C syntax it'd be "acpit_rsdt *read_rsdt = parse_acpi_tables(real_rsdt);", and you'd get a warning about using an uninitialised variable as the argument to "parse_acpi_tables()".

if (optional_rsdt) {
   acpi_rsdt *real_rsdt = optional_rsdt;
   parse_acpi_tables(real_rsdt);
}
else {
   /* no rsdt */
}

Brendan wrote:How does the "controller <= madt->controllers[-1]&;" make sense? Should I translate it into "stop looping if the starting address of the current controller is not lower than or equal to the starting address of the last entry in a heterogeneous array that isn't a heterogeneous array"?

Wouldn't it make more sense to do "stop looping if the address of the "length" field in the controller structure would be past the end of the parent "acpi_madt" structure; and (if the first check passes and you can safely use the length field of the controller structure) also stop looping if the "controller start address plus controller length field" is beyond the size of the parent acpi_madt structure"?

Brendan wrote:Given a correct RSDT? Nobody said it's a correct RSDT.

Brendan wrote:I don't think that the ability to do compile time enforcement of explicit run-time checking is realistic either (another "sounds easy to do until you attempt to implement a compiler that does it" feature).

Rusky wrote:

Brendan wrote:Actually, no. I don't understand the line above it ("real_rsdt: acpi_rsdt* -> parse_acpi_tables(real_rsdt)") which looks like it creates a variable called "read_rsdt" of type "acpi_rsdt*" and assigns the value returned by "parse_acpi_tables(real_rsdt)" to the variable. In C syntax it'd be "acpit_rsdt *read_rsdt = parse_acpi_tables(real_rsdt);", and you'd get a warning about using an uninitialised variable as the argument to "parse_acpi_tables()".

It's pattern matching- the underscore is like a default label in a switch statement. It means "anything not matched above," while the line above it means "put optional_rsdt in the new variable real_rsdt if it 'fits' in that type." It's how I extracted the value from optional_rsdt- the match statement is a null check. Because you're allergic to functional programming, which I obviously shouldn't have mentioned, here's the C syntax:

Code: Select all

if (optional_rsdt) {
   acpi_rsdt *real_rsdt = optional_rsdt;
   parse_acpi_tables(real_rsdt);
}
else {
   /* no rsdt */
}

Rusky wrote:madt->controllers is a byte array with its contents being cast to different-sized structures, not "a heterogeneous array that isn't a heterogeneous array." But yes, it would make more sense to check if the length field of the current controller goes past the madt structure. That would be caught by the compiler in this imaginary language. Would it be caught in C?

Rusky wrote:

Brendan wrote:Given a correct RSDT? Nobody said it's a correct RSDT.

If you can't rely on the length fields of the ACPI structures, you're screwed anyway and you'd get the same checksum result no matter how you write the program. At that point, the problem is in the firmware. Besides, as we all know this is a systems programming language and the goal is not 100% memory safety, just an improvement over the brain-dead type checker that is C's.

Rusky wrote:

Brendan wrote:I don't think that the ability to do compile time enforcement of explicit run-time checking is realistic either (another "sounds easy to do until you attempt to implement a compiler that does it" feature).

I've already explained how this is possible, but that discussion got sidetracked onto functional programming because you're allergic to academia and refuse to look at research papers that explain the details.

public class Person {
    private int age;                  // Stupid java doesn't support unsigned integers...

    Person(int newAge) {
        age = newAge;
    }
}

Brendan wrote:Ah - it's just confusing when the syntax looks like you're creating a new variable and not doing "case" or pattern matching at all. What makes it more confusing is that "->" is used to refer to a field in a structure (e.g. "table->length"). Giving symbols multiple meanings (where meaning depends on context) is something I don't like in any language (including '&' and "*' in C).

Brendan wrote:Anyway, basically what you're saying is that "acpi_rsdt*" pointer type doesn't accept NULL and the "acpi_rsdt?" pointer type does, so the matching works by checking to see if the pointer is NULL in an obfuscated way.

What if the 32-bit pointer is 0xFFFFFFFF - would the compiler think it's a valid pointer? What if the kernel is 64-bit?

Brendan wrote:It would be caught in imaginary C, but not real C...

Brendan wrote:You can at least check if the length field is large enough for a valid (required) header, and is below an arbitrary maximum (e.g. is a 3 GiB RSDT likely to be sane?). A good assembly or C programmer would check these things (after being kicked in the groin enough times, you learn to protect your groin).

Brendan wrote:Consider this code (Java):
...
Now write a compiler that generates a "You need an explicit check" error for the bug in the code above.

Rusky wrote:In the language I'm proposing, you would. C and C++, with all warnings enabled, don't even complain about "unsigned int a = -5;".

Rusky wrote:

Brendan wrote:Consider this code (Java):
...
Now write a compiler that generates a "You need an explicit check" error for the bug in the code above.

What explicit check? You didn't tell the compiler you wanted age to be non-negative. In the language I'm proposing, you would. C and C++, with all warnings enabled, don't even complain about "unsigned int a = -5;".

Solar wrote:I beg to differ. -Wconversion has been around a while.

turdus wrote:@Brendan, Rusky: I think what you're talking about is supported by ADA95 language. It also has a runtime checker though (compile time checking is simply not enough), for situations like

Code: Select all

unsigned int age=5;
unsigned int delta=0;
delta=somefunction(); //returns 10 when executed under some circumstances
age-=delta;

Here's the manual on how to do this in Ada95, with some examples: http://www.adahome.com/rm95/rm9x-03-02-02.html
Ada allows to be more precise if you want:

Code: Select all

subtype age is Integer range 0..110;
subtype grownupage in age range 18..110;

This will throw a Constraint_Error exception if you try to load a value out of range into a variable of type age on execution, and won't compile if it happens in a declaration.

Brendan wrote:If I can tell the compiler I want age to be non-negative, why can't I tell the compiler I want age to be within the range 0 to 200 (and then not bother telling the compiler if it's signed or unsigned; or char, short, int or long)? If I can tell the compiler I want a variable to be within a certain range, why can't I do the same with pointers (e.g. "acpi_rsdt* must be in the range from 1 to (0x100000000 - sizeof(acpi_header))")?

berkus wrote:

Brendan wrote:If I can tell the compiler I want age to be non-negative, why can't I tell the compiler I want age to be within the range 0 to 200 (and then not bother telling the compiler if it's signed or unsigned; or char, short, int or long)? If I can tell the compiler I want a variable to be within a certain range, why can't I do the same with pointers (e.g. "acpi_rsdt* must be in the range from 1 to (0x100000000 - sizeof(acpi_header))")?

So you DO want dependant types now?

Solar wrote:I beg to differ. -Wconversion has been around a while.

int foo = 123;
unsigned int bar = foo;

Brendan wrote:I don't see it as dependant types - the type of a variable doesn't depend on the variable's value (only the variable's range).

Rusky wrote:

Brendan wrote:I don't see it as dependant types - the type of a variable doesn't depend on the variable's value (only the variable's range).

That's what dependent types are. The type doesn't have to depend on the variable's value, just on a value. Arrays with their length in the type are dependent types. Integers with a specific range are dependent types (although generally only when it's more specific than whatever happens to be built-in to the processor). It's nice to know we agree on something.

• Variables (including pointers) should have ranges
• Using the same symbols for different things is bad (e.g. '*' and '&' in C)
• Functions should be able to return multiple values

• Unless there's a good reason, the syntax should be similar to whatever people are already familiar with (mostly "C like" syntax).
• For any new technology (including languages and operating systems), the benefits of that new technology need to outweigh the cost of changing from old technology (retooling, retraining, etc).
• Functional programming is imperative programming with an additional set of restrictions (and work-arounds for the restrictions), where these additional restrictions (and work-arounds) are intended to avoid common problems with imperative programming; but the restrictions are often worse than the problems they intend to avoid because:
  • It causes too much change in syntax
  • It causes too much change in the way programmers have to think
  • The benefits are negligible because programmers are already comfortable dealing with most of the problems that functional programming attempts to solve (everything except concurrency)
  • There's better ways to handle concurrency
• The biggest problem with modern languages is that they're text based. You should be able drag and drop icons directly into something like a class diagram to create a program's logic. Note: I mean honestly, computers only ever do about 15 simple operations (call, return, jmp/goto, branch/if, loops, add, subract, multiply/shift left, divide/shift right, not, and, or, xor, copy) - why the hell is programming so freaking complicated to begin with!

Brendan wrote:Doh. From the wikipedia article I assumed that "a dependent type is a type that depends on a value" (and therefore wasn't a type that depended on a range of many possible values, because "a value" isn't "a range of values").

Brendan wrote:Let's draw up a summary then...

Brendan wrote:

• Unless there's a good reason, the syntax should be similar to whatever people are already familiar with (mostly "C like" syntax).
• For any new technology (including languages and operating systems), the benefits of that new technology need to outweigh the cost of changing from old technology (retooling, retraining, etc).

• Text-based programming has problems caused by its free-form nature that don't exist in well-designed GUI-based programming.

Brendan wrote:

• Functional programming is imperative programming with an additional set of restrictions (and work-arounds for the restrictions), where these additional restrictions (and work-arounds) are intended to avoid common problems with imperative programming; but the restrictions are often worse than the problems they intend to avoid because:
  • It causes too much change in syntax
  • It causes too much change in the way programmers have to think
  • The benefits are negligible because programmers are already comfortable dealing with most of the problems that functional programming attempts to solve (everything except concurrency)
  • There's better ways to handle concurrency

Brendan wrote:Functional programming is imperative programming with an additional set of restrictions (and work-arounds for the restrictions), where these additional restrictions (and work-arounds) are intended to avoid common problems with imperative programming; but the restrictions are often worse than the problems they intend to avoid because:

Brendan wrote:The biggest problem with modern languages is that they're text based. You should be able drag and drop icons directly into something like a class diagram to create a program's logic. Note: I mean honestly, computers only ever do about 15 simple operations (call, return, jmp/goto, branch/if, loops, add, subract, multiply/shift left, divide/shift right, not, and, or, xor, copy) - why the hell is programming so freaking complicated to begin with!

NickJohnson wrote:All you need for real functional programming is a) closures, b) garbage collection, and c) proper lexical scoping.

NickJohnson wrote:

Brendan wrote:The biggest problem with modern languages is that they're text based. You should be able drag and drop icons directly into something like a class diagram to create a program's logic. Note: I mean honestly, computers only ever do about 15 simple operations (call, return, jmp/goto, branch/if, loops, add, subract, multiply/shift left, divide/shift right, not, and, or, xor, copy) - why the hell is programming so freaking complicated to begin with!

Aaahhh! The pain! Why would that ever be faster than just typing? Text is a type of image too, you know, if you bother to format it correctly. It's also very transparent.

Brendan wrote:Now try to explain why programming is the only "engineering like" profession that uses text.