rahul said:
But had networking and other libraries been standardized for C, it
would have remained same across platforms.
Many systems that C excels in targetting (embedded micros) often do not
have *any* support for network, graphics etc, (think micros in your car
engine or DVD player).
If the C Standard codified interfaces for networking or graphics they
would either have to be left out on implementations targetting these
platforms (thus non-confirming), or create stubs and no-ops for these
routines. Both will break source code portability.
The changes will be there
in implementation of libraries on various platforms but source code
portability will still be there.
Not on all platforms that C intends to target. C (at least as the ISO
Committee envisage) aspires for "maximal" portability, which
essentially means that the language be kept small and easily
implementable, so that compilers can be quickly created for new
systems. If it were to be as ambitious as say C++ or Java, this would
not be possible.
Regarding nature of the tasks, even addition of two numbers is not a
portable tasks on two platforms depending upon the opcode to be
generated, format of the executable, width of the data bus, width of
the address bus, representation (big, small-endian or the middle one
you mentioned) etc. But the underlying implementation takes care of it
so we call it portable. The same could have been done for the tasks
you were saying are inherently non-portable. In fact, Java and ports
of perl, python etc do that.
There is a very great difference (in terms of magnitude) between
implementing basic arithmetic operations and something like a portable
graphics library.
No computer language has built-in facilities for doing all possible
tasks. Each language chooses to implement a subset of tasks when it is
designed, according to the consensus that emerges from the language's
purpose and consideration of various pros and cons.
C has chosen to implement a small subset of tasks so that the language
itself can be easily and widely implemented. Other tasks are either
performed by a sequence of built-in steps or are provided by external
code (which may not be in C).
Other languages have chosen to implement a plethora of features for the
sacrifice of some portability.
It is the task of the programmer to choose the appropriate language for
a task based on availability, requirements, skills, support and so on.
Unfortunately learning only one (or a few) language and expecting it to
provide built-in routines to solve all problems is an easy trap to fall
in. In practise you'll have to mix and match code in many languages if
you want to avoid endless frustration or time wasted in reinventing the
wheel again and again.