OSDev.org

Hi,

bwat wrote:

Brendan wrote: Of course someone could also simply not bother supporting any or all of it (e.g. decide that the maths library is a third-party thing that isn't part of their new standard). In this case, I'm sure it won't take anyone very long to implement nothing.

I wouldn't support it in a new OS. One of the reasons I wrote my own was because I found too many differences between the results of elementary functions across different platforms. Now I get the same result regardless of platform.

That's a good reason not to include it in the standard library at all - different people want mutually exclusive things (fast, slow with guaranteed minimum and maximum precision, or even slower arbitrary precision rational numbers using complex data types where using "float" and "double" is unsuitable).


Cheers,

Brendan

BMW wrote:

rdos wrote:I'd remove the error-codes all together, replacing them with success (TRUE) and failure (FALSE).

I wouldn't. There's nothing worse than something simpy failing with no error code.

That's what you use the debugger for. The error codes are only meaningful during development, and when you can step into syscalls with your debugger, you don't need the OS' version of what went wrong.

If starting a program fails, I as a user find it helpful if I get "out of memory", "file not found", "permission denied" or "I/O error" rather than just "could not start program". I would do different things depending on the error message I get.

Kevin wrote:If starting a program fails, I as a user find it helpful if I get "out of memory", "file not found", "permission denied" or "I/O error" rather than just "could not start program". I would do different things depending on the error message I get.

All of the reasons except "file not found" are non-fixable.

- Permission denied is something that never should happen
- Out of memory shouldn't happen (modern OSes use virtual memory)
- I/O error is non-recoverable, and if the OS uses demand-load, it won't be detected until the program already executes

That leaves "file not found" as the only relevant reason, and one reason doesn't require error-codes.

So should fail because / was not found?
Edit: Sorry. Didn't notice it was a program-start special case. But still, though, I don't quite understand what you mean.

I agree with people above. Errno is messy, but I believe error codes are a necessity.

The differences between file streams and file descriptors is something I'd look at too...

rdos wrote:All of the reasons except "file not found" are non-fixable.

Non-fixable or don't happen? Anyway, it should be clear that this was only an example, and as I'm lazy based on the first few POSIX errno values that I found and sounded applicable. It's easy enough to find other examples.

- Permission denied is something that never should happen

Wait, so why do you even implement permission checks if it can't happen? Well, or do you think nobody needs new-fashioned stuff like permissions?

- Out of memory shouldn't happen (modern OSes use virtual memory)

It needs to be backed by something, and even if you claimed that you can have a basically infinite swap disk, there are some good reasons to disallow overcommitting memory (this is one of the things that you get wrong no matter what you do...)

- I/O error is non-recoverable, and if the OS uses demand-load, it won't be detected until the program already executes

Is it? Let me plug in the network cable and suddenly that file on the network will be accessible again...

Also, on most OSes I would expect that at least some data must be read before the program executes. And if it's only the header of the binary format. (While we're at it, it could also be a binary format that the OS doesn't understand. Another type of error.)

Kevin wrote:Wait, so why do you even implement permission checks if it can't happen? Well, or do you think nobody needs new-fashioned stuff like permissions?

Right. I don't implement permissions of any sort, so it cannot happen.

Kevin wrote: It needs to be backed by something, and even if you claimed that you can have a basically infinite swap disk, there are some good reasons to disallow overcommitting memory (this is one of the things that you get wrong no matter what you do...)

I don't implement swap disks either. Those are designs of another century that are best avoided.

When physical memory is exhausted, and no memory can be stolen from disk buffers, that's it. You won't get any further, and error codes won't help you.

Kevin wrote: Also, on most OSes I would expect that at least some data must be read before the program executes. And if it's only the header of the binary format. (While we're at it, it could also be a binary format that the OS doesn't understand. Another type of error.)

That's also non-recoverable. No error codes in the world could convert a non-executable file, or an executable file the loader doesn't understand, into something that suddenly can run.

rdos wrote:When physical memory is exhausted, and no memory can be stolen from disk buffers, that's it. You won't get any further, and error codes won't help you.

So if you run out of memory, and something fails, you waste time debugging it when you could have known straight away that you were out of memory?

Owen, in the struct you wrote representing a string, I'd suggest to have length before the char pointer and not the other way around.

Jezze wrote:Owen, in the struct you wrote representing a string, I'd suggest to have length before the char pointer and not the other way around.

Why?

bwat wrote:

Jezze wrote:Owen, in the struct you wrote representing a string, I'd suggest to have length before the char pointer and not the other way around.

Why?

Alignment?

Knowledge that the two addresses are always a fixed distance apart meaning more efficient code?

iansjack wrote:

bwat wrote:

Jezze wrote:Owen, in the struct you wrote representing a string, I'd suggest to have length before the char pointer and not the other way around.

Why?

Alignment?

On the architectures that I program on, pointers are always a machine word in width so having an integral type, of whatever length, after a pointer will always be aligned. I'm assuming Jezze isn't spending alot of time on, to me, exotic architectures.

iansjack wrote:Knowledge that the two addresses are always a fixed distance apart meaning more efficient code?

I'm not seeing what you're getting at here. Can you give an example?

BMW wrote:

rdos wrote:When physical memory is exhausted, and no memory can be stolen from disk buffers, that's it. You won't get any further, and error codes won't help you.

So if you run out of memory, and something fails, you waste time debugging it when you could have known straight away that you were out of memory?

You are never out of virtual memory, so whatever the requirements of the application in terms of virtual memory, they are always met. The problems comes later when virtual memory needs to be mapped to physical memory. And it is not only the static code and data, but more typically calls to malloc/new which could cause physical memory to become exhausted, and you cannot determine at load time if the application would need 1k or 4G of physical memory from malloc.

bwat wrote: On the architectures that I program on, pointers are always a machine word in width so having an integral type, of whatever length, after a pointer will always be aligned. I'm assuming Jezze isn't spending alot of time on, to me, exotic architectures.

If the character part comes first then it will need padding to ensure that the length field is aligned. Pointers are a machine word width, but characters seldom are. If the length field comes first then you just have to ensure that the struct address is aligned.

bwat wrote: I'm not seeing what you're getting at here. Can you give an example?

Knowing the address A of the struct the compiler knows that the length field is at A and the character field is at A + 4 (say). But if the character field comes first then it knows that the character field starts at A but has to compute the address of the length field. It is also marginally easier to manipulate strings (change length, concatenate, copy, etc.) if both fields are always at fixed positions relative to the struct address.

Small differences perhaps but, other things being equal, why not choose the most efficient representation.

iansjack wrote:

bwat wrote: On the architectures that I program on, pointers are always a machine word in width so having an integral type, of whatever length, after a pointer will always be aligned. I'm assuming Jezze isn't spending alot of time on, to me, exotic architectures.

If the character part comes first then it will need padding to ensure that the length field is aligned. Pointers are a machine word width, but characters seldom are. If the length field comes first then you just have to ensure that the struct address is aligned.

bwat wrote: I'm not seeing what you're getting at here. Can you give an example?

Knowing the address A of the struct the compiler knows that the length field is at A and the character field is at A + 4 (say). But if the character field comes first then it knows that the character field starts at A but has to compute the address of the length field. It is also marginally easier to manipulate strings (change length, concatenate, copy, etc.) if both fields are always at fixed positions relative to the struct address.

Small differences perhaps but, other things being equal, why not choose the most efficient representation.

But Owen's struct was:

Owen wrote: struct { char* string; size_t length}

with the characters stored outside the struct.