twitter: comp.lang.c - 25 new messages in 9 topics

comp.lang.c
http://groups.google.com/group/comp.lang.c?hl=en

comp.lang.c@googlegroups.com

Today's topics:

==============================================================================
TOPIC: Checking validity of a file pointer
http://groups.google.com/group/comp.lang.c/t/4f4f63a7786abe8e?hl=en
==============================================================================

== 1 of 3 ==
Date: Thurs, Jan 14 2010 2:51 pm
From: Flash Gordon

Richard Harter wrote:
> On Wed, 13 Jan 2010 19:06:42 +0100, jacob navia
> <jacob@spamsink.net> wrote:
>
>> Richard Harter a �crit :
>>> Is there any way to reliably check the legitimacy of something
>>> that purports to be a file pointer?
>> No.

<snip>

>> Solution:
>>
>> When you start the program open the log file and ensure that
>> it is OK to write to it. Then store it in some place.
>> Eliminate the FILE * argument from the log function specs.
>
> Minor quibble: The context is an error exit function, not a log
> function.

I've got one of those as well...

> Actually, the code I use does that. The issue is that there is
> no guarantee that the file pointer is still valid when the error
> exit function is called. Any number of bad things may have
> happened in the interim; indeed something bad must have happened
> or the code wouldn't be calling the error exit function.

Mine has lots of things that should be open and should be closed, but
they might be figments of the corruption causing the crash...

> One can check by trying to put a character and then checking for
> a write error. This may crash the program which is undesirable.
>
> Is there anything better?

If it is Linux/Unix the most likely crash probably generates a SIGSEGV,
and on Windows and other OSs there might be an equivalent signal which
you could trap. So what you can do is something like...

static failstep = 0;

failstep++;

switch {
case 1: log failure
case 2: tidy up
...
}

add cases etc as required in an appropriate order, and you may need a
bit more stuff in the signal handler to re-install itself for the next
SIGSEGV.

It is far from perfect, but it does allow you to first try and abort
nicely with a log message, and gradually do less and less tidying up as
you find out what you can't do.

I would also recommend NOT freeing memory in the abort code, since if
you are crashing because the structures malloc/free use doing another
free only compounds the problem.

<snip>

>> Much better would be:
>>
>> void errexit(char *function_name, char *message, int flags);
>>
>> Error messages do not need to be SO nicely formatted. Just print the
>> location of the code, the errormessage. Flags could be something that
>> tells you if you should exit or not (warning/error) but it can be
>> eliminated.
>>
>> At this point, the software is going to stop running. Do NOT
>> complicate things, do NOT try to have fancy formatting. Just
>> print the message and exit.
>>
>> REMEMBER: Only software people afre going to read this. They are not end
>> users. And if the log file is hard to read they can write a piece of
>> software for better formatting of the log file :-)
>
> I disagree with your "much better". I've used it and I don't
> like it. I want to be able to include data in the message.

I agree, even the programmer needs more information than can be
contained in a fixed message if you can manage to get it out. A fall
back which just chucks out minimal information can also be useful (I
have a daemon that emails a fixed message if it crashes so that the
sysadmin at least knows it needs restarting before it tries to do any
tidying up or detailed error reporting).
--
Flash Gordon

== 2 of 3 ==
Date: Thurs, Jan 14 2010 3:05 pm
From: Keith Thompson

"io_x" <a@b.c.invalid> writes:
> "Keith Thompson" <kst-u@mib.org> ha scritto nel messaggio
> news:lnr5ptfor8.fsf@nuthaus.mib.org...
>> I agree that fclose() can do some checking, and that it shouldn't be
>> too difficult in most implementations. (I won't comment on your
>> characterization of an implementation that doesn't do this.)
>>
>> On the other hand, it's not hard to imagine an implementation that's
>> built on top of some lower level, where that lower level doesn't
>> provide this kind of checking.
>>
>> Also (somebody else mentioned this scenario), consider:
>>
>> fp1 = fopen(...);
>> fclose(fp1);
>
>> fp2 = fopen(...);
>> /* Suppose fp2 happens to point to the same FILE object that
>> fp1 had pointed to.
>> */
>> ...
>> fclose(fp1);
>> /* Oops, we closed fp1 twice, but the error isn't detected
>> because the pointer looks valid.
>> */
>
> in how i see the subject:
> here is the place where the program has to abort()

Then how you see it is inconsistent with the standard and, as far as I
can tell, with reality.

I agree that it would be nice if this particular error could be
detected (preferably by having fclose return an error indication
rather than by aborting the program), but I don't see how it could be
detected. I suppose the implementation could try to guarantee that
fopen() calls don't return a pointer to a previously closed file, but
that would mean remembering all previously closed files, which could
become unwieldy after a while. Remembering the last N, for some small
value of N, is probably feasible.

>> fclose(fp2);
>> /* This should have beeen ok, but the previous fclose clobbered
>> the FILE object; if fclose() performs checking, it will
>> report the error here rather than where it really occurred
>> */
>>
>> That's not to say that performing checking in fclose() isn't a good
>> idea (and closing a file isn't likely to be performance-critical), but
>> it can't catch everything.
>
> if the buffer of the file is returned from the malloc() function,
> "that performing checking" could be done in free() function too;
> free() could show there is a memory leak or better a double free

malloc and free can have the same kind of problem:

p1 = malloc(...);
free(p1);

p2 = malloc(...); /* p2 happens to point to the same location that
p1 previously pointed to */
free(p1); /* oops! */

The free(p1) call invokes undefined behavior, but without substantial
extra work there's no way the implementation can detect the problem.

--
Keith Thompson (The_Other_Keith) kst-u@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"

== 3 of 3 ==
Date: Thurs, Jan 14 2010 4:33 pm
From: richard@cogsci.ed.ac.uk (Richard Tobin)

In article <lnfx68e194.fsf@nuthaus.mib.org>,
Keith Thompson <kst-u@mib.org> wrote:

>I agree that it would be nice if this particular error could be
>detected (preferably by having fclose return an error indication
>rather than by aborting the program), but I don't see how it could be
>detected. I suppose the implementation could try to guarantee that
>fopen() calls don't return a pointer to a previously closed file, but
>that would mean remembering all previously closed files, which could
>become unwieldy after a while.

It's not unreasonable in a debugging mode. Some malloc()
implementations have a debugging option that effectively makes free()
a no-op, so they never return the same memory twice. For a system
that malloc()s FILE structs, this would have the side-effect of doing
what you suggest.

-- Richard
--
Please remember to mention me / in tapes you leave behind.

==============================================================================
TOPIC: The undefinedness of a common expression.
http://groups.google.com/group/comp.lang.c/t/bdae87d399a9442e?hl=en
==============================================================================

== 1 of 5 ==
Date: Thurs, Jan 14 2010 2:17 pm
From: lawrence.jones@siemens.com

In comp.std.c sfuerst <svfuerst@gmail.com> wrote:
> Hello, back in 2002 there was a long discussion in these newsgroups
> about the undefinedness of the expression:
>
> a[a[0]] = 1; when a[0] begins with the value 0.
>
> The general opinion was that the above invokes undefined behaviour due
> to the fact that there is no sequence point in the expression, and
> that the value of a[0] is used in a "value computation" unsequenced
> with respect to the side-effect of the assignment operator.

I believe this is corrected by the new sequencing language in the C1X
draft (N1425 is the latest version).
--
Larry Jones

From now on, I'm devoting myself to the cultivation of
interpersonal relationships. -- Calvin

== 2 of 5 ==
Date: Thurs, Jan 14 2010 4:21 pm
From: Kaz Kylheku

On 2010-01-14, sfuerst <svfuerst@gmail.com> wrote:
> Hello, back in 2002 there was a long discussion in these newsgroups
> about the undefinedness of the expression:
>
> a[a[0]] = 1; when a[0] begins with the value 0.

The assignment cannot modify a[0] until that assignment actually happens;
i.e. the modification of a[0] is the culmination of that assignment
(except for the part that the assignment expression also returns a value,
which is not relevant in the above).

The assignment cannot happen until the value being assigned is known (which it
always is since it is the constant 1), and it also cannot happen until the
location of the destination operand is established; if you don't yet know
/where/ to store the value, you cannot do the assignment.

To know where the assignment is going to be stored, we must evaluate
a[0], and so this must happen before the assignment occurs, which means
that it it uses the prior value of a[0].

The access to a[0] is therefore properly sequenced with regard to the
assignment: not by explicit sequence points but by a data flow dependency which
follows the rules of causality in our observable universe.

Outside of science fiction fantasies involving time travel, parallel universes,
or time going backwards in localized regions of time-space, the determination
of where an assignment is going to happen cannot occur after the assignment has
already happened.

> The general opinion was that the above invokes undefined behaviour due

General or not, that is not a particularly well-informed opinion.

C expression evaluation (oustide of the sequencing operators like comma or ||)
is not totally unordered. The standard says explicitly that the order
of evaluation of the /subexpressions/ of an operator is unspecified
and may even be parallel, and the order in which side effects take place
is unspecified:

6.5 Expresions

3 The grouping of operators and operands is indicated by the syntax.71)
Except as specified later (for the function-call (), &&, ||, ?:, and comma
operators), the order of evaluation of subexpressions and the order in which
side effects take place are both unspecified.

Note that this paragraph does not insist that there is never any
order among side effects and subexpressions. There are situations where
logic requires order.

And note that 6.5 doesn't say that the evaluation of operators may be reordered
with respect to their own subexpressions (that is illogical)! Only among the
subexpressions is the order unspecified. To evaluate an operator, you must
fetch the values of its subexpressions (except where short-circuiting permits
elision). Only after that can the operator be evaluated.

So what happens if the evaluation of a parent operator invokes a side effect,
which depends on the constituent subexpressions? In that case we cannot
conclude that the order is unspecified between that side effect and
the subexpressions.

The = operator in a[a[0]] = 1 operator has two subexpressions: a[a[0]] and 1.
The implementation may evalute these in either order, in accordance with 6.5p3.
It also has a side effect: that of storing to the lvalue. Certainly, that side
effect might be ordered arbitrarily with regard to some side effects elsewhere
in the expression, in accordance with 6.5.

However, the two subexpressions of the assignment cannot be reordered with
regard to the store side effect /of that same assignment/ operator. That is a
logical impossibility, since the assignment must evaluate its two operands
before producing that side effect.

This doesn't need to be spelled out in the standard, because it's not the sort
of document for readers who cannot recognize logical impossibilities.

== 3 of 5 ==
Date: Thurs, Jan 14 2010 5:04 pm
From: Ben Bacarisse

Kaz Kylheku <kkylheku@gmail.com> writes:

> On 2010-01-14, sfuerst <svfuerst@gmail.com> wrote:
>> Hello, back in 2002 there was a long discussion in these newsgroups
>> about the undefinedness of the expression:
>>
>> a[a[0]] = 1; when a[0] begins with the value 0.
<snip discussion of sub-expression sequencing>
>> The general opinion was that the above invokes undefined behaviour due
>
> General or not, that is not a particularly well-informed opinion.
<snip more about sequencing>

I don't disagree with your arguments about sequencing, logic, and
causality, but I don't see how you can dismiss the conclusion above so
lightly -- particularly without any reference to the text that, in my
view, renders it undefined.

The oft-quoted 6.5 paragraph 2 reads:

"Between the previous and next sequence point an object shall have
its stored value modified at most once by the evaluation of an
expression. Furthermore, the prior value shall be read only to
determine the value to be stored." [footnote numbers removed]

Surely the prior value of an object (a[0] -- which is having it's
stored value modified exactly once) is being read for some purpose
other than to determine the value to be stored?

You could argue that this shouldn't be undefined, or that the new
sequencing wording in n1401.pdf makes it no longer undefined; but that
it was undefined (and still is undefined) looks like a perfectly
reasonable conclusion.

--
Ben.

== 4 of 5 ==
Date: Thurs, Jan 14 2010 5:24 pm
From: lacos@ludens.elte.hu (Ersek, Laszlo)

In article <bf348dad-6ecc-4f54-baf3-49ac2f3def08@m25g2000yqc.googlegroups.com>,
sfuerst <svfuerst@gmail.com> writes:

> It is not me contending that undefined behaviour is invoked. That
> answer seemed to be the consensus of the thread in 2002. It's start
> is at:
> http://groups.google.com/group/comp.std.c/browse_thread/thread/cffd61637f55=
> 20d/5ce672676f5ab8ef
> and it is a particularly interesting read. The pointer-chain example
> is introduced about halfway along.

I've paged through all 329 messages and searched for the string "*a".
I've also searched the current thread. Since I haven't found what I was
looking for, I'd like to add a reformulation of the original

a[a[0]] = 1;

statement. I apologize if it's trivial.

C89 6.3.2.1 Array subscripting

"The definition of the subscript operator [] is that E1[E2] is identical
to (*(E1+(E2)))."

C99 6.5.2.1 Array subscripting

"The definition of the subscript operator [] is that E1[E2] is identical
to (*((E1)+(E2)))."

Going with the latter, the statement can be rewritten as

(*((a)+((*((a)+(0)))))) = 1;

which can be simplified to

*(a + *a) = 1;

I'm sorry if this doesn't add anything to the discussion; my hope is
that it would.

lacos

== 5 of 5 ==
Date: Thurs, Jan 14 2010 6:20 pm
From: Kaz Kylheku

On 2010-01-15, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
> Kaz Kylheku <kkylheku@gmail.com> writes:
>
>> On 2010-01-14, sfuerst <svfuerst@gmail.com> wrote:
>>> Hello, back in 2002 there was a long discussion in these newsgroups
>>> about the undefinedness of the expression:
>>>
>>> a[a[0]] = 1; when a[0] begins with the value 0.
><snip discussion of sub-expression sequencing>
>>> The general opinion was that the above invokes undefined behaviour due
>>
>> General or not, that is not a particularly well-informed opinion.
><snip more about sequencing>
>
> I don't disagree with your arguments about sequencing, logic, and
> causality, but I don't see how you can dismiss the conclusion above so
> lightly -- particularly without any reference to the text that, in my
> view, renders it undefined.
>
> The oft-quoted 6.5 paragraph 2 reads:
>
> "Between the previous and next sequence point an object shall have
> its stored value modified at most once by the evaluation of an
> expression. Furthermore, the prior value shall be read only to
> determine the value to be stored." [footnote numbers removed]

This text can be parsed as:

[ Furthermore, the prior value shall be read only ] to
determine the value to be stored."

Indeed, before the store, the prior value shall not be written, but only read,
and this is of course necessary for determining the value to be stored.

See, people are just reading it wrong. There is no document defect to see
here, people; move along.

So this sentence does not unambiguously grant implementors a license
to gratuitously break code with cunning diagnostics (at least in
a mode that claims to be conforming).

==============================================================================
TOPIC: Detecting an empty line in stdin
http://groups.google.com/group/comp.lang.c/t/ac86a7275d1ba03d?hl=en
==============================================================================

== 1 of 1 ==
Date: Thurs, Jan 14 2010 3:27 pm
From: ike@localhost.claranet.nl (Ike Naar)

In article <c248de5e-7eb7-409a-b5e7-39559092db93@j4g2000yqe.googlegroups.com>,
Peter Nilsson <airia@acay.com.au> wrote:
>i...@localhost.claranet.nl (Ike Naar) wrote:
>> 3000 numbers have 2999 differences.
>
>Which is why the OP had the next line...
>
> > #define MAXDIFF 2999
>
>Which doesn't alter the fact that the OP only
>allocates storage for 2999 input integers in
>the subsequent code, despite the specs saying
>there may be up to 3000 such integers.

You're right; I should have read the OP's code more carefully before posting.

==============================================================================
TOPIC: Order of Variable Declartion
http://groups.google.com/group/comp.lang.c/t/8c208583d249fb6e?hl=en
==============================================================================

== 1 of 1 ==
Date: Thurs, Jan 14 2010 3:51 pm
From: Andrew Poelstra

On 2010-01-14, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>
> ...
>
> Nit: %s stops on white space so it will only write '+' followed by
> '\0' when the '\n' is seen. The '\n' is left for the next input
> operation to see.
>

That's more than a nit - I didn't know that and it probably would
have nailed me! (If I were ever to use scanf() on stdin.)

> Second to the OP: you really should be testing the return from scanf.
> It is a great habit to get into, not because it is the right thing to
> do (though it is) but because it gets you thinking about how the
> program should be shaped to cope with thing going wrong. Coping with
> things going wrong is one of the most important things to pick up, and
> you can't start too early.
>

That one I knew, but forgot to mention.

==============================================================================
TOPIC: plz send me the solution of the problem.
http://groups.google.com/group/comp.lang.c/t/2b0df2dd5d20b8c8?hl=en
==============================================================================

== 1 of 1 ==
Date: Thurs, Jan 14 2010 3:58 pm
From: Flash Gordon

Charlton Wilbur wrote:
>>>>>> "KT" == Keith Thompson <kst-u@mib.org> writes:
>
> KT> Charlton Wilbur <cwilbur@chromatico.net> writes:
>
> >> Posting a possibly correct solution -- I only skimmed it -- that
> >> is more rigorous and thorough than the homework plagiarist likely
> >> has the experience to be, and is written in idiomatic C that is
> >> likely to be well above the homework plagiarist's level of
> >> ability seems like another good solution to the problem.
>
> KT> Assuming that the instructor is sufficiently competent to
> KT> recognize that the submitted code is beyond the student's
> KT> abilities. If he gets enough help cheating, he might be able to
> KT> fool the instructor just because the instructor will never have
> KT> seen any code the student actually wrote.
>
> Well, if the instructor is that incompetent, the student is not going to
> learn much either way.

Which leads to the student getting a pass and possibly an interview for
a job wasting the time of the interviewer. They may even get a job they
are not able to actually do costing even more money. All in all I would
prefer that students who cannot be bothered to attempt their homework
not be handed solutions.
--
Flash Gordon

==============================================================================
TOPIC: A tool that suggests optimized logic for a piece of code/module/
function
http://groups.google.com/group/comp.lang.c/t/8dc0c7e3c216aa24?hl=en
==============================================================================

== 1 of 3 ==
Date: Thurs, Jan 14 2010 4:30 pm
From: richard@cogsci.ed.ac.uk (Richard Tobin)

In article <4b4f3f14$0$6254$8404b019@news.wineasy.se>,
David Brown <david@westcontrol.removethisbit.com> wrote:

>I don't agree here (perhaps as a compiler writer you are thinking of
>"implementation" in terms of generated target code - then I'd agree).
>Kids use Logo to learn about programming concepts, and how to get the
>computer to do what you want it to do. They learn to write things like:
>
>TO SQUARE :size
>REPEAT 4 [ FD :size RT 90 ]
>END
>
>This is entirely about writing an imperative implementation of how you
>want the system to draw a square.

Well that *is* the natural way to draw a square with a turtle.
But another typical, slightly more advanced, Logo problem is to
draw fractal-like patterns, using recursion.

-- Richard
--
Please remember to mention me / in tapes you leave behind.

== 2 of 3 ==
Date: Thurs, Jan 14 2010 5:51 pm
From: karthikbalaguru

On Jan 15, 3:26 am, Hans-Bernhard Bröker <HBBroe...@t-online.de>
wrote:
> David Brown wrote:
> > Nothing stops the compiler from doing this sort of thing in /theory/.
> > But /practice/ is a different matter.
>
> The same thing applies to the original question. If a compiler's
> full-blown optimizer, given practically infinite time to ponder the
> problem, can't get that analysis job done, then no other tool can, and
> certainly not while just looking over the programmers' shoulders as they
> type.

I think, the tool
should be trained to develop tiny
logics by giving tiny infos to it.
I think, the tool should also be
trained to develop its own
self decision capabilities by
giving lot of small tasks that might
require tiny decisions initially.
The above should make it
robust in finding alternate logic.
Maybe, it can also bank on the
reliable sources on internet or
other servers to get more info
incase it runs out of steam. But
i think, it is better to avoid some
internet dependencies as
sometimes we might need to
use a PC that is not connected
to internet !

Thx in advans,
Karthik Balaguru

== 3 of 3 ==
Date: Thurs, Jan 14 2010 5:58 pm
From: Måns Rullgård

karthikbalaguru <karthikbalaguru79@gmail.com> writes:

> On Jan 15, 3:26�am, Hans-Bernhard Br�ker <HBBroe...@t-online.de>
> wrote:
>> David Brown wrote:
>> > Nothing stops the compiler from doing this sort of thing in /theory/.
>> > But /practice/ is a different matter.
>>
>> The same thing applies to the original question. �If a compiler's
>> full-blown optimizer, given practically infinite time to ponder the
>> problem, can't get that analysis job done, then no other tool can, and
>> certainly not while just looking over the programmers' shoulders as they
>> type.
>
> I think, the tool should be trained to develop tiny logics by giving
> tiny infos to it. I think, the tool should also be trained to
> develop its own self decision capabilities by giving lot of small
> tasks that might require tiny decisions initially. The above should
> make it robust in finding alternate logic. Maybe, it can also bank
> on the reliable sources on internet or other servers to get more
> info incase it runs out of steam. But i think, it is better to avoid
> some internet dependencies as sometimes we might need to use a PC
> that is not connected to internet !

There's a name for that: outsourced engineer.

--
M�ns Rullg�rd
mans@mansr.com

==============================================================================
TOPIC: Auto-generate Response?
http://groups.google.com/group/comp.lang.c/t/26a1923e9f430f39?hl=en
==============================================================================

== 1 of 1 ==
Date: Thurs, Jan 14 2010 4:38 pm
From: richard@cogsci.ed.ac.uk (Richard Tobin)

In article <hindj8$cle$4@news.xmission.com>,
Kenny McCormack <gazelle@shell.xmission.com> wrote:

>To get an idea of what a psycho Seebsie is, check out spinoza111's
>postings in CLC. They are long, and often very intricate and involved
>(yes, a time investment is required), but he has Seebsie's (and other
>CLC regs') numbers to a tee.

"We must support whatever the enemy opposes".

-- Richard

--
Please remember to mention me / in tapes you leave behind.

==============================================================================
TOPIC: limits.h
http://groups.google.com/group/comp.lang.c/t/5a3024cfbe9312f5?hl=en
==============================================================================

== 1 of 8 ==
Date: Thurs, Jan 14 2010 5:00 pm
From: frank

I read this on the internet:

I am strongly against creating a my-headers.h that simply includes all
the standard header files, when it's clearly defined which standard
headers provide which standard symbols, such as limits.h provides
PATH_MAX.

end quote. Does PATH_MAX have to be defined in limits.h, according to
standard C? I thought it certainly must, until I didn't get a hit for
it in the dinkumware compleat reference.
--
frank

== 2 of 8 ==
Date: Thurs, Jan 14 2010 5:15 pm
From: Ben Bacarisse

frank <frank@example.invalid> writes:

> I read this on the internet:
>
> I am strongly against creating a my-headers.h that simply includes all
> the standard header files, when it's clearly defined which standard
> headers provide which standard symbols, such as limits.h provides
> PATH_MAX.
>
> end quote. Does PATH_MAX have to be defined in limits.h, according to
> standard C?

No.

> I thought it certainly must, until I didn't get a hit for
> it in the dinkumware compleat reference.

I'd pick the Dinkumware reference too, if I had no other source to go
by. Alternatively, look at the C standard and you'll see no PATH_MAX
there at all (stdio.h defines FILENAME_MAX but that's not the macro in
question).

--
Ben.

== 3 of 8 ==
Date: Thurs, Jan 14 2010 5:28 pm
From: Richard Heathfield

frank wrote:
>
> Does PATH_MAX have to be defined in limits.h, according to
> standard C?

On the contrary, it *must not* be defined there, or in any other
standard header.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
"Usenet is a strange place" - dmr 29 July 1999
Sig line vacant - apply within

== 4 of 8 ==
Date: Thurs, Jan 14 2010 5:30 pm
From: Peter Nilsson

Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
> frank <fr...@example.invalid> writes:
> > Does PATH_MAX have to be defined in limits.h, according to
> > standard C?
>
> No.

Moreover, a conforming implementation must *not* define it in
<limits.h>.

--
Peter

== 5 of 8 ==
Date: Thurs, Jan 14 2010 5:44 pm
From: lacos@ludens.elte.hu (Ersek, Laszlo)

In article <7r9t0jFd4lU1@mid.individual.net>, frank <frank@example.invalid> writes:
> I read this on the internet:
>
> I am strongly against creating a my-headers.h that simply includes all
> the standard header files, when it's clearly defined which standard
> headers provide which standard symbols, such as limits.h provides
> PATH_MAX.
>
> end quote. Does PATH_MAX have to be defined in limits.h, according to
> standard C? I thought it certainly must, until I didn't get a hit for
> it in the dinkumware compleat reference.

C99 doesn't mention PATH_MAX in

7.10 Sizes of integer types <limits.h>
->
5.2.4.2.1 Sizes of integer types <limits.h>

If you mean the Single UNIX Specification, then PATH_MAX need not be
defined. You may have to use the pathconf() function, the fpathconf()
function, or the getconf utility instead.

SUSv2:
http://www.opengroup.org/onlinepubs/007908775/xsh/limits.h.html#tag_000_007_349_002

SUSv3:
http://www.opengroup.org/onlinepubs/000095399/basedefs/limits.h.html#tag_13_24_03_02

SUSv4:
http://www.opengroup.org/onlinepubs/9699919799/basedefs/limits.h.html#tag_13_23_03_02

If you program for SUSv2: you may want to use _POSIX_PATH_MAX.

If you program for SUSv3 or SUSv4: you may want to use _POSIX_PATH_MAX,
or, if the implementation conforms not only to POSIX, but also the
Single UNIX Specification, _XOPEN_PATH_MAX.

This might be of interest:

Ulrich Drepper - Directory Reading
http://udrepper.livejournal.com/18555.html

Cheers,
lacos

== 6 of 8 ==
Date: Thurs, Jan 14 2010 5:55 pm
From: frank

Richard Heathfield wrote:
> frank wrote:
>>
>> Does PATH_MAX have to be defined in limits.h, according to standard C?
>
> On the contrary, it *must not* be defined there, or in any other
> standard header.
>

When a compiler is directed to look along different paths for limits.h,
it's liable to find more than one.

What I'm trying to put together is how the preprocessor deals with that
situation. Plauger says header inclusion is idempotent. Ok, fine.
Does that mean if you have the identical text in 2 versions of limits.h,
the preprocessor would end at the same state after doing its thing if it
processes either once or thrice?
--
frank

== 7 of 8 ==
Date: Thurs, Jan 14 2010 6:28 pm
From: "robertwessel2@yahoo.com"

On Jan 14, 7:55 pm, frank <fr...@example.invalid> wrote:
> Richard Heathfield wrote:
> > frank wrote:
>
> >> Does PATH_MAX have to be defined in limits.h, according to standard C?
>
> > On the contrary, it *must not* be defined there, or in any other
> > standard header.
>
> When a compiler is directed to look along different paths for limits.h,
> it's liable to find more than one.
>
> What I'm trying to put together is how the preprocessor deals with that
> situation. Plauger says header inclusion is idempotent. Ok, fine.
> Does that mean if you have the identical text in 2 versions of limits.h,
> the preprocessor would end at the same state after doing its thing if it
> processes either once or thrice?

Only the standard headers are guaranteed to be idempotent (well,
except for assert.h). You can, of course, make your own headers
idempotent as well, but that's a different issue. Also, there can
only be one copy of each standard header (assuming such a thing
physically exists), and providing an additional one with a standard
name results in undefined behavior.

So there can only be one limits.h (again, there doesn't have to
physically be a file called that), but including it more than once is
harmless.

For non-standard headers, including two headers of the same name, but
in different directories, is no different than if they had different
names - it's just the contents of the specified file that gets pasted
into your source code at that point. And whatever the effect of
pasting it in two identical - or different - copies is, is what it is.

== 8 of 8 ==
Date: Thurs, Jan 14 2010 6:24 pm
From: William Ahern

frank <frank@example.invalid> wrote:
<snip>
> end quote. Does PATH_MAX have to be defined in limits.h, according to
> standard C?

No.

> I thought it certainly must, until I didn't get a hit for it in the
> dinkumware compleat reference.

Probably because PATH_MAX is defined by POSIX (and perhaps other standards
I'm unaware of). POSIX says that limits.h must provide PATH_MAX.

==============================================================================
TOPIC: Newbie question: accessing global variable on multiprocessor
http://groups.google.com/group/comp.lang.c/t/1c98f0aeb9e1ec74?hl=en
==============================================================================

== 1 of 2 ==
Date: Thurs, Jan 14 2010 4:25 pm
From: Flash Gordon

BGB / cr88192 wrote:
> "Flash Gordon" <smap@spam.causeway.com> wrote in message
> news:esjp17xcdl.ln2@news.flash-gordon.me.uk...
>> Nobody wrote:
>>> On Sun, 10 Jan 2010 11:06:45 +0000, Flash Gordon wrote:
>> <snip>
>>
>>>>> And even if the compiler provides the "assumed" semantics for
>>>>> "volatile"
>>>>> (i.e. it emits object code in which read/write of volatile variables
>>>>> occurs in the "expected" order), that doesn't guarantee that the
>>>>> processor
>>>>> itself won't re-order the accesses.
>>>> However, it does have to document what it means by accessing a volatile,
>>>> and it should be possible to identify from this whether it prevents the
>>>> processor from reordering further down, whether it bypasses the cache
>>>> etc.
>>> Easier said than done. The object code produced by a compiler may
>>> subsequently be run on a wide range of CPUs, including those not invented
>>> yet. The latest x86 chips will still run code which was generated for a
>>> 386.
>> If the compiler does not claim to support processors not yet invented then
>> that is not a problem. You can't blame a compiler (or program) if it fails
>> for processors which are not supported even if the processor is
>> theoretically backwards compatible.
>
> if a processor claims to be "backwards compatible" yet old code often breaks
> on it, who takes the blame?...
> that is right, it is the manufacturer...
>
> it is worth noting the rather large numbers of hoops Intel, MS, ... have
> gone through over the decades to make all this stuff work, and keep
> working...

<snip>

Not successfully. I used programs that worked on a 286 PC but failed on
a 386 unless you switched "Turbo mode" off. This was nothing to do with
the OS.

> it doesn't help that even lots of 32-bit SW has broken on newer Windows, due
> I suspect to MS no longer really caring so much anymore about legacy
> support...

It ain't all Microsoft's fault. Also, there are good technical reasons
for dropping support of ancient interfaces.
--
Flash Gordon

== 2 of 2 ==
Date: Thurs, Jan 14 2010 5:28 pm
From: "BGB / cr88192"

"Flash Gordon" <smap@spam.causeway.com> wrote in message
news:88p427x5gc.ln2@news.flash-gordon.me.uk...
> BGB / cr88192 wrote:
>> "Flash Gordon" <smap@spam.causeway.com> wrote in message
>> news:esjp17xcdl.ln2@news.flash-gordon.me.uk...
>>> Nobody wrote:
>>>> On Sun, 10 Jan 2010 11:06:45 +0000, Flash Gordon wrote:
>>> <snip>
>>>
>>>>>> And even if the compiler provides the "assumed" semantics for
>>>>>> "volatile"
>>>>>> (i.e. it emits object code in which read/write of volatile variables
>>>>>> occurs in the "expected" order), that doesn't guarantee that the
>>>>>> processor
>>>>>> itself won't re-order the accesses.
>>>>> However, it does have to document what it means by accessing a
>>>>> volatile, and it should be possible to identify from this whether it
>>>>> prevents the processor from reordering further down, whether it
>>>>> bypasses the cache etc.
>>>> Easier said than done. The object code produced by a compiler may
>>>> subsequently be run on a wide range of CPUs, including those not
>>>> invented
>>>> yet. The latest x86 chips will still run code which was generated for a
>>>> 386.
>>> If the compiler does not claim to support processors not yet invented
>>> then that is not a problem. You can't blame a compiler (or program) if
>>> it fails for processors which are not supported even if the processor is
>>> theoretically backwards compatible.
>>
>> if a processor claims to be "backwards compatible" yet old code often
>> breaks on it, who takes the blame?...
>> that is right, it is the manufacturer...
>>
>> it is worth noting the rather large numbers of hoops Intel, MS, ... have
>> gone through over the decades to make all this stuff work, and keep
>> working...
>
> <snip>
>
> Not successfully. I used programs that worked on a 286 PC but failed on a
> 386 unless you switched "Turbo mode" off. This was nothing to do with the
> OS.
>

on DOS, yes, it is the HW in this case...

>> it doesn't help that even lots of 32-bit SW has broken on newer Windows,
>> due I suspect to MS no longer really caring so much anymore about legacy
>> support...
>
> It ain't all Microsoft's fault. Also, there are good technical reasons for
> dropping support of ancient interfaces.

yeah, AMD prompted it with a few of their changes...

but, MS could have avoided the problem by essentially migrating both NTVDM
and DOS support into an interpreter (which would itself provide segmentation
and v86).

a lot of the rest of what was needed (to glue the interpreter to Win64) was
likely already implemented in getting WoW64 working, ...

this way, we wouldn't have been stuck needing DOSBox for software from
decades-past...

if DOSBox can do it, MS doesn't have "that" much excuse, apart from maybe
that they can no longer "sell" all this old software, so for them there is
not as much market incentive to keep it working...

==============================================================================

You received this message because you are subscribed to the Google Groups "comp.lang.c"
group.

To post to this group, visit http://groups.google.com/group/comp.lang.c?hl=en

To unsubscribe from this group, send email to comp.lang.c+unsubscribe@googlegroups.com

To change the way you get mail from this group, visit:
http://groups.google.com/group/comp.lang.c/subscribe?hl=en

To report abuse, send email explaining the problem to abuse@googlegroups.com

==============================================================================
Google Groups: http://groups.google.com/?hl=en

twitter

Thursday, January 14, 2010

comp.lang.c - 25 new messages in 9 topics - digest

0 Comments:

Post a Comment

About Me

Previous Posts