portable C, posix C and windows C

[asit]

what is the difference between portable C, posix C and windows C ???

[user923005]

On Oct 7, 10:34*pm, asit <[e-mail]:

what is the difference between portable C, posix C and windows C ???

Portable means that it will compile on many platforms.
To accomplish this, you need some kind of a standard.
The ANSI/ISO C standard creates one kind of portability for C
programs.

Posix is another kind of standard. It allows some additional
fascilities to be standardized that will not work without the Posix
assumption.
http://en.wikipedia.org/wiki/POSIX

There is no such thing as Windows C. There are C compilers that run
on Windows. Mingw GCC, Microsoft and Intel all make nice C compilers
for Windows.

HTH

[asit]

user923005 wrote:

On Oct 7, 10:34�pm, asit <[e-mail]:

what is the difference between portable C, posix C and windows C ???

Portable means that it will compile on many platforms.
To accomplish this, you need some kind of a standard.
The ANSI/ISO C standard creates one kind of portability for C
programs.

Posix is another kind of standard. It allows some additional
fascilities to be standardized that will not work without the Posix
assumption.
http://en.wikipedia.org/wiki/POSIX

There is no such thing as Windows C. There are C compilers that run
on Windows. Mingw GCC, Microsoft and Intel all make nice C compilers
for Windows.

HTH

Does portable C is as faster as posix C.
I mean to say that does portable C is converted directly to assembly
language....avoiding any intermediate conversion ???

[user923005]

On Oct 7, 10:42*pm, asit <[e-mail]:

user923005 wrote:

On Oct 7, 10:34 pm, asit <[e-mail]:

what is the difference between portable C, posix C and windows C ???

Portable means that it will compile on many platforms.
To accomplish this, you need some kind of a standard.
The ANSI/ISO C standard creates one kind of portability for C
programs.

Posix is another kind of standard. *It allows some additional
fascilities to be standardized that will not work without the Posix
assumption.
http://en.wikipedia.org/wiki/POSIX

There is no such thing as Windows C. *There are C compilers that run
on Windows. *Mingw GCC, Microsoft and Intel all make nice C compilers
for Windows.

HTH

Does portable C is as faster as posix C.

Portability and speed have no real connection.

I mean to say that does portable C is converted directly to assembly
language....avoiding any intermediate conversion ???

Generally, the best optimizers process the file in several passes.

[Ian Collins]

asit wrote:

>
user923005 wrote:

>On Oct 7, 10:34�pm, asit <[e-mail]:

>>what is the difference between portable C, posix C and windows C ???

Portable means that it will compile on many platforms.
To accomplish this, you need some kind of a standard.
The ANSI/ISO C standard creates one kind of portability for C
programs.

Posix is another kind of standard. It allows some additional
fascilities to be standardized that will not work without the Posix
assumption.
http://en.wikipedia.org/wiki/POSIX

There is no such thing as Windows C. There are C compilers that run
on Windows. Mingw GCC, Microsoft and Intel all make nice C compilers
for Windows.

But windows does provide its own library extensions.

Does portable C is as faster as posix C.
I mean to say that does portable C is converted directly to assembly
language....avoiding any intermediate conversion ???

POSIX is best be viewed as an extension to the C standard library, not
an extension to the language. So in the general case, there isn't a
performance difference. There are exceptions such as constraints
imposed by threading, but you shouldn't worry about those.

--
Ian Collins.

[James Kuyper]

asit wrote:

what is the difference between portable C, posix C and windows C ???

"portable" is ill-defined. As a practical matter, portability is a
matter of degree, not an absolute yes-or-no. Some code is more portable
that other code. Very little code is portable everywhere, and most such
code is of limited utility.

Some people consider code portable if it can work as intended without
modification on every machine that has exactly the same software and
hardware configuration as the one they are using (I'm exaggerating; but
it's not as much of an exaggeration as it should be). Other people
consider code to be portable only if it works as intended under every
version of C still in use, on every platform for which a C compiler is
available (this is close to the standard that a lot of GNU code is
written to). Most people use a definition somewhere in between those two
extremes.

My own definition is that C code is portable if it would work as
intended if translated by any implementation of C while operating in a
mode that conforms fully and meaningfully to at least one version of the
official C standard. "conforms meaningfully" means that the
implementation doesn't take advantage of the abundance of weasel wording
that's present in the standard to conform to the standard in technical
sense, without actually implementing the language and library described
by that standard.

A key phrase here is "work as intended". If the behavior is intended to
be different on different platforms, then it is working as intended if
the behavior varies in the way that it's supposed to vary. This is the
key difference between my concept of "portable" and the standard's
definition of "strictly conforming". One consequence of this difference
is that it's not possible to be certain that code is "portable" by my
definition, unless you know what the intended behavior is. Strict
conformance can be verified solely by inspection of the code itself.

POSIX C code is C code that fully conforms to some version of the POSIX
standard. All of my code is POSIX C with that definition. You might
argue that it isn't truly a POSIX program unless it relies on at least
one POSIX-specific feature; I've only written a little bit of code that
qualifies as POSIX code, if you add in that requirement.

I don't write or read Windows C, so I don't feel competent to define it;
you might want to wait for a response from a Windows programmer. I would
presume that it means code which will work as intended when compiled and
executed on at least one Windows machine. You might argue that it isn't
truly a Windows program unless it relies upon at least one
Windows-specific feature.

[James Kuyper]

asit wrote:
....

Does portable C is as faster as posix C.
I mean to say that does portable C is converted directly to assembly
language....avoiding any intermediate conversion ???

The advantage of portability is that the code can be compiled on many
different machines; it has nothing to do with speed. In some cases,
making code portable is incompatible with making it fast for a
particular platform, because it means that you can't use
platform-specific features that could achieve greater speed.

[Malcolm McLean]

"asit" <li*****@gmail.comwrote in message
news:af**********************************@n1g2000p rb.googlegroups.com...

what is the difference between portable C, posix C and windows C ???

Portable C depends only on the standard library.
Posix C depends on the Posix library, which is widely available on UNIX
systems but not generally on small systems.
Windows C depends on the Microsoft Windows C API, a very rich set of library
calls to open and manage windows and do much else besides.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

[dj3vande]

In article <2d*****************@nwrddc01.gnilink.net>,
James Kuyper <ja*********@verizon.netwrote:

>asit wrote:
...

>Does portable C is as faster as posix C.
I mean to say that does portable C is converted directly to assembly
language....avoiding any intermediate conversion ???

The advantage of portability is that the code can be compiled on many
different machines; it has nothing to do with speed. In some cases,
making code portable is incompatible with making it fast for a
particular platform, because it means that you can't use
platform-specific features that could achieve greater speed.

On the other hand, portable code is easy to speed up by recompiling it
for newer and fastar machines. The closer you get to the nonportable
end of the spectrum, the harder that gets.
For ISO9899 (Standard C) + POSIX or (to a slightly lesser degree)
ISO9899+Win32, you can probably get almost all of the benefits along
this axis of using ISO9899 only, since POSIX systems tend to run on
most kinds of hardware and Win32 runs on the hardware family that's
pushing the speed envelope most aggressively. But if you have inline
x86 assembly scattered through your code, you'll only be able to take
advantage of newer/faster CPUs in one particular family (though
currently a very popular one) unless you're willing to rewrite your
code. If that inline x86 assembly was filled with speed hacks
optimized for the 386^W486^WPentium^WP-II^WP-4 architecture, you might
even end up having to rewrite it just to keep up with portable C code
compiled with a decent architecture-aware optimizer.

So if it needs to run "As fast as possible for the foreseeable future",
as opposed to "As fast as possible right now", platform-specific
features become less valuable.
dave

--
Dave Vandervies dj3vande at eskimo dot com
Is that a specific "typical 64-bit machine", or a generalized 64
bit machine?
--Walter Roberson in comp.lang.c

[dj3vande]

In article <_9*****************@nwrddc01.gnilink.net>,
James Kuyper <ja*********@verizon.netwrote:

>POSIX C code is C code that fully conforms to some version of the POSIX
standard. All of my code is POSIX C with that definition. You might
argue that it isn't truly a POSIX program unless it relies on at least
one POSIX-specific feature; I've only written a little bit of code that
qualifies as POSIX code, if you add in that requirement.

I don't write or read Windows C, so I don't feel competent to define it;
you might want to wait for a response from a Windows programmer. I would
presume that it means code which will work as intended when compiled and
executed on at least one Windows machine.

That's almost how I would define `Windows C', and I program for Windows
at my day job.
"On at least one Windows machine" is a rather weak requirement, though;
as a matter of professional pride, I would insist that Windows C code
I'm responsible for be able to compile on *any* Windows machine with
the appropriate tools, and run (and work as intended) on *any* Windows
machine (or, at least, any Windows machine meeting a well-defined and
reasonable set of additional requirements, such as "Has Windows version
at least X and at least Y amount of storage available to the program"),
not just "at least one".

You might argue that it isn't
truly a Windows program unless it relies upon at least one
Windows-specific feature.

If it doesn't rely on at least one Windows-specific feature, there's
not much point in calling it a Windows program, though it's not
strictly incorrect to do so (especially if it's intended to run on
Windows).

I would be more likely to explicitly partition it into "C" (or possibly
"portable C", if the qualifier is useful in distinguishing multiple
flavors of C under discussion), which is C code that will behave as
intended when compiled and run with any correct C implementation, and
"C+Win32", which is C code intended to be compiled and linked against
an implementation of the Win32 API which will behave as expected when
that environment is correctly implemented.
(Similarly, I would partition what you call "POSIX C" into "C" and
"C+POSIX".)
But all of this is just barely marginally on-topic here. CLC exists
for the discussion of "C", also known as "portable C"; for "POSIX C",
or "C+POSIX", or whatever you call it, there's comp.unix.programmer;
and for "Windows C" or "C+Win32" or whatever you call *that*, there's
comp.os.ms-windows.programmer.win32; and for other platforms there are
other platform-specific newsgroups...
dave

--
Dave Vandervies dj3vande at eskimo dot com
You should post to CLC or CLC++ if you are interested in having highly
qualified people help you with your code, making it correct, efficient,
hansome, suave and good with the ladies. --Brian Rodenborn in CLC

[Ian Collins]

Malcolm McLean wrote:

>
"asit" <li*****@gmail.comwrote in message
news:af**********************************@n1g2000p rb.googlegroups.com...

>what is the difference between portable C, posix C and windows C ???

Portable C depends only on the standard library.
Posix C depends on the Posix library, which is widely available on UNIX
systems but not generally on small systems.

That depends on what you define as small. Posix is supported (or even
complied to) by a number of popular RTOS.

--
Ian Collins.

[Flash Gordon]

Ian Collins wrote, On 08/10/08 07:59:

asit wrote:

>user923005 wrote:

>>On Oct 7, 10:34�pm, asit <[e-mail]:
what is the difference between portable C, posix C and windows C ???
Portable means that it will compile on many platforms.
To accomplish this, you need some kind of a standard.
The ANSI/ISO C standard creates one kind of portability for C
programs.

Posix is another kind of standard. It allows some additional
fascilities to be standardized that will not work without the Posix
assumption.
http://en.wikipedia.org/wiki/POSIX

There is no such thing as Windows C. There are C compilers that run
on Windows. Mingw GCC, Microsoft and Intel all make nice C compilers
for Windows.

But windows does provide its own library extensions.

Yes. However there can be further confusion because a number of
compilers use the C library provided by MS giving access to all the
extensions MS provide in it but other implementations use their own
implementation of the C library so whilst the probably provide full
access to the Windows API they may not provide all of the functions (or
may provide them with different names and/or semantics) as some Windows
programmers would expect.

>Does portable C is as faster as posix C.
I mean to say that does portable C is converted directly to assembly
language....avoiding any intermediate conversion ???

POSIX is best be viewed as an extension to the C standard library, not
an extension to the language. So in the general case, there isn't a
performance difference. There are exceptions such as constraints
imposed by threading, but you shouldn't worry about those.

There are also other constraints the POSIX standard puts on the compiler
itself, such as I believe the number of bits in a byte (it must be 8
which is one of the values allowed by the C standard). If programming
specifically for POSIX one might (for good reasons) take advantage of
some of these constraints.
--
Flash Gordon
If spamming me sent it to sm**@spam.causeway.com
If emailing me use my reply-to address
See the comp.lang.c Wiki hosted by me at http://clc-wiki.net/

[user923005]

On Oct 8, 1:10*pm, Ian Collins <[e-mail]:

Malcolm McLean wrote:

"asit" <[e-mail] in message
news:af**********************************@n1g2000p rb.googlegroups.com...

what is the difference between portable C, posix C and windows C ???

Portable C depends only on the standard library.
Posix C depends on the Posix library, which is widely available on UNIX
systems but not generally on small systems.

That depends on what you define as small. *Posix is supported (or even
complied to) by a number of popular RTOS.

<OT-Aside>
You can even run Posix on Windows using this:
http://www.suacommunity.com/

Unfortunately, most config.guess files have no idea what SUA is.
This is helpful in that regard:
http://git.savannah.gnu.org/gitweb/?....guess;hb=HEAD

All the windows Posix solutions have some speed bumps.
Mingw has no fork().
Cygwin has confusing usage terms.
SUA has trouble running ./configure
I guess the thing to do is get Linux if you really want Posix on PC
hardware.

IMO-YMMV
</OT-Aside>

[Ian Collins]

user923005 wrote:

I guess the thing to do is get Linux if you really want Posix on PC
hardware.

Erm no, if you want Posix on PC hardware, get (Open)Solaris.

--
Ian Collins.

[Richard Heathfield]

John H. Guillory said:

<snip>

Not to get off topic, but what would you say about someone who uses a
Windows C compiler to compile Console mode programs or graphical
"Console" programs that are basically a window opened up that outputs
standard C style printf/puts to a virtual console that looks like a
white windows window?

That sounds like "QuickWin" to me. It was a feature of early versions of
Visual C, and it sounded quite promising - "turn your console program into
a Windows program with one click of the mouse!" - but of course it turned
out to be exactly what you describe: a console window with delusions of
grandeur.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Chris H]

In message
<c4**********************************@u40g2000pru. googlegroups.com>,
asit <li*****@gmail.comwrites

>

user923005 wrote:

>On Oct 7, 10:340 what is the difference between portable C, posix C and windows C ???

Portable means that it will compile on many platforms.
To accomplish this, you need some kind of a standard.
The ANSI/ISO C standard creates one kind of portability for C
programs.

Posix is another kind of standard. It allows some additional
fascilities to be standardized that will not work without the Posix
assumption.
http://en.wikipedia.org/wiki/POSIX

There is no such thing as Windows C. There are C compilers that run
on Windows. Mingw GCC, Microsoft and Intel all make nice C compilers
for Windows.

HTH

Does portable C is as faster as posix C.

Generally (but not always) portable C is slower because you don't use
the hardware or compiler specific extensions.

>I mean to say that does portable C is converted directly to assembly
language....avoiding any intermediate conversion ???

The conversion from C to object code is in several stages, most do not
bother with assembler these days. However these passes are internal to
the compiler and not visible to the user. Not like when you invoked CC1,
cc2, cc3 , assembler and linker.

All the compilers I use are "one pass" from C to object code. The next
stage is linking

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

[Ian Collins]

Chris H wrote:

In message
<c4**********************************@u40g2000pru. googlegroups.com>,
asit <li*****@gmail.comwrites

>>
Does portable C is as faster as posix C.

Generally (but not always) portable C is slower because you don't use
the hardware or compiler specific extensions.

I disagree on two counts, you may not need any compiler specific
extensions and hardware specific extensions tend to be compiler options
rather than in the code. Compiler specific extensions tend to be
syntactic rather than performance enhancing.

--
Ian Collins.

[Chris H]

In message <6l************@mid.individual.net>, Ian Collins
<ia******@hotmail.comwrites

>Chris H wrote:

>In message
<c4**********************************@u40g2000pru .googlegroups.com>,
asit <li*****@gmail.comwrites

>>>
Does portable C is as faster as posix C.

Generally (but not always) portable C is slower because you don't use
the hardware or compiler specific extensions.

I disagree on two counts, you may not need any compiler specific
extensions and hardware specific extensions tend to be compiler options
rather than in the code. Compiler specific extensions tend to be
syntactic rather than performance enhancing.

I have to completely disagree. In most of my work you could not get a
program to run without the extensions. How do you interface to the
hardware?

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

[Ian Collins]

Chris H wrote:

In message <6l************@mid.individual.net>, Ian Collins
<ia******@hotmail.comwrites

>Chris H wrote:

>>In message
<c4**********************************@u40g2000pr u.googlegroups.com>,
asit <li*****@gmail.comwrites

Does portable C is as faster as posix C.

Generally (but not always) portable C is slower because you don't use
the hardware or compiler specific extensions.

I disagree on two counts, you may not need any compiler specific
extensions and hardware specific extensions tend to be compiler options
rather than in the code. Compiler specific extensions tend to be
syntactic rather than performance enhancing.

I have to completely disagree. In most of my work you could not get a
program to run without the extensions. How do you interface to the
hardware?

That really depends how the hardware is mapped.

--
Ian Collins.

[Richard Bos]

John H. Guillory <jo***@communicomm.comwrote:

dj******@csclub.uwaterloo.ca.invalid wrote:

>The advantage of portability is that the code can be compiled on many
different machines; it has nothing to do with speed. In some cases,

The only argument I have with this is that despite "ANSI-C" being

It's not "ANSI-C". It's ISO C, and it's been adopted by ANSI as well,
making it also ANSI C.

portable to a great number of computers and operating systems w/o
re-compiling what soever, one must take into account that it is still
not 100% portable, because of Micro Processors that have no monitors,
such that a printf() is pretty useless, nor file systems, making
fopen() kinda useless, etc...

That's why the ISO C Standard allows for freestanding implementations,
which are required to support the core language and library, but need
not support things like stdio.

On the other hand, portable code is easy to speed up by recompiling it
for newer and fastar machines. The closer you get to the nonportable
end of the spectrum, the harder that gets.

On windows computers, what's to stop you from doing what many
programmers allready do? Create a .dll file for each CPU you want to
optimize for, then for eg. create a .dll file for each major video
card you need support for.

Needless and multiple profusion of code and object files. Not only are
you guaranteed more bugs than you'd otherwise have, your users also do
not thank you for filling their system directories (or as most of them
would call it, "Windows Folder") with yet more DLLs used by a single
program.

Richard

[Chris H]

In message <6l************@mid.individual.net>, Ian Collins
<ia******@hotmail.comwrites

>Chris H wrote:

>In message <6l************@mid.individual.net>, Ian Collins
<ia******@hotmail.comwrites

>>Chris H wrote:
In message
<c4**********************************@u40g2000p ru.googlegroups.com>,
asit <li*****@gmail.comwrites
>
Does portable C is as faster as posix C.

Generally (but not always) portable C is slower because you don't use
the hardware or compiler specific extensions.

I disagree on two counts, you may not need any compiler specific
extensions and hardware specific extensions tend to be compiler options
rather than in the code. Compiler specific extensions tend to be
syntactic rather than performance enhancing.

I have to completely disagree. In most of my work you could not get a
program to run without the extensions. How do you interface to the
hardware?

That really depends how the hardware is mapped.

How do you mean?

How would you access the peripherals on an MCU without hardware
extensions?

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

[Ian Collins]

Chris H wrote:

In message <6l************@mid.individual.net>, Ian Collins
<ia******@hotmail.comwrites

>Chris H wrote:

>>In message <6l************@mid.individual.net>, Ian Collins
<ia******@hotmail.comwrites
Chris H wrote:
In message
<c4**********************************@u40g2000 pru.googlegroups.com>,
asit <li*****@gmail.comwrites
>>
>Does portable C is as faster as posix C.
>
Generally (but not always) portable C is slower because you don't use
the hardware or compiler specific extensions.
>
I disagree on two counts, you may not need any compiler specific
extensions and hardware specific extensions tend to be compiler options
rather than in the code. Compiler specific extensions tend to be
syntactic rather than performance enhancing.

I have to completely disagree. In most of my work you could not get a
program to run without the extensions. How do you interface to the
hardware?

That really depends how the hardware is mapped.

How do you mean?

How would you access the peripherals on an MCU without hardware extensions?

If they are mapped into the processor's normal address space, it's a
non-issue. If not then you do have to use extensions, I'm not disputing
that. The issue wasn't the requirement for extensions, but whether they
speed up the code.

My point was hardware extensions tend to be used to enable the code to
do things that aren't part of standard C, like access extra address
spaces or peripheral registers. They tend not to be used for increased
performance.

Most compilers provide compiler options to increase performance on
specified targets (using multi-media instructions or extended registers
for example), but these apply to the compiler, not the source code.

--
Ian Collins.

[dj3vande]

In article <6l************@mid.individual.net>,
Ian Collins <ia******@hotmail.comwrote:

>My point was hardware extensions tend to be used to enable the code to
do things that aren't part of standard C, like access extra address
spaces or peripheral registers. They tend not to be used for increased
performance.

Counterexample: Crypto accelerators.
They work at too high a level to be used automagically by the compiler
at code-generation time (unless compilers are a *lot* smarter than I
think they are), and their entire purpose is to speed up operations
that could easily be done correctly (modulo deadlines) by fully
portable C code.

(I believe the canonical solution is to use a dynamically linked system
library and trust your vendor and/or sysadmin to be competent enough to
install a version of the library that supports any hardware that would
be useful for the purpose; but by relying on a system-provided library,
you've stepped outside the bounds of standard, fully portable C.)
dave

--
Dave Vandervies dj3vande at eskimo dot com
I'm waiting for the day that you're carrying a pistol, for which you have an
open carry permit, and are busted for the Leatherman. I think that I'm only
joking, but wouldn't put any money on it. --Shmuel Metz in the SDM

[Ian Collins]

dj******@csclub.uwaterloo.ca.invalid wrote:

In article <6l************@mid.individual.net>,
Ian Collins <ia******@hotmail.comwrote:

>My point was hardware extensions tend to be used to enable the code to
do things that aren't part of standard C, like access extra address
spaces or peripheral registers. They tend not to be used for increased
performance.

Counterexample: Crypto accelerators.
They work at too high a level to be used automagically by the compiler
at code-generation time (unless compilers are a *lot* smarter than I
think they are), and their entire purpose is to speed up operations
that could easily be done correctly (modulo deadlines) by fully
portable C code.

True enough. One could also include packet filtering offload to NICs as
a common hardware extension.

But in both cases, the code using this hardware can be standard C. The
acceleration can be transparent to the client code.

(I believe the canonical solution is to use a dynamically linked system
library and trust your vendor and/or sysadmin to be competent enough to
install a version of the library that supports any hardware that would
be useful for the purpose; but by relying on a system-provided library,
you've stepped outside the bounds of standard, fully portable C.)

That all depends where you draw the "implementation" line. At least on
Solaris, crypto acceleration (if fitted) is provided by the OS environment.

--
Ian Collins