The standard library is linked statically by default, though your binary is still an order of magnitude larger than mine for some reason. If you do dynamic linking, comparable to the default with C
QuoteThe standard library is linked statically by default, though your binary is still an order of magnitude larger than mine for some reason. If you do dynamic linking, comparable to the default with C
Just to be clear, by 'static' linking you mean shoving library code in the executable, and by 'dynamic' you mean having the library code loaded at run-time? If so, that's a bit disingenuous since the executing application still needs the same linked-in code, just that with dynamic linking you don't count it. Put all the necessary stuff in one place and see what the size is - that's what it takes to run it.
And, in fact, all other things being equal, running a single executable with dynamic linking leads to more bloat since every library function will be required regardless as to whether it's used or not. With static linking only the bits actually used get linked in (or should be).
Amusingly, until recently it wasn't even possible to write an OS in C. I know it is ridiculous, but as late a 2004 Hans Boehm had to point that out to many people in "Threads Cannot be Implemented as a Library" http://www.hpl.hp.com/techreports/2004/HPL-2004-209.htmlI think Hans Boehm is also someone who wrote an excellent article about how poorly understood the memory models of various x86 cores was (even by their own developers), and how this shot holes in most threading systems. I don't see how this makes running C code an impediment to progress.
Strawman question!
Amusingly, until recently it wasn't even possible to write an OS in C. I know it is ridiculous, but as late a 2004 Hans Boehm had to point that out to many people in "Threads Cannot be Implemented as a Library" http://www.hpl.hp.com/techreports/2004/HPL-2004-209.htmlI think Hans Boehm is also someone who wrote an excellent article about how poorly understood the memory models of various x86 cores was (even by their own developers), and how this shot holes in most threading systems. I don't see how this makes running C code an impediment to progress.
Strawman question!Try reading what I wrote again without the bad attitude. Hans Boehm is an important figure who pointed out a lot of sloppy thinking related to how poorly understood hardware memory models interact with threading and multi-CPU environments. I don't see how this makes running C code an impediment to progress. Single threaded C code has no real issues. Mullti-threaded C code certainly inhibits change, but so does every other kind of multi-threaded code. They are ALL incompatible with change.
After this project, I'd like to play with a simple OS not written in C/C++.
I mean, I like to compile (modify?) some good piece of code, upload something on a board (68k? modern STM32?), and play with it.
Ada? Pascal? Modula2? Oberon? Assembly? All welcome
With dynamic linking, every program running on the system at the same time can use the same physical RAM copy of the dynamic libraries.
With dynamic linking, every program running on the system at the same time can use the same physical RAM copy of the dynamic libraries.
Only the code and constant data part. All the rest is not shared.
Non-constant data (variables) can be a big part of a library.
So, in practice, the memory-savings by using dynamic linking is not as big as hoped for.
After this project, I'd like to play with a simple OS not written in C/C++.
I mean, I like to compile (modify?) some good piece of code, upload something on a board (68k? modern STM32?), and play with it.
Ada? Pascal? Modula2? Oberon? Assembly? All welcome
Other than assembly language, those are all isomorphic to C/C++, certainly the GNU version if not the standard (e.g. with nested functions possible). They differ only in surface syntax, the standard library, and things such as how visibility of names is controlled. Generate code is identical. The same goes for Lisp.
With dynamic linking, every program running on the system at the same time can use the same physical RAM copy of the dynamic libraries.
Only the code and constant data part. All the rest is not shared.
Non-constant data (variables) can be a big part of a library.
So, in practice, the memory-savings by using dynamic linking is not as big as hoped for.Right. Most big things are big because of the working data, not the code. I have libraries of a couple of hundred k, that take up gigabytes on running systems, because so many instances are used, and each instance has a lot of working data.
I'm not sure the original intent of dynamic link libraries was mostly about memory saving. The ability to swap out one bug fixed library, and fix every app using it, was an important driving force. That's more an area where the hype didn't work out well, as we fell into a DLL hell that the industry has taken a long time to cilmb out of.
With dynamic linking, every program running on the system at the same time can use the same physical RAM copy of the dynamic libraries.
Only the code and constant data part. All the rest is not shared.
Non-constant data (variables) can be a big part of a library.
So, in practice, the memory-savings by using dynamic linking is not as big as hoped for.
After this project, I'd like to play with a simple OS not written in C/C++.
I mean, I like to compile (modify?) some good piece of code, upload something on a board (68k? modern STM32?), and play with it.
Ada? Pascal? Modula2? Oberon? Assembly? All welcome
Other than assembly language, those are all isomorphic to C/C++, certainly the GNU version if not the standard (e.g. with nested functions possible). They differ only in surface syntax, the standard library, and things such as how visibility of names is controlled. Generate code is identical. The same goes for Lisp.
Really? You can get buffer overflow in Ada using the normal cliche programming style? Or access/mutate aCamel as if it was aHorse?
After this project, I'd like to play with a simple OS not written in C/C++.
I mean, I like to compile (modify?) some good piece of code, upload something on a board (68k? modern STM32?), and play with it.
Ada? Pascal? Modula2? Oberon? Assembly? All welcome
Other than assembly language, those are all isomorphic to C/C++, certainly the GNU version if not the standard (e.g. with nested functions possible). They differ only in surface syntax, the standard library, and things such as how visibility of names is controlled. Generate code is identical. The same goes for Lisp.
Really? You can get buffer overflow in Ada using the normal cliche programming style? Or access/mutate aCamel as if it was aHorse?
You don't get buffer overflows in properly-written C (or especially C++) code.
What problems there are are generally caused by using poorly designed libraries (including the convenient but dangerous standard library).
Why is everybody ignoring and not mentioning ADA, the best way that is not C/C++ to write an operating system ?
"The Army Secure Operating System (ASOS) was written almost entirely in Ada. It was designed to meet Orange Book A1 protection requirements, support Ada applications more directly, and run on a commodity Sun3. The total software was 55,000 lines of code. It even had checkpointing/restore and later a secure RDBMS."
Here, freshly declassified:
https://apps.dtic.mil/dtic/tr/fulltext/u2/a340370.pdf
https://moscow.sci-hub.se/1864/6e4bd79db1e4753ea76c251441a45133/waldhart1990.pdf
After this project, I'd like to play with a simple OS not written in C/C++.
I mean, I like to compile (modify?) some good piece of code, upload something on a board (68k? modern STM32?), and play with it.
Ada? Pascal? Modula2? Oberon? Assembly? All welcome
Other than assembly language, those are all isomorphic to C/C++, certainly the GNU version if not the standard (e.g. with nested functions possible). They differ only in surface syntax, the standard library, and things such as how visibility of names is controlled. Generate code is identical. The same goes for Lisp.
Really? You can get buffer overflow in Ada using the normal cliche programming style? Or access/mutate aCamel as if it was aHorse?
You don't get buffer overflows in properly-written C (or especially C++) code.
I wondered how long it would be until the There's No True Scotsman fallacy would rear its head! https://en.m.wikipedia.org/wiki/No_true_Scotsman
After this project, I'd like to play with a simple OS not written in C/C++.
I mean, I like to compile (modify?) some good piece of code, upload something on a board (68k? modern STM32?), and play with it.
Ada? Pascal? Modula2? Oberon? Assembly? All welcome
Other than assembly language, those are all isomorphic to C/C++, certainly the GNU version if not the standard (e.g. with nested functions possible). They differ only in surface syntax, the standard library, and things such as how visibility of names is controlled. Generate code is identical. The same goes for Lisp.
Really? You can get buffer overflow in Ada using the normal cliche programming style? Or access/mutate aCamel as if it was aHorse?
You don't get buffer overflows in properly-written C (or especially C++) code.
I wondered how long it would be until the There's No True Scotsman fallacy would rear its head! https://en.m.wikipedia.org/wiki/No_true_ScotsmanThat is an unfair statement.
Unlike C++, C has two different "modes": hosted environment and freestanding environment. The former includes the standard C library – including functions like fgets(), strcpy(), and so on –; whereas the latter is used when programming kernels and microcontrollers, often with a replacement set of functions (see Linux kernel C functions, or the Arduino environment, for examples).
Buffer overflows are intrinsic part of the C standard library, but not the C freestanding environment. It is quite possible to replace the standard C library with a completely different API, including arrays with explicit bounds and garbage collection, but keep the C compiler and syntax.
Therefore, this is not a No True Scotsman argument, because it identifies the problematic but optional half of C. I know this, because I myself am working on a "better" substitute (for my own needs and uses).
..., so now Java, Python and possibly Rust are dominant.
https://www.tiobe.com/tiobe-index/
After this project, I'd like to play with a simple OS not written in C/C++.
I mean, I like to compile (modify?) some good piece of code, upload something on a board (68k? modern STM32?), and play with it.
Ada? Pascal? Modula2? Oberon? Assembly? All welcome
Other than assembly language, those are all isomorphic to C/C++, certainly the GNU version if not the standard (e.g. with nested functions possible). They differ only in surface syntax, the standard library, and things such as how visibility of names is controlled. Generate code is identical. The same goes for Lisp.
Really? You can get buffer overflow in Ada using the normal cliche programming style? Or access/mutate aCamel as if it was aHorse?
You don't get buffer overflows in properly-written C (or especially C++) code.
I wondered how long it would be until the There's No True Scotsman fallacy would rear its head! https://en.m.wikipedia.org/wiki/No_true_ScotsmanThat is an unfair statement.
Unlike C++, C has two different "modes": hosted environment and freestanding environment. The former includes the standard C library – including functions like fgets(), strcpy(), and so on –; whereas the latter is used when programming kernels and microcontrollers, often with a replacement set of functions (see Linux kernel C functions, or the Arduino environment, for examples).
Buffer overflows are intrinsic part of the C standard library, but not the C freestanding environment. It is quite possible to replace the standard C library with a completely different API, including arrays with explicit bounds and garbage collection, but keep the C compiler and syntax.
Therefore, this is not a No True Scotsman argument, because it identifies the problematic but optional half of C. I know this, because I myself am working on a "better" substitute (for my own needs and uses).
So you think it is an acceptable argument to exclude "half" of C uses and concentrate on the less inconvenient other half?
I'd like to play with a simple OS not written in C/C++.