Is this fully portable and/or smart?

[Richard Tobin]

POSIX and ISO C99 have many differences. For example, POSIX requires
CHAR_BIT to be exactly 8 while the standard only guarantees it to be
equal or greater than 8.
In POSIX, int is at least 32 bits, while in ISO C (and ANSI C) it's at
least 16 bits.
POSIX allows a void pointer to hold a function pointer, while ISO C
doesn't allow that. There are more differences than the above.

POSIX is not a superset of ISO C just like ISO C++ is not a superset
of ISO C.

All the difference you list are consistent with Posix C being a
superset of ISO C. For example, a program that only assumes that
CHAR_BIT is at least 8 will work perfectly will on a Posix
implementation where it is exactly 8.

The obvious things make typical unix C implementations not a superset
are the additional identifiers that they declare in standard headers,
but I'm not sure what Posix says about these.

-- Richard

 

[Szabolcs Borsanyi]

The obvious things make typical unix C implementations not a superset
are the additional identifiers that they declare in standard headers,
but I'm not sure what Posix says about these.

At this point i'd appreciate if someone could make a statement, lest I get
confused:
Does POSIX change anything more in the C language than declaring
more identifiers in standard headers (and more functionality in the
libraries) as well as imposing stricter implementational limits?

I vaguely remember a posix requirement that there shall be no gaps in
structs unless a gap is necessary for ensuring the correct alignment.

(Posix is probably not quite topical here, but unix is still the root of C,
isn't it.)

Szabolcs

 

[santosh]

Szabolcs Borsanyi wrote:

(Posix is probably not quite topical here, but unix is still the root
of C, isn't it.)

My rather modest experience indicates that C's main usage these days is
with various "embedded" systems and maintenance of old code on existing
mainstream desktop, server and mainframe systems. There seems to be
little new C programming outside the embedded arena, at least if goes
by the job offers.

 

[Spiros Bousbouras]

Szabolcs Borsanyi wrote:



My rather modest experience indicates that C's main usage these days is
with various "embedded" systems and maintenance of old code on existing
mainstream desktop, server and mainframe systems. There seems to be
little new C programming outside the embedded arena, at least if goes
by the job offers.

I see plenty of job offers which require C (among other
languages). Whenever I see an open source project it is
more often than not written in C.

 

[Eligiusz Narutowicz]

I see plenty of job offers which require C (among other
languages). Whenever I see an open source project it is
more often than not written in C.

Only some Gnome apps afaik. And the kernel and device drivers for Linux.

 

[Spiros Bousbouras]

Only some Gnome apps afaik. And the kernel and device drivers for Linux.

http://sourceforge.krugle.com gives "about" 22510 projects
in C.

 

[Eligiusz Narutowicz]

http://sourceforge.krugle.com gives "about" 22510 projects
in C.

And how many offer paying jobs?

 

[Spiros Bousbouras]

And how many offer paying jobs?

Hardly any I would imagine. What's your point ?

 

[Eligiusz Narutowicz]

Hardly any I would imagine. What's your point ?

The point would be clearly in this thread I am thinking.

 

[santosh]

I see plenty of job offers which require C (among other
languages). Whenever I see an open source project it is
more often than not written in C.

Okay. I suppose a local market bias is colouring my estimates.

 

[Szabolcs Borsanyi]

My rather modest experience indicates that C's main usage these days is
with various "embedded" systems and maintenance of old code on existing
mainstream desktop, server and mainframe systems. There seems to be
little new C programming outside the embedded arena, at least if goes
by the job offers.

Hmm. The first thing I ever programmed in C was indeed an 8-bit
microcontroller, still I was surprised of this statement.

Although programming the linux kernel is not a well paid job, it is done in C
and is important. In science, C is one of the main means of solving numerical
problems and data analysis, and runs almost exclusively on posix systems. In
this (very narrow and low paid) branch portability means posix conformance, and
we hardly think of porting a big calculation from a supercomputer to an embedded
system. That's why I asked my question.

Szabolcs

 

[Szabolcs Borsanyi]

Not sure whether POSIX says anything about it or not. C
tolerates padding after any element if the implementation decides
to put some there, but does not require that there be any -- so
...

I might have confused posix with sysv. By gapless struct I meant that e.g.
struct { float r,i } can be accessed through a complex float.
(Which is clearly a nice undefined behaviour, otherwise).

Szabolcs

 

[Bill Reid]

"Bill Reid" <[email protected]> writes:

[big snip]

Anyway, learned something today: if a system is POSIX "Issue 4"
compliant, I CAN use fgetpos() and fsetpos()...

I'm glad we could help.

Don't expect much more help here unless you change your attitude.

OH NO, WHAT A "THREAT"!!! "We're" not going to tell you how to
mess up perfectly fine working code if you don't thank us profusely
enough for the "help"!

You know what else I learned: that the POSIX "version" of fseek()
can have non-zero offsets from SEEK_END for 8-bit character text
files. Of course, nobody told me this directly, but the Open Org
link allowed me to look up that VERY interesting and relevant little
factoid.

What does this mean? Well, as to the general question of
portability of the code I posted, quite a lot. It means that if
the code works on a Windows "implementation", then it almost
certainly will work across a broad range of *nixes; in fact,
it will probably work across a broad range of *nixes even if
it DOESN'T work on a particular Windows "implementation".

So the correct answer(s) to my question(s) was it is probably
pretty portable to systems where it would actually be useful,
but definitely not FULLY portable according to the language of
the C "standard" (how many times have I heard THAT before?),
and it's actually pretty "smart" too...or at least as "smart" as
allowed by one of the most frequent posters here:

Newsgroups: comp.lang.c
From: Richard Heathfield
Date: Tue, 15 Apr 2008
Subject: Re: How do I create a function in my library for passing user
callback function

(e-mail address removed) said:

Now, there wasn't a syntax error. So, what's the bug?

Please disregard my previous reply. Mr Reid was correct. I suspect this was
accidental, but nevertheless he was right and I was wrong.

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

---end of archived post

You see, I AM "smart", just "accidentally" so!!! Yay me!!!

 

[santosh]

[big snip]

Anyway, learned something today: if a system is POSIX "Issue 4"
compliant, I CAN use fgetpos() and fsetpos()...

I'm glad we could help.

Don't expect much more help here unless you change your attitude.

OH NO, WHAT A "THREAT"!!! "We're" not going to tell you how to
mess up perfectly fine working code if you don't thank us profusely
enough for the "help"!

You have been on my PLONK list for some time, marked as
"insufferable and non-portable". [ ... ]

You even annotate your killfile entries!?

 

[Bill Reid]

You have been on my PLONK list for some time, marked as
"insufferable and non-portable". [ ... ]

You even annotate your killfile entries!?

The amateur psychologist in me is fascinated by people who
purport to use "kill-files".

First, about 90% of all "PLONK"s announced on newsgroups
are imaginary in my experience. Most of the time, it actually
means that the "PLONK"er is now officially obsessed with
the person they allegedly "PLONK"ed, and will actually read
their messages much more closely than before.

Note carefully there is NO rational reason to ANNOUNCE
your "PLONK" in the first place. When asked about this odd
practice, serial "kill-filers" sometimes will mumble something
about sending a warning to others, but will usually evade the
question. It IS clear they derive some internal emotional
benefit from stating they have "kill-filed" somebody, even
though in most cases, they have done no such thing.

One of the fascinating behaviors was just demonstrated
here, where the person with the imaginary "kill-file" responds
to a post by the person they "kill-filed", requiring various
claims as to why they are reading the post. (One guy I
know continuously claims that his disks crash about every
three days, and he has to buy a new computer and so
loses his "kill-file"!) These messages invariably contain
a "warning" to the "PLONKEE" that their readable state
is temporary in nature and could be revoked at any time
for continued bad behavior. This is orthogonal to what
I call the "talking kill-file", where the "PLONK"er continuously
discusses the "PLONK"ee that they so publically claimed
was not worth reading.

Obviously, the individual who displays this behavior must
have generalized feelings of powerlessness, and like so
many is attempting to gain some feelings of importance
and power lacking in their "real life" by lashing out in this
peculiar manner at people on the Internet.