Re: C portability is a myth
From: Jack Klein (jackklein_at_spamcop.net)
Date: 02/15/05
- Next message: Peter Nilsson: "Re: difference between casting and atol,atoi functions"
- Previous message: Walter Roberson: "Re: Control never returns from malloc()"
- In reply to: websnarf_at_gmail.com: "Re: C portability is a myth"
- Next in thread: websnarf_at_gmail.com: "Re: C portability is a myth"
- Reply: websnarf_at_gmail.com: "Re: C portability is a myth"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Mon, 14 Feb 2005 21:38:47 -0600
On 14 Feb 2005 04:47:12 -0800, websnarf@gmail.com wrote in
comp.lang.c:
> Jack Klein wrote:
> > On 13 Feb 2005 14:13:25 -0800, "Mysidia" <mysidia@gmail.com> wrote:
> > > C is not the best at portability, according to the more
> > > modern relative definition of portability...
>
> You mean where *semantics* get added to the definition?
>
> > > Java for example is supposed to provide automatic portability
> > > (What you lose in the process is performance and some basic
> > > capabilities: things you can do portably are limited by the
> > > high level SDK available, (and sometimes the high level SDK
> > > isn't good enough)
> >
> > Except Java provides no portability at all to any platform that
> > isn't at least 32-bits with a multi-tasking GUI environment.
>
> What are you talking about? A VM can emulate multitasking -- an
> underlying OS which does so is irrelevant (in fact, I would be curious
> to know, if in fact, the Java spec *REQUIRES* the multitasking to be
> emulated, so that race conditions are limited to VM instruction
> granularity.) Interfacing with GUI environments has to be done with
> some kind of native method rig up, and again is not a gating factor in
> the ability to run Java. And 32 bits -- are you smoking something? You
> just have to present the interface, there only requirements for the
> underlying machine is that it can compute something.
>
> For example, there was a port of Java to DOS (called Kaffe, I believe.)
> You are confusing what is exposed with what is required by the
> platform.
Is there a port of Java to PIC, 8051, AVR, ST7, or any DSP in the
world? There are C compilers for all of them, C++ for some. No Java,
Perl, Lisp, Visual Basic, C#, or any other flavor of the month.
> > [...] C on the other hand, does.
>
> C requires the existence of files/stdio, and a system timer. Voting
Whatever gave you that silly, and totally wrong idea? C specifically
defines two types of implementations. A hosted environment does
indeed require stdio, a free-standing environment does not. No
implementation of C requires a system timer. There is no such
requirement in the language standard at all.
> machines can arguably be considered more secure if they do *NOT*
> contain any system timer (consider software which waits for the
> election date, or well past the start of a real election before
> enacting a "flaw" -- a little hard to do without a timer).
But your point is moot, because C does not require any sort of timer,
not in any environment. Not under any circumstances, even in a
strictly conforming hosted environment. The time() function merely
returns (time_t)-1. Period, end of story.
Heck, in 1999 I had to produce and sign documents for a variety of
systems affirming that they could not possibly have a Y2K problem
because they had no time-of-day hardware, and neither used outside
world time nor even had a method in their communications protocol of
receiving one.
> > There is a C compiler, or more likely several or dozens,
> > for virtually every processor architecture in existence,
> > from 8-bit microprocessors and microcontrollers to 64-bit
> > supercomputers.
>
> Yes, but I think the OP's point is that no pair of any such compilers
> accepts the same set of source inputs and does not generate
> semantically compatible output for the intersection of code that is
> common.
>
> > No new processor or controller is ever introduced without
> > some C compiler being available these days.
>
> I am aware of at least one smart card that was -- they implemented a
> picojava instruction set for it. Think about the complexities involved
> in architecture design and bring up -- there can't possibly be any
> since they have most of it specced out for them already.
>
> > The core of C is the most portable language in existence, has
> > been for a long time, and will be for a long time to come.
>
> You misspelled *least*. Lua, Python and Perl, for example, are *FAR*
> more portable. I think the only two languages I know of which are
> *less* portable than C are assembly and Basic.
You seem to think, even as computers of all sizes are being introduced
into almost everything, that the entire world is one problem domain.
The most recent estimates I have heard are that there are
approximately 1,000,000,000 CPUs/processors/controllers being
manufactured and used per year. Approximately 150,000,000, or about
15% of them, are the 32-bit and 64-bit processors used as the main CPU
in laptop/desk top/workstation/server applications, an extremely
narrow range of applications.
The other 85% cover a much wider range than that.
Take a good look at the computer you are using to view Google and read
and post messages. It has one CPU, Pentium or equivalent or perhaps a
PowerPC. How many other programmed execution units does it have?
One in the keyboard, one in the mouse, one in the hard disk drive, one
in the CD/DVD drive. One or more in the printer, another in the
router if you use one. Oh, don't forget one in the monitor.
If you have a common home desk top setup, your router could well have
an ARM in it, and might be running under a version of Linux, perhaps
with real time extensions. So most or all of the languages you
mention above are available for that platform, as well as for the main
computer's CPU.
As for the others, if they have anything available at all besides an
assembler available, it is a C compiler.
> ---
A proper signature line consists of "-- ", that is two dash characters
and a space. As specified by relevant RFCs. Most competent
newsreaders handle trimming automatically. Incorrect signature
delimiters are a sign of a social engineering, not a technical,
problem.
> Paul Hsieh
> http://www.pobox.com/~qed/
> http://bstring.sf.net/
-- Jack Klein Home: http://JK-Technology.Com FAQs for comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html comp.lang.c++ http://www.parashift.com/c++-faq-lite/ alt.comp.lang.learn.c-c++ http://www.contrib.andrew.cmu.edu/~ajo/docs/FAQ-acllc.html
- Next message: Peter Nilsson: "Re: difference between casting and atol,atoi functions"
- Previous message: Walter Roberson: "Re: Control never returns from malloc()"
- In reply to: websnarf_at_gmail.com: "Re: C portability is a myth"
- Next in thread: websnarf_at_gmail.com: "Re: C portability is a myth"
- Reply: websnarf_at_gmail.com: "Re: C portability is a myth"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
