Thread: C Portability

Originally Posted by Aparavoid

I know C is sometimes called a portable assembler but exactly how portable is it? Are there any systems where the low levelness of C is bad because the system doesn't deal with memory(or something else) the same way C does? Would a language that doesn't directly deal with memory, like Scheme, be more portable or about the same?

C is highly portable. It can be be used to program PIC controllers. Note the memory characteristics.

I'm unsure what you mean by not dealing directly with memory. But C standard makes no specifications as to how memory should be internally managed. It's up to the implementation (the compiler/linker) to defined such things given the architecture for which it is being built.

Well, there is no special requirements to my knowledge that would make the use of malloc/calloc/realloc/free incompatible with a certain architecture. The architecture doesn't need to provide any special features.

The important thing perhaps to take in consideration is that this is about how memory is used by the program. Not really how memory is deal with by the architecture. You have three types of memory usage:

Static Memory - static variables, global variables and static class members. It's memory that is allocated when the program starts and deallocated when it ends. It is said the object is allocated on static memory. However, this is not to say there is a special architecture feature to use this memory. For all matters, the term is meant to differentiate the different types of memory usage. The actual object may reside anywhere within the memory space of the system.

Automatic Memory - Called automatic because objects are created and destroyed automatically. All local objects are automatic memory and they are said to be created on the stack. But the term follows the exact same rules as above.

Free Store - It's your objects created with malloc and deallocated with free. It is said these objects reside on the heap... but again the term is just meaningful to us programmers.

As long as the architecture provides a memory space, you can use any of these types of memory because their implementation doesn't care about anything else. This is at least my understanding of the whole issue.

Just a few observations, vis the alternatives: many or most of them use compilers which are today written in C. From the looks of the wikipedia page, I would say this includes most implementations of Scheme -- some of them use C as intermediary code, and the common LISP interpreter is written in C. Of course, an executable (such as a compiler or interpreter) does not contain actual C pointers, etc, it is in asm, but I think there is probably a very intimate historical relationship between C, asm, and processor architecture. Eg, Linus Torvalds went into chip design after inventing the linux kernel, which is in C.

Basically, what I am trying to say is that the things you are concerned about ("Using pointers and having to manage allocating and freeing memory") are probably the reasons C is so portable, as opposed to being features which would restrict this.

Originally Posted by abachler

That's not entirely accurate. At least not with C. While C++ has cin/cout, C has printf/scanf which are both part of libraries. While one could say that C could simply write the byte to the appropriate area of memory, and it could, that region would be different for each architecture, making the resulting program not generally portable.

Hmmm. Altho with OS (kernel) programming not sure how much standard IO is necessary -- standard IO would seem to me something that exists once you do have a running kernel/OS. Eg, with linux, within the kernel itself non-standard, perhaps platform specific libraries are used for such, there is no printf() or fprintf(). But I'm not sure.

Originally Posted by Banned

So, was I wrong, or right?

My opinion is that you are more right than wrong. But this is debatable.

Even in the presence of a fully standard library, portability isn't guaranteed since it will always depend on the implementation on the other system. Portability across systems is dependent on portability across implementations. So, a standard library influences the ability to receive code from, or send code to, another system.

This is more evident when new additions occur to the standards and each implementation takes its sweet time to adjust their libraries and compilers accordingly. But you can also observe it on about any implementation that decides to include languages extensions to its standard library implementation.

Originally Posted by Kennedy

As for the Linux kernel not having a printf, this is not completely correct either. printk() is the name, but it _IS_ defined as a printf function. The choice for the 'k' was so that one couldn't accidentally link against GlibC as that could be "bad".

Yeah, I'm aware of that, it's in "module.h". Which I haven't looked at "module.h" but I was thinking that part of the reason for this is to provide platform specific IO, as opposed to using stdio.h, which will not work in the kernel -- altho my thinking about all this could be muddled.