OSDev.org

Candy wrote:

Brynet-Inc wrote:

nick8325 wrote:Sure, and if you want to travel half-way across the world you can walk. It doesn't mean it's a good idea...

Who wants to travel? boring...

Agree with nick8325 (that's one of the least original nicknames I've ever seen). If I can write intelligent C++ code that does something in 1000 lines and somebody else can write intelligent C code that does the same in 10000 lines, I'm still off better, especially on the maintenance level. Why use C if you can use assembly and why use assembly when you can use machine language? BA0A00B80900CD21EBFE51454424 (run as COM file in windows/dos).

It was only an opinion.. I shall include C++ next time.

But in my humble opinion, I don't see a need to use a language other than C or ASM.. Can't test that code.. Wouldn't use Windows/DOS if my life depended on it.

Brynet-Inc wrote:

Candy wrote:Agree with nick8325 (that's one of the least original nicknames I've ever seen). If I can write intelligent C++ code that does something in 1000 lines and somebody else can write intelligent C code that does the same in 10000 lines, I'm still off better, especially on the maintenance level. Why use C if you can use assembly and why use assembly when you can use machine language? BA0A00B80900CD21EBFE51454424 (run as COM file in windows/dos).

It was only an opinion.. I shall include C++ next time.

But in my humble opinion, I don't see a need to use a language other than C or ASM.. Can't test that code.. Wouldn't use Windows/DOS if my life depended on it.

The point wasn't about C++ in specific.

Candy wrote:

Brynet-Inc wrote:

nick8325 wrote:Sure, and if you want to travel half-way across the world you can walk. It doesn't mean it's a good idea...

Who wants to travel? boring...

Agree with nick8325 (that's one of the least original nicknames I've ever seen). If I can write intelligent C++ code that does something in 1000 lines and somebody else can write intelligent C code that does the same in 10000 lines, I'm still off better, especially on the maintenance level. Why use C if you can use assembly and why use assembly when you can use machine language? BA0A00B80900CD21EBFE51454424 (run as COM file in windows/dos).

Yeah. But the thing I don't understand, is why everyone is using such low level languages to build everything. C and assembly are great, but when your writing programs using abstract ideas (That is, concepts that have no relation to how the machine operates.) why not use something like Lisp and other such languages? Your simply wasting time writing such things in C or (gasp) assembly.

PS: Who doesn't want to travel? Maybe it's just that I've never really traveled that far from home...

Edit: This was supposed to go up like 2 posts...I just type slow apparently...

Alboin wrote: Yeah. But the thing I don't understand, is why everyone is using such low level languages to build everything. C and assembly are great, but when your writing programs using abstract ideas (That is, concepts that have no relation to how the machine operates.) why not use something like Lisp and other such languages? Your simply wasting time writing such things in C or (gasp) assembly.apparently...

Cross-platform compatibility goes way up with C (at least for me, I also do microchip programming, and well, my compiler supports C) . I did write major parts of my OS in asm also, it keeps my kernel compact, and the interface fast. I don't consider writing things in assembly a waste of time, but it depends on your target. Check out menuet, fits on a floppy, full gui, network, media player, etc. Imagine if that was written in c, C++ or lisp, do you think it'd still fit on a floppy? I doubt it, i'm sure it'd of grown in size much faster (granted, the majority of the size is the media files, so if they got rid of some eye candy you could probably do such a thing). Point is, if your target is low compatibility, low footprint, use asm, if it's high compatibility and relatively low footprint, use C (not sure how many microchips support lisp, or if you'd need to run it as an interpreter, which is way to slow for kernel functions imho), if you don't care about footprint, but want great code reuseability, use a higher level/more abstract language.

Anyways, back to the original discussion, I don't think the C library really needs to be updated, you can add any functionality as you'd like, adding more standards just means more bloat/useless things to implement that aren't always required. Maybe a way to do templates, or a nicer/more convenient macro definition, like define a function as a macro (ala, inline, but always make it inline, don't leave this up to the compiler).

C's standard library sucks. I would redo everything that has anything to do with I/O, as a start.

If I could redesign the C standard library, I would not change a thing.

The whole point about the standard C library is that it is standarized, agreed upon, supported by the system vendors. No matter which system you are on, you can count on strcpy() being there in <string.h> and doing the exact same thing as on any other system.

The library as it is has been the result of a long, painstaking process driven by people much more competent than us here. It's been around for almost 18 years now.

Yes, the standard gets fuzzy around the edges ("implementation-defined"...), and some things aren't as elegant as they could be. But you have to realize that C was not a "lab language" designed on a clean slate, and that there had been well over a decade of library work already done by the time the C standard committee did its work.

Go ahead and design a C library that is better than the standard one. There are dozens around already, but that should not discourage you. But you will not, cannot, and should not "redesign" the standard library, which isn't about being omnipotent, "slick" or even "easy", but about the common denominator of all systems supporting a C compiler.

It sounds like you lack imagination, the whole point about "if you could redesigning the standard library", is that it would still be the standard and widley used.
If you did find that time&space wormhole and did have a chance of changing the standard, wouldn't you change anything?

Well, I for one would get rid of strncpy and strncat and replace those with strlcat/strlcpy. Also, all string functions should take the size of the buffer as an argument.

bubach wrote:If you did find that time&space wormhole and did have a chance of changing the standard, wouldn't you change anything?

Ahhh... now it makes more sense.

Well, most of the "bad" functions in there have been included in the standard for reasons of downward compatibility / prior art, so I would need a wormhole for everyone who wrote a C lib prior to the standard.

I don't agree with Ztane, for one. I think it is neat to have size-checking and not-size-checking versions of the string functions. If you know a string fits the buffer (e.g., because you have checked its size before), doing a copy without checking speeds things up. strncpy() is a piece of BS, however.

I also don't agree with Yayyak about the "weird" names of the printf() / scanf() variants. "v" means you pass va_arg instead of ..., "s" means you are working on a string instead of a stream, "f" means you define the stream instead of using stdin / stdout defaults, "n" means you do buffer-checking. That is consistent throughout the library.

I would probably try to get locale and wide-char support into the mainstream headers (<stdio.h> and <string.h>) so that US coders get to realize that the whole world isn't ASCII-7, right from the beginning, so the rest of the world doesn't have to retro-fit all that.

I would add all the stuff that was introduced with C99 and the TR's into the first standard, so we'd have <stdint.h> and <iohw.h> etc. for 18 years already... as a byproduct, we'd have <stdint.h> and long long in C++, too...

And if that wormhole would reach even further back, I'd force system engineers to make text == binary on all systems, at gunpoint if necessary because it's a bloody nuisance to implement a lib that differentiates between the two, believe me.

But all in all, I think the standard lib - especially since C99 - is a pretty decent job and doesn't require much changing. Now, if only the Java / .NET people would stop comparing it to their "standard" libraries...

What about an environment like Plan 9? I checked that out a while ago and it had some different ideas. (Which isn't exactly a bad thing.) Like, full Unicode support in the kernel, the idea that all things where files (Yes, even the window.), and the 9P network system.

It's like that when it was being though out, the creators actually were thinking that, "Hey! it's not 1972! We have color monitors and more than 4k of RAM!!!!!!!".

Although it's an operating system itself, I think some of those ideas might fit nicely in a C standard, or UNIX's in general.

Alboin wrote:Like, full Unicode support in the kernel...

In my mind, I cannot find a place for unicode support in the kernel... maybe I'm just dense, but I feel as if Unicode is a userspace thing...

...the idea that all things where files...

One of the biggest design follys of UNIX, IMHO. Many things can be made to look and behave like files, or rather, streams. But things that aren't shouldn't be forced to look like it. As soon as a metaphor isn't consistent, I wouldn't try it.

UNIX devices, for example. All things are files, but the files in /dev/ are different because you can call ioctl() on them, and you should create them with mknod instead of touch... yes, sure, very intuitive and consistent metaphor.

Although it's an operating system itself, I think some of those ideas might fit nicely in a C standard, or UNIX's in general.

Be very careful: The C standard is not about UNIX. It originated on that system, but if it were "only" UNIX, it would be much simpler (and wouldn't work too well on other systems)...

I believe in Bruce Lee: Take whatever works, and make it your own. That includes, leaving behind what doesn't work. There are things to be learned in Plan 9, just as there are things to be learned in Mac OS, Linux, AmigaOS, and (gasp!) Windows...

Solar wrote:

...the idea that all things where files...

One of the biggest design follys of UNIX, IMHO. Many things can be made to look and behave like files, or rather, streams. But things that aren't shouldn't be forced to look like it. As soon as a metaphor isn't consistent, I wouldn't try it.

UNIX devices, for example. All things are files, but the files in /dev/ are different because you can call ioctl() on them, and you should create them with mknod instead of touch... yes, sure, very intuitive and consistent metaphor.

Actually, from what I've read Plan 9 goes farther with the file design. (Therefore creating more consistency.) For example, processes are, themselves files and are located in the /proc directory in Pan 9. This allows you to do almost anything you can do with files to processes.

Solar wrote:In my mind, I cannot find a place for unicode support in the kernel... maybe I'm just dense, but I feel as if Unicode is a userspace thing...

Maybe it doesn't, but it does add consistency to the system. Does it not?

I am quite impressed with Plan 9 actually. (Acme is a wonderful editor.) I would probably add it to my main machine if it's window manager wasn't so bloody ugly.

Plan 9 itself is considered dead, But lots of UNIX-like systems have ported various aspects from it..

Linux has for example.. Some of the Plan 9 applications have been ported also.

I myself wasn't a big fan of Plan 9.. I'm quite fond of UNIX.

Brynet-Inc wrote:I myself wasn't a big fan of Plan 9.. I'm quite fond of UNIX.

?? Really?

I think Plan 9 was brilliant. They simply threw away everything from Unix. They rewrote everything. (The compilers, linkers, editors, etc.) They made a Unix for machines in the 21st century. (20th, whatever.) Meaning, they (gasp!) used the ... MOUSE! (I can hear thousands of die hard terminal fans screaming...)

I do think that a lot of what's in Unix is outdated. It just is. (This can be bluntly seen in xwindows and xlib. Although not a part of Unix per se, it shows the age of some aspects of the beast.) I just don't understand why we are still using software based of software, based of software, which was based of software from the 1970's.

This may explain why I am in osdev.

Note: I like this bold function.

I also have had a look at some of the Plan 9 material on that website. I agree that the window manager is ugly, but again, it's never going to get prettier until somebody comes along and codes prettyness into it. Catch 22.

I agree with Solar that the kernel itself shouldn't have Unicode in it. IMHO, the kernel shouldn't have any type of character set in it, not even good old ASCII (okay, maybe for the BSOD, but nothing else). It's the job of the drivers to supply all that stuff. Or at least, that's in a microkernel.