portable C, posix C and windows C

[asit]

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

 

[user923005]

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]

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]

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]

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.

 

[James Kuyper]

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.

 

[dj3vande]

asit 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,
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

 

[dj3vande]

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

 

[Ian Collins]

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.

 

[Flash Gordon]

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

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.

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.

 

[user923005]

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/?p=config.git;a=blob_plain;f=config.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]

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.

 

[Chris H]

In message

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

 

[Ian Collins]

In message


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.

 

[Chris H]

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?

 

[Ian Collins]

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.

 

[Richard Bos]

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 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]

That really depends how the hardware is mapped.

How do you mean?

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

 

[John Bode]

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

"Portable" has several different meanings with respect to C. One
meaning is that C compilers have been implemented on a wide variety of
platforms where other languages have not; this was a Big Deal back in
the dark ages, now probably not so much. Another meaning is that
there is a single, well-known standard for the C language that most
compilers implement faithfully, as opposed to languages that vary
depending on the platform and vendor (there were multiple, slightly
incompatible versions of Pascal and Fortran floating around when C was
first becoming popular).

For most of us, "portable" means C code that has been written in such
a way that it will build and run on multiple platforms with little or
no change. For example, the canonical "Hello World" program

#include <stdio.h>
int main(void)
{
printf("Hello, World\n");
return 0;
}

should compile and run and give the same results on every platform
without making any changes to the source code, so it's considered
"portable" (what I call trivially portable). As long as your source
code makes no assumptions about word size, byte order, or numerical
representation, and restricts itself to using the standard library
(stdio, stdlib, string, math, etc.), then it should be trivially
portable like the code above.

Unfortunately, C doesn't provide built-in support for a lot of
capabilities that most of us have come to expect in modern software --
graphics, sound, network support, etc., so to do any of that we have
to rely on vendor-specific or third-party libraries that may only
exist on specific platforms. For example, if you took the source code
for Microsoft Word for Windows and tried to compile and run in on a
Mac, you'd get a ton of errors because the Mac doesn't support the
Windows libraries. In this case, "portable" means structuring your
code so that the stuff that really is platform-specific is segregated
from the general application logic, so that the general application
logic can be ported easily from one platform to another.

There is no POSIX-specific version of the C language; when people talk
about POSIX C, they're talking about C code that uses interfaces and
utilities defined by the POSIX standard.

Similarly, "Windows C" refers to C code that makes use of interfaces
and utilities specific to the Microsoft Windows platform, although MS
did extend the language a bit (adding extra keywords) to support
Windows programming.