Is this fully portable and/or smart?

[Bill Reid]

This is how I handle a check that the last character of a text
file is a newline:

/* checks if newline is last character of text file */
unsigned check_text_file_newline_termination(FILE *test_file) {
int end_char;

fseek(test_file,-1L,SEEK_END);

end_char=getc(test_file);

rewind(test_file);

if(end_char=='\n') return TRUE;
else return FALSE;
}

The question is: is this actually guaranteed to work properly on
all "conforming" C "implementations"? My reading of the spec says
"no", but of course it works just fine on the several systems I've
used it on...

Also, would this be the fastest way possible to make this check,
as opposed to a perhaps more "conformant" scheme of reading
every character in the file to find the end of the file?

---
William Ernest Reid

[Keith Thompson]

"Bill Reid" <ho********@happyhealthy.netwrites:
[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.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[vippstar]

On May 21, 9:55 am, "Bill Reid" <[e-mail]:

Ian Collins <[e-mail] in message

news:69*************@mid.individual.net...

Bill Reid wrote:

Keith Thompson <[e-mail]:

>And, in fact, the *absence* of fgetpos and fsetpos in a C
>implementation would cause that implementation to be non-conformat to
>both C and POSIX.

What authority do you rely on to say that absence of those two in
a C "implementation" makes it not POSIX-conformant?

http://www.opengroup.org/onlinepubs/...s/fgetpos.html

OK, NOW it is in POSIX, as of "Issue 4" (look at the change history
section); it was NOT in "Issues 1, 2, and 3"...but fseek() was in there
from the beginning. I'm relying on documentation that is several years
old at least, and who knows, possibly POSIX-compliance of similar
vintage if I should try to port my application...

For some really relevant fun, read the description of fseek() from
the same source:

http://www.opengroup.org/onlinepubs/...ons/fseek.html

Note carefully that the restriction on only seeking a non-zero offset
from SEEK_SET applies only to wide-character I/O, conflicting with
more restrictive language of the C "standard"...

In any event, you're looking at this the wrong way...since even by
your "logic" POSIX is a superset of the C "standard", why would
I read "C" documentation to figure out what is in POSIX?

It may reference the C standard, but it does not include the text.

Huh? You just gave me a link to what purports to be the "POSIX"
description of a C "standard" function. ALL POSIX versions I have
read either explicitly referenced the C "standard" section for functions
that were "identical" for both, or explicitly described the differences,
or provided a full description for functions/defines/etc. that were
unique to POSIX. In this latest version, they apparently have full
descriptions of all the C "standard" functions, with a little notation
indicating what is an "extension" to the C "standard".

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.

[Richard Tobin]

In article <28**********************************@k37g2000hsf. googlegroups.com>,
<vi******@gmail.comwrote:

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

[Szabolcs Borsanyi]

On Wed, May 21, 2008 at 11:02:15AM +0000, Richard Tobin wrote:

<vi******@gmail.comwrote:

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

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:

<snip>

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

On 21 May, 12:47, santosh <[e-mail]:

Szabolcs Borsanyi wrote:

<snip>

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

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]

Spiros Bousbouras <sp****@gmail.comwrites:

On 21 May, 12:47, santosh <[e-mail]:

>Szabolcs Borsanyi wrote:

<snip>

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

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.

[Eric Sosman]

Szabolcs Borsanyi wrote:

On Wed, May 21, 2008 at 11:02:15AM +0000, Richard Tobin wrote:

> <vi******@gmail.comwrote:

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

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?

In an attempt to be precise about what "change anything"
means, let me try this: Any strictly conforming C program will
work on a POSIX system exactly as it would on any other C
system, provided it doesn't clash with POSIX' extra identifiers.
The `for' statement behaves on POSIX just as it does elsewhere,
the rules for argument promotion are the same, memory provided
by malloc() is still correctly aligned for any type, atan2()
still computes arctangents, longjmp() still does a non-local
goto, and so on and so on.

POSIX "specializes" the more general ISO C in several
ways already mentioned, and (perhaps more pervasively) adds to
some library functions behavioral guarantees beyond C's own.
For example, C allows a binary output stream to be padded with
an implementation-defined number of zero bytes at the end; by
specifying a particular choice for that number (zero), POSIX
does not conflict with ISO C. C does not specify any behavior
for conversion between void* and function pointers; POSIX does,
but defining something C leaves undefined is not a conflict.

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

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
if POSIX does in fact have such a requirement, it's just choosing
to use no padding under some circumstances and that's fine with C.
Also, the words "necessary" and "correct" leave a huge amount of
wiggle room: "necessary" according to whose priorities, "correct"
according to whose code generator?

--
Eric Sosman
es*****@ieee-dot-org.invalid

[Spiros Bousbouras]

On 21 May, 13:17, Eligiusz Narutowicz<[e-mail]>
wrote:

Spiros Bousbouras <[e-mail]:

On 21 May, 12:47, santosh <[e-mail]:

Szabolcs Borsanyi wrote:

<snip>

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

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.

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

[Eligiusz Narutowicz]

Spiros Bousbouras <sp****@gmail.comwrites:

On 21 May, 13:17, Eligiusz Narutowicz<[e-mail]>
wrote:

>Spiros Bousbouras <[e-mail]:

On 21 May, 12:47, santosh <[e-mail]:
Szabolcs Borsanyi wrote:

><snip>

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

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.

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

And how many offer paying jobs?

[Spiros Bousbouras]

On 21 May, 14:23, Eligiusz Narutowicz<[e-mail]>
wrote:

Spiros Bousbouras <[e-mail]:

On 21 May, 13:17, Eligiusz Narutowicz<[e-mail]>
wrote:

Spiros Bousbouras <[e-mail]:
On 21 May, 12:47, santosh <[e-mail]:
Szabolcs Borsanyi wrote:

<snip>

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

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.

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

And how many offer paying jobs?

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

[Eligiusz Narutowicz]

Spiros Bousbouras <sp****@gmail.comwrites:

On 21 May, 14:23, Eligiusz Narutowicz<[e-mail]>
wrote:

>Spiros Bousbouras <[e-mail]:

On 21 May, 13:17, Eligiusz Narutowicz<[e-mail]>
wrote:
Spiros Bousbouras <[e-mail]:
On 21 May, 12:47, santosh <[e-mail]:
Szabolcs Borsanyi wrote:

><snip>

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

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.

>http://sourceforge.krugle.comgives "about" 22510 projects
in C.

And how many offer paying jobs?

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

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

[santosh]

Spiros Bousbouras wrote:

On 21 May, 12:47, santosh <[e-mail]:

>Szabolcs Borsanyi wrote:

<snip>

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

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]

On Wed, May 21, 2008 at 05:17:36PM +0530, santosh 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.

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]

On Wed, May 21, 2008 at 08:36:31AM -0400, Eric Sosman wrote:

Szabolcs Borsanyi wrote:

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

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]

Keith Thompson <ks***@mib.orgwrote in message
news:ln************@nuthaus.mib.org...

"Bill Reid" <ho********@happyhealthy.netwrites:

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

---
William Ernest Reid

[CBFalconer]

Bill Reid wrote:

Keith Thompson <ks***@mib.orgwrote in message

>"Bill Reid" <ho********@happyhealthy.netwrites:

[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". I took you off a couple of days
ago to see what you were saying these days. The above doesn't help
you. I will wait a bit before deciding whether to rePLONK.

No, we don't decide to 'not tell you'. We just ignore your
postings, so we have no idea what, if anything, you are saying. At
the same time we are not annoyed.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.
** Posted from http://www.teranews.com **

[santosh]

CBFalconer wrote:

Bill Reid wrote:

>Keith Thompson <ks***@mib.orgwrote in message

>>"Bill Reid" <ho********@happyhealthy.netwrites:

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

santosh <sa*********@gmail.comwrote in message
news:g1**********@registered.motzarella.org...

CBFalconer wrote:

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.

---
William Ernest Reid

[CBFalconer]

santosh wrote:

CBFalconer wrote:

>Bill Reid wrote:

.... snip ...

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

The system here has space for a 'title'. Here I mark thread
plonks, and for individuals I mark the name and reason. No great
sweat. This gives me a chance to review things semi-intelligently
later. I can't remember why I plonked somebody 4 years ago!

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.
** Posted from http://www.teranews.com **