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

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

comp.lang.c@googlegroups.com

Today's topics:

==============================================================================
TOPIC: substring finding problem!
http://groups.google.com/group/comp.lang.c/t/cf9bd97208e0c3a3?hl=en
==============================================================================

== 1 of 2 ==
Date: Mon, Feb 15 2010 11:46 pm
From: spinoza1111

On Feb 16, 3:47 am, Seebs <usenet-nos...@seebs.net> wrote:
> On 2010-02-15, Chris M. Thomasson <n...@spam.invalid> wrote:
>
> > "spinoza1111" <spinoza1...@yahoo.com> wrote in message
> >news:292491f2-c3ca-45ae-8d8e-355c56325544@x1g2000prb.googlegroups.com...
> >> But by saying "it took me a half hour" I read an implied, perhaps
> >> unintended slight at the approximately six hours I took ... where only
> >> in dysfunctional corporations is it a bad thing to take a little extra
> >> care and a little extra time in anticipation of difficulty.
> > I actually meant nothing by it. Quite frankly, now that I think about it, I
> > don't actually know why I posted how long it took me. I mean, who cares
> > right?
>
> Right.
>
> That said, I *did* mean a slight at the alleged six hours Nilges took to
> produce a much buggier implementation, because that suggests that his
> methodology is bad -- and since he posted his originally specifically as
> a criticism of my off-the-cuff example I posted in another thread, I
> figured he was looking for comparisons.
>
> In short, he posted a large rant about how unprofessional and unconsidered
> and badly-designed my code was, which point he "proved" by demonstrating
> that, in only ten times as many lines of code, with four or five times as
> many bugs, he could nearly solve a sort of similar problem. Very persuasive.

You only knew about the bugs because I fixed them, Peter, whereas you
never fixed the bugs you reported in your first attempt. I haven't
been tracking your other code in detail because it doesn't interest
me, but I see in your posts nothing like diligence in testing. You're
so worried about taking "too long", having been in my view corrupted
by corporate life, that you created nothing like a systematic and
growing test suite (I did) nor did you systematically track and
document bugs and changes (I did).

In fact, most of the "six hours" I spent was in documentation and test
creation, not coding. How dare you even compare your buggy and
amateurish work?

If you look at the latest text of "my" replace, you'll see in the
Change Record that each bug save one is labeled with "bug:": one is
labeled "bug fix".

There were, in fact, only five bugs.

And, of course, you're counting in "lines of code" the test suite that
many other posters including Willem have found useful, but which you
probably dare not use.

>
> >> A week late, in this thread, Seebach, Bacarisse et al. seem to be
> >> running into confusion trying to help the OP meet the original
> >> challenge. But I note nobody harassing them or the original poster,
> >> targeting them for abuse.
> > What challenge?
>
> I have no clue.
>
> This whole thing started because I posted a snippet of code I found
> interesting to make for some vaguely topical stuff. Nilges responded with
> angry rants about how bad my code was and a gigantic, buggy, "solution"
> to the problem.

Five bugs. All fixed. YOU NEVER FIXED the %s bug.

>
> >> Without knowing as much about C as the regs, esp. postmodern C and the
> >> standards (I'll be the first to concede this), I've left them in the
> >> dust as regards my challenge.
> > Again, what challenge are you referring to?
>
> The one he thinks it's very offensive that you implied existed.
>
> He's not exactly consistent. At any given time, he believes whatever he
> feels makes him look best. This can result in him believing wildly
> contradictory things over the course of a post.

Your limitations are not my contradictions,
Your failures are not mine,
Your misery is your own history,
So, dear boy, don't whine.

>
> > Finding a bug is damn good thing! Nothing wrong with that. I hate it when
> > somebody gets pissed off when I find a bug in some of their code. They don't
> > even thank you for pointing it out to them!
>
> Agreed!

Asshole. I've bent over backward to acknowledge whatever contributions
you've made. You won't even respond to email.
>
> > I just cannot really understand why you are trying to avoid `string.h' in
> > all cases. I mean, if you wanted to re-implement `strstr()', well, that's
> > fine. However, I don't see a real need to roll your own version of
> > `strlen()' or `memcpy()'. I mean, how can you do better than a good
> > implementation of the standard C library? An implementation of `memcpy()'
> > will most likely be using processor specific instructions that provide a
> > level of efficiency that cannot be reached with 100% pure portable C code.
>
> I have no clue. I also don't see why he thinks my posts about his buggy
> code have anything to do with the time or effort it takes to get this done.
> When he proposed a more general problem than the one my original effort
> solved, I posted a proposed solution, which took about ten minutes to write,

It uses string.h. It doesn't meet the challenge. God damn, boy, you
are a liar, aren't you?

If I missed where you wrote a bug free replace() without using
string.h, post it

*HERE*

so we can evaluate it.

> and in which one bug was found so far. (It went into an infinite loop if you
> had it matching a zero-length substring.) I fixed that, and it's done. So
> far as I can tell, it works for all inputs that don't exhaust memory or
> size_t or something similar, and is otherwise unexceptional because the
> task is fundamentally a very trivial one.
>
> -s
> --
> Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.nethttp://www.seebs.net/log/<-- lawsuits, religion, and funny pictureshttp://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

== 2 of 2 ==
Date: Tues, Feb 16 2010 3:50 am
From: "bartc"

spinoza1111 wrote:
> On Feb 16, 3:13 am, "Chris M. Thomasson" <n...@spam.invalid> wrote:

>> roll your own version of `strlen()' or `memcpy()'. I mean, how can
>> you do better than a good implementation of the standard C library?
>> An implementation of `memcpy()'
>
> Actually, in terms of efficiency one often can. Library writers are
> men of flesh and blood, and women too.

But different men for different implementations. When you write your
strlen() equivalent, you are only going to write one, not dozens. And if you
stick to portable C, it might not be faster.

>> will most likely be using processor specific instructions that
>> provide a level of efficiency that cannot be reached with 100% pure
>> portable C code.
>
> How is that possible? The compiler of the library code will emit
> "processor specific" instructions, to be sure, but it will do the same
> for me, or any man. And if the library code forces out assembler code,
> then it will only work on one processor, or at best small n processor.

I think standard library routines can be written in a language other than C,
or some mix. For example, hand-written assembly.

And the library you use comes with the processor; switch processors, and
there could be a different library routine, optimised a different way (or
just optimised down by the compiler to a couple of inline machine
instructions).

--
Bartc

==============================================================================
TOPIC: Knowing the implementation, are all undefined behaviours become
implementation-defined behaviours?
http://groups.google.com/group/comp.lang.c/t/4f8b56b26018cf4e?hl=en
==============================================================================

== 1 of 5 ==
Date: Tues, Feb 16 2010 12:12 am
From: tonydee

On Feb 14, 10:23 pm, pete <pfil...@mindspring.com> wrote:
> Michael Tsang wrote:
> > undefined behaviour
>
> The way that term is used in the standard,
> is to describe programs outside of any context.
>
> The question is,
> "Does the standard place any limitions
> on the behavior of this program?"
> If the answer is "No", then you have undefined behavior.
>
> I think it is simplest to consider
> the behavior of an otherwise correct
> program which executes this statement
> return (1 / (CHAR_BIT - 7));
> as being implementation defined

The way you're contrasting this with "/ (CHAR_BIT - 9)" suggests you
believe CHAR_BIT >= 8. I've heard rumours of systems where it was 7,
but let's ignore that.

I don't believe that your example is implementation defined vis-à-vis
the Standard.

"1.4 Definitions
[intro.defs]

--implementation-defined behavior: Behavior, for a well-formed
program
construct and correct data, that depends on the implementation
and
that each implementation shall document."

If your code divides 1 by some positive value, that has a well-defined
meaning and flow of control that is common to all C++ compilers/
environments, though the exact divisor and result may vary. Nothing
here needs to be documented per implementation.

> and the the behavior of an otherwise correct
> program which executes this statement
> return (1 / (CHAR_BIT - 9));
> as being undefined.

Only on a system where CHAR_BIT was equal to 9 would this result in
undefined behaviour. From the Standard:

5.6 Multiplicative operators [expr.mul]

4 ...
If the second operand of / or % is zero the behavior is unde-
fined; otherwise (a/b)*b + a%b is equal to a. If both operands
are
nonnegative then the remainder is nonnegative; if not, the sign of
the
remainder is implementation-defined

This applies at run-time. A program doesn't have some static property
of "undefined behaviour" just because some unsupported inputs could
cause undefined behaviour at run-time. That said, given CHAR_BIT may
be constant for a particular version of a compiler on a particular
system, it may be that compiling and running the program in that
environment will always generate undefined behaviour. Taking the code
in isolation from the compilation environment, it's more likely to
provide a negative divisor, triggering the mixed-signs clause above
and hence implementation-defined behaviour. So, there are three
possible run-time outcomes based on static analysis of the source
code: undefined behaviour, implementation defined behaviour, and well-
defined behaviour.

Cheers,
Tony

== 2 of 5 ==
Date: Tues, Feb 16 2010 12:24 am
From: Nick Keighley

On 16 Feb, 08:12, tonydee <tony_in_da...@yahoo.co.uk> wrote:

> [this] suggests you
> believe CHAR_BIT >= 8. I've heard rumours of systems where it was 7 [...]

CHAR_BIT cannot be less than 8 on a standard conforming C (or C++)
implementation

== 3 of 5 ==
Date: Tues, Feb 16 2010 12:27 am
From: Richard Heathfield

[I note the cross-post to clc++. My answer is given in a C context,
which may or may not also apply to C++.]

tonydee wrote:
> On Feb 14, 10:23 pm, pete <pfil...@mindspring.com> wrote:
<snip>

>> I think it is simplest to consider
>> the behavior of an otherwise correct
>> program which executes this statement
>> return (1 / (CHAR_BIT - 7));
>> as being implementation defined
>
> The way you're contrasting this with "/ (CHAR_BIT - 9)" suggests you
> believe CHAR_BIT >= 8. I've heard rumours of systems where it was 7,
> but let's ignore that.

Yes, let's, since CHAR_BIT is *required* to be >= 8 on conforming
implementations.

> I don't believe that your example is implementation defined vis-à-vis
> the Standard.

The CHAR_BIT - 7 one is implementation-defined. The implementation
defines it by defining CHAR_BIT (as it is required to do), which is at
least 8 but which can be greater. So the result of the expression 1 /
(CHAR_BIT - 7) will be 1 unless CHAR_BIT exceeds 8, in which case it
will be 0.

When we shift to CHAR_BIT - 9, however, the result can be -1 (for
CHAR_BIT of 8), or 1 (for CHAR_BIT of 10), or 0 (for CHAR_BIT of 11+),
or undefined (for CHAR_BIT of 9). So, if all we can observe is the
source (i.e. we don't know the implementation), the safest observation
we can make is that the code exhibits undefined behaviour and should be
changed.

<snip>

> If your code divides 1 by some positive value, that has a well-defined
> meaning and flow of control that is common to all C++ compilers/
> environments, though the exact divisor and result may vary. Nothing
> here needs to be documented per implementation.

CHAR_BIT does. Since the result of the expression depends on that value,
the behaviour is effectively implementation-defined.

<snip>

--
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 5 ==
Date: Tues, Feb 16 2010 1:33 am
From: tonydee

On Feb 16, 5:27 pm, Richard Heathfield <r...@see.sig.invalid> wrote:
> [I note the cross-post to clc++. My answer is given in a C context,
> which may or may not also apply to C++.]
>
> tonydee wrote:
> > On Feb 14, 10:23 pm, pete <pfil...@mindspring.com> wrote:
>
> >> I think it is simplest to consider
> >> the behavior of an otherwise correct
> >> program which executes this statement
> >> return (1 / (CHAR_BIT - 7));
> >> as being implementation defined
>
> > I don't believe that your example is implementation defined vis-à-vis
> > the Standard.
>
> The CHAR_BIT - 7 one is implementation-defined. The implementation
> defines it by defining CHAR_BIT (as it is required to do), which is at
> least 8 but which can be greater. So the result of the expression 1 /
> (CHAR_BIT - 7) will be 1 unless CHAR_BIT exceeds 8, in which case it
> will be 0.

The _value_ of CHAR_BIT is implementation defined. Programs that
incorporate the value into the division above always receive a result
that's entirely specified - as a function of the inputs - by the
Standard. The division process and behaviour are well defined. I
don't think it's correct or useful to imagine that all behaviour
consequent to something implementation defined is itself
implementation defined.

If we look at what was being said:

> >> I think it is simplest to consider
> >> the behavior of an otherwise correct
> >> program which executes this statement
> >> return (1 / (CHAR_BIT - 7));
> >> as being implementation defined

Surely it is implied that it's the use of CHAR_BIT in the division,
and not CHAR_BIT itself, which might make the expression
implementation defined? I'm saying that in that exact but limited
sense, it's moved past the implementation defined aspect and division
behaviour is well defined.

> When we shift to CHAR_BIT - 9, however, the result can be -1 (for
> CHAR_BIT of 8), or 1 (for CHAR_BIT of 10), or 0 (for CHAR_BIT of 11+),
> or undefined (for CHAR_BIT of 9). So, if all we can observe is the
> source (i.e. we don't know the implementation), the safest observation
> we can make is that the code exhibits undefined behaviour and should be
> changed.

Again, this misses the subtlety I was trying to communicate. "The
code exhibits undefined behaviour" is misleading. It's only exhibited
when it happens. It certainly _can_ exhibit undefined behaviour, but
there are many environments where it will run with well-defined
behaviour. There may even be a compile time assertion that CHAR_BIT !
= 9 somewhere above. While any good program would handle this issue
is a robust fashion, but it's not a precondition for avoiding
undefined behaviour when the implementation has CHAR_BIT != 9. It
boils down to a defensive programming consideration.

> > If your code divides 1 by some positive value, that has a well-defined
> > meaning and flow of control that is common to all C++ compilers/
> > environments, though the exact divisor and result may vary. Nothing
> > here needs to be documented per implementation.
>
> CHAR_BIT does. Since the result of the expression depends on that value,
> the behaviour is effectively implementation-defined.

(Discussed again above.)

Cheers,
Tony

== 5 of 5 ==
Date: Tues, Feb 16 2010 1:41 am
From: Richard Heathfield

tonydee wrote:

<snip>

> I don't think it's correct or useful to imagine that all behaviour
> consequent to something implementation defined is itself
> implementation defined.

It is clear that you have thought this through. I, too, have thought
this through. We have arrived at opposite conclusions. (This is hardly a
unique phenomenon.) And it seems unlikely that either of us will change
our position through debate.

I suggest, then, that we agree to disagree. :-)

<snip>

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

==============================================================================
TOPIC: arrays
http://groups.google.com/group/comp.lang.c/t/62c4e3bdb2bd43fa?hl=en
==============================================================================

== 1 of 2 ==
Date: Tues, Feb 16 2010 12:25 am
From: achp

On 16 фев, 01:29, Keith Thompson <ks...@mib.org> wrote:
> This:
>
> int arr[10];
> printf("%p %p\n", (void*)&arr, (void*)arr);
>
> will almost certainly print the same value twice.

Why "almost"? I cannot see any reason for "almost". I believe it
*must* print the same value twice.

== 2 of 2 ==
Date: Tues, Feb 16 2010 12:27 am
From: Richard Heathfield

achp wrote:
> On 16 фев, 01:29, Keith Thompson <ks...@mib.org> wrote:
>> This:
>>
>> int arr[10];
>> printf("%p %p\n", (void*)&arr, (void*)arr);
>>
>> will almost certainly print the same value twice.
>
> Why "almost"? I cannot see any reason for "almost". I believe it
> *must* print the same value twice.

What is the basis of your belief?

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

==============================================================================
TOPIC: Efficency and the standard library
http://groups.google.com/group/comp.lang.c/t/ad9fea19f2f7dd61?hl=en
==============================================================================

== 1 of 3 ==
Date: Tues, Feb 16 2010 1:07 am
From: Nick Keighley

On 15 Feb, 14:40, spinoza1111 <spinoza1...@yahoo.com> wrote:
> On Feb 15, 6:32 pm, websnarf <websn...@gmail.com> wrote:
> > On Feb 14, 8:16 pm, "Chris M. Thomasson" <n...@spam.invalid> wrote:
> > > On Feb 15, 7:33 am, websnarf <websn...@gmail.com> wrote:

> Until very recently, I thought that bit length was an unacceptable
> restriction on string length, but if one ponders the scale of long
> long, it is more than enough.

if you mean (I don't find "bit length" very clear) a character count
and a collection of characters and using long long as the count then
small strings have a heft overhead.

"hello" has more space devoted to the count than the character data

== 2 of 3 ==
Date: Tues, Feb 16 2010 1:34 am
From: spinoza1111

On Feb 16, 5:07 pm, Nick Keighley <nick_keighley_nos...@hotmail.com>
wrote:
> On 15 Feb, 14:40,spinoza1111<spinoza1...@yahoo.com> wrote:
>
> > On Feb 15, 6:32 pm, websnarf <websn...@gmail.com> wrote:
> > > On Feb 14, 8:16 pm, "Chris M. Thomasson" <n...@spam.invalid> wrote:
> > > > On Feb 15, 7:33 am, websnarf <websn...@gmail.com> wrote:
> > Until very recently, I thought that bit length was an unacceptable
> > restriction on string length, but if one ponders the scale of long
> > long, it is more than enough.
>
> if you mean (I don't find "bit length" very clear) a character count
> and a collection of characters and using long long as the count then
> small strings have a heft overhead.
>
> "hello" has more space devoted to the count than the character data

Hmm, good point. The vast majority of strings fit in int or even short
or even byte, and the counts of strings probably increase
exponentially from long long to long to int to short to byte.

OK, use a byte for string length in a linked list. When you need the
total length sum the byte lengths in a long long. Shouldn't be a
problem for 90% of all strings.

Then, "hello" would take

1 byte length
4 (?) byte pointer to value
6 bytes for the value

You do agree that you're gonna need more bytes than are in the string.
We could get rid of the NUL bytes by storing the segment length and
not the length of the string in the linked list node, and whenever we
need the "real" length, walking the list.

But note that I fall here into the trap that Heathfield apparently
fell into in C Unleashed with his less than amazing linked list: some
calls to my string thingie blow up.

Better, then, to put the total length in the first node.

== 3 of 3 ==
Date: Tues, Feb 16 2010 1:31 am
From: "Chris M. Thomasson"

"spinoza1111" <spinoza1111@yahoo.com> wrote in message
news:c412fe87-400b-4528-bd8d-0a1f1b801ab9@o16g2000prh.googlegroups.com...
On Feb 16, 2:57 am, "Chris M. Thomasson" <n...@spam.invalid> wrote:
> > "spinoza1111" <spinoza1...@yahoo.com> wrote in message
> >
> > news:6ae1ff4f-5c5e-4111-ade6-5b7ca0b5a83c@k5g2000pra.googlegroups.com...
> > [...]
> >
> > > It was hard to get my doubly linked list working, but I did. It would
> > > have been nice to have a separate tool for linked lists. Richard
> > > Heathfield appears to have published such a tool in 2000, in C
> > > Unleashed, but as far as I can determine (see elsethread), the
> > > Dickiemaster copies the actual values into the list. This would have
> > > blown me to Kingdom Come. I THINK the Heathman wanted to avoid using
> > > pointer to void (he is welcome to comment here).
> >
> > I don't know why Richard implemented a simple linked-list that way. I
> > take
> > it he is not that fond of intrusive linked lists.

> But his solution IS intrusive, unless by "intrusive" you mean
> something else.

I mean why not embed the list node directly into a data-structure? The list
nodes intrudes into the object.

> > A linked list of pointers (the right way) is only "intrusive" in that
> > it consists of a set of eyes looking at data.
> >
> > Whereas to copy *anything* into your linked list is asking for
> > trouble, since you're both looking at data and grabbing it. Eyes and
> > paws.

> > > However, preprocessor macro implementation of linked list would avoid
> > > both copying entries and pointer to void. But it would be at that
> > > point in which I would ask myself, like Ross Perot's running mate VAdm
> > > Jim Stockdale in 1992, "Who am I? Why am I here? And why am I not
> > > coding in C Sharp, or getting laid?"
> >
> > What about intrusive data-structures that do not require any copying
> > and/or
> > void pointers? I use them all the time.

> That was my idea...use a macro for strong typing.

I was thinking of the following technique. Here, let me quickly code up a
simple example:
_______________________________________________________________
#include <stdio.h>
#include <stddef.h>

#define CONTAINS(mp_self, mp_type, mp_member) \
((mp_type*)(((unsigned char*)(mp_self)) - \
offsetof(mp_type, mp_member)))

struct slist
{
struct slist* next;
};

#define SLIST_SINIT { NULL }

#define slhead(mp_self) ((mp_self)->next)

void
slpush(struct slist* const self,
struct slist* node)
{
node->next = self->next;
self->next = node;
}

struct slist*
slpop(struct slist* const self)
{
struct slist* node = self->next;
if (node) self->next = node->next;
return node;
}

void
slreverse(struct slist* const self)
{
struct slist* head = NULL;
struct slist* node = self->next;

while (node)
{
struct slist* next = node->next;
node->next = head;
head = node;
node = next;
}

self->next = head;
}

struct foo
{
char const* string;
struct slist node1;
struct slist node2;
};

#define FOO_SINIT(mp_string) \
{ (mp_string), SLIST_SINIT, SLIST_SINIT }

int main()
{
struct slist* node;
struct slist list1 = SLIST_SINIT;
struct slist list2 = SLIST_SINIT;

struct foo foo[] =
{
FOO_SINIT("One"),
FOO_SINIT("Two"),
FOO_SINIT("Three"),
FOO_SINIT("Four"),
FOO_SINIT("Five")
};

size_t i;
size_t depth = sizeof(foo) / sizeof(foo[0]);

for (i = 0; i < depth; ++i)
{
slpush(&list1, &foo[i].node1);
slpush(&list2, &foo[i].node2);
}

slreverse(&list2);

node = slhead(&list1);

while (node)
{
struct foo* f = CONTAINS(node, struct foo, node1);

printf("(%p)->foo(%s)\n",
(void*)f,
f->string);

node = node->next;
}

puts("--------------------------------------------------");

node = slhead(&list2);

while (node)
{
struct foo* f = CONTAINS(node, struct foo, node2);

printf("(%p)->foo(%s)\n",
(void*)f,
f->string);

node = node->next;
}

return 0;
}
_______________________________________________________________

The `struct slist' objects intrude upon the `struct foo' objects. Now, you
can create a generic set of functions that operate on `struct slist' objects
regardless of what they are embedded within (e.g., see the `slreverse()'
function).

==============================================================================
TOPIC: How to force fgets read from file instead of buffer cache?
http://groups.google.com/group/comp.lang.c/t/1bf5e211a06eb016?hl=en
==============================================================================

== 1 of 2 ==
Date: Tues, Feb 16 2010 1:33 am
From: "luke.yolanda@gmail.com"

Hello everybody,

Actually, I'm trying to read (no write operation) from proc filesystem
periodically. It turns out that after first read, all subsequent read
are go to buffercache, not the proc fs (therefore, get the same value
every time). This problem can be avoided by closing and open it again
after each read, but I'm wondering if there's a better solution?

Thank you very much!

Gen

== 2 of 2 ==
Date: Tues, Feb 16 2010 2:03 am
From: gwowen

On Feb 16, 9:33 am, "luke.yola...@gmail.com" <luke.yola...@gmail.com>
wrote:

> Actually, I'm trying to read (no write operation) from proc filesystem
> periodically. It turns out that after first read, all subsequent read
> are go to buffercache, not the proc fs

If you are using Linux, I rather suspect this is not the problem. You
don't provide enought information to be any more helpful than that,
I'm afraid.

==============================================================================
TOPIC: Experiment: functional concepts in C
http://groups.google.com/group/comp.lang.c/t/7889fc59043eb32b?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Feb 16 2010 1:42 am
From: Phil Carmody

Nobody <nobody@nowhere.com> writes:
> Many programs initialise a lot of data at startup then never touch it
> again unless you use that particular feature. There's no point having such
> data locked into RAM when there are better ways to use it.
>
> Similarly, modern desktop systems tend to run a lot of programs which are
> "running" for as long as you're logged in but seldom see actual use.

Hey, don't forget about mobile phones - they do that too!

And your two paragraphs are linked. Because there's so much
unnecessary crap happening at program startup, one can no
longer afford to start them on demand - they need to be pre-
started. Which means that they have to hang around while you're
not using them.

Phil
--
Any true emperor never needs to wear clothes. -- Devany on r.a.s.f1

==============================================================================
TOPIC: Warning to newbies
http://groups.google.com/group/comp.lang.c/t/9597fd702985dff4?hl=en
==============================================================================

== 1 of 3 ==
Date: Tues, Feb 16 2010 1:50 am
From: Nick Keighley

On 16 Feb, 05:49, spinoza1111 <spinoza1...@yahoo.com> wrote:

[...]

> Replace "egregious" by "x" in "egregious"
> Expect "x":
> "x"
>
> Replace "egregious" by "x" in ""
> Expect "":
> ""
>
> Testing complete: check output carefully

you could avoid this by making your test subroutine do the check for
you. The TDD people rave about this. Plauger's Library book uses
assert() as a simple test harness.

== 2 of 3 ==
Date: Tues, Feb 16 2010 3:43 am
From: "io_x"

"spinoza1111" <spinoza1111@yahoo.com> ha scritto nel messaggio
news:3691d046-5aa6-41c0-a036-5c8790cf57df@w27g2000pre.googlegroups.com...
>I don't understand. If you claim this "beat" me, would you mind
>posting a console output with the test suite in my program? I was
>willing to concede to Willem and am willing to concede to you,
>although I find your code "hard" to read. The readability of my code
>is a readability to someone with a high level of English, therefore,
>in resolving this "contest", we should just forget about
>"readability", since we seem to have coders of all nations.
>
>This is turning into the Vancouver Olympics...

If you not care of readability, not for languages programming, compiler and OS
and little macros, this would be one asm-cpp program

[in few words the function has 2 pass
first pass:
calculate the final string len
second pass
reserve memory for that len
and copy the string and
(has in count that the original strings can be chaged)]

/* bcc32 -v file.cpp asmfile.obj */
#include <stdio.h>
#include <stdlib.h>
#include <string.h>

#define P printf
#define R return

extern "C" char* __stdcall
Replacer_m(unsigned* len, char* origin, char* whatSost, char* sost);

// origin has to came from malloc memory
int Print(char** origin, char* whatSost, char* sost)
{char *p;
unsigned len;
int i;
p=Replacer_m(&len, *origin, whatSost, sost);
if(p==0) return 0;
P("Origin=%s|WhatS=%s|Sost=%s\n", *origin, whatSost, sost);
P("Result=%s len=%u slen=%u\n", p, len, strlen(p));
free(*origin); *origin=p;
R 1;
}

// origin has to came from malloc memory
int tester(char* origin, char* whatSost, char* sost,
char* expected, unsigned n)
{char *p;
unsigned len;
int i;

p=Replacer_m(&len, origin, whatSost, sost);
if(p==0) R 0;
if(strcmp(expected, p)!=0 || len!=strlen(p))
{P("I find one error on test %u:\n", n);
P("Origin=%s|WhatS=%s|Sost=%s\n", origin, whatSost, sost);
P("Expect \"%s\":\nResult \"%s\"\n", expected, p);
P("lenResult=%u strlenResult=%u\n", len, strlen(p));
free(p);
R 0;
}
free(p);
return 1;
}

// ---------------------------------------------------------------
// Main procedure
//
//
int test1(void)
{ unsigned r;
P("\n\nTest1\n");
r=1;
r*=tester("a stupid error","stupid error","miracle","a miracle", 1);
r*=tester("a stupid error","stupid","miracle","a miracle error", 2);
r*=tester("the stupid error","the stupid error","a miracle",
"a miracle", 3);
r*=tester("the miracle","the","a","a miracle", 4);
r*=tester("a miraclsnirpKamunkle","snirpKamunkle","e",
"a miracle", 5);
r*=tester("a miraclesnirpKamunkle","a miracle",
"","snirpKamunkle", 6);
r*=tester(" a miraclesnirpKamunkle","a miracle",
""," snirpKamunkle", 7);
r*=tester(" a miraclesnirpKamunklea miraclea miracle","a miracle",
""," snirpKamunkle", 8);
r*=tester("a miracle a miraclesnirpKamunkle a Miraclea miraclea miracle",
"a miracle",""," snirpKamunkle a Miracle", 9);
r*=tester("a stupid errord","stupid error","miracle","a miracled", 10);
r*=tester("a stupid errod","stupid error","miracle","a stupid errod", 11);
r*=tester("a sstupid error","stupid error","miracle","a smiracle", 12);
r*=tester("a stupid errorstupid error","stupid error","miracle",
"a miraclemiracle", 13);
r*=tester("a stupid error stupiderror","stupid error","miracle",
"a miracle stupiderror", 14);
r*=tester("bbbbbbbbbb","b","a","aaaaaaaaaa", 15);
r*=tester("In the halls of R'yleh great %s lies dreaming","%s",
"Cthulu","In the halls of R'yleh great Cthulu lies dreaming", 16);
r*=tester("%s%s%s%s%s%s","%s","Cthulu",
"CthuluCthuluCthuluCthuluCthuluCthulu", 17);
r*=tester("banana","ana","oat","boatna", 18);
r*=tester(" a stupid errorstupid errorHeystupid errors","stupid error",
"+"," a ++Hey+s", 19);
r*=tester("foo barfoo barf","foo bar","bas","basbasf", 20);
r*=tester("abab","ba","ba","abab", 21);
r*=tester("a", "a", "b", "b", 22);
r*=tester("1111123bbb1111123bbb11123bb11111231111112111111123",
"111123", "ono",
"1onobbb1onobbb11123bb1ono1111112111ono", 23);
r*=tester("bbb1111123bbbbb", "111123", "ono", "bbb1onobbbbb", 24);
r*=tester("a stupid error", "stupid error", "miracle", "a miracle", 25);
r*=tester("a stupid error", "stupid", "miracle", "a miracle error", 26);
r*=tester("the stupid error", "the stupid error", "a miracle",
"a miracle", 27);
r*=tester("the miracle", "the", "a", "a miracle", 28);
r*=tester("a miraclsnirpKamunkle", "snirpKamunkle", "e", "a miracle", 29);
r*=tester("a miraclesnirpKamunkle", "a miracle", "", "snirpKamunkle", 30);
r*=tester(" a miraclesnirpKamunkle","a miracle", ""," snirpKamunkle", 31);
r*=tester(" a miraclesnirpKamunklea miraclea miracle", "a miracle", "",
" snirpKamunkle", 32);
r*=tester("a miracle a miraclesnirpKamunkle a Miraclea miraclea miracle",
"a miracle", "", " snirpKamunkle a Miracle", 33);
r*=tester("a stupid errord", "stupid error", "miracle", "a miracled", 34);
r*=tester("a stupid errod", "stupid error",
"miracle", "a stupid errod", 35);
r*=tester("a sstupid error", "stupid error","miracle", "a smiracle", 36);
r*=tester("a stupid errorstupid error", "stupid error", "miracle",
"a miraclemiracle", 37);
r*=tester( "a stupid error stupiderror", "stupid error", "miracle",
"a miracle stupiderror", 38);
r*=tester("bbbbbbbbbb", "b", "a", "aaaaaaaaaa", 39);
r*=tester("In the halls of R'yleh great %s lies dreaming", "%s",
"Cthulu",
"In the halls of R'yleh great Cthulu lies dreaming", 40);
r*=tester("%s%s%s%s%s%s", "%s", "Cthulu",
"CthuluCthuluCthuluCthuluCthuluCthulu", 41);
r*=tester("banana", "ana", "oat", "boatna", 42);
r*=tester(" a stupid errorstupid errorHeystupid errors", "stupid error",
"+", " a ++Hey+s", 43);
r*=tester("foo barfoo barf", "foo bar", "bas", "basbasf", 44);
r*=tester("abab","ba","ba", "abab", 45);
r*=tester("abab", "bab", "boop", "aboop", 46);
r*=tester( "banana", "ana", "ono", "bonona", 47);
r*=tester( "a", "x", "b", "a", 48);
r*=tester("x","x","b","b", 49);
r*=tester("egregious","egregious","egregious", "egregious", 50);
r*=tester("egregious","egregious","x","x", 51);
r*=tester("","","","", 52);
r*=tester("x","x","","", 53);
r*=tester("x", "","","x", 54);
if(r==0) {P("Test 1: Some error occurs\n\n"); R 0;}
r=tester(0,0,0,0,55);
if(r==0) P("Test 1: Find No error\n\n");
else {P("Test 1: the 0 arg Error\n\n"); R 0; }
R 1;
}

int main(void)
{test1();
return 0;
}
-----------------
; nasmw -fobj asmfile.asm
section _DATA use32 public class=DATA

global Replacer_m
extern _realloc
extern _free

section _BSS use32 public class=BSS
section _TEXT use32 public class=CODE

; i8* __stdcall
; Replacer_m(u32* len, i8* origin, i8* whatSost, i8* sost)
; La Funzione alloca in memoria dinamica un array
; dove viene copiato tutta "origin" dove ogni sottostringa
; in "origin" che contiene
; "whatSost" viene sostituita dalla stringa "sost".
;
; Se non sono stati trovati errori, ritorna tale stringa
; da liberare successivamente con free, e la lunghezza
; della stringa ritornata in "len" e CF=0
;
; Altrimenti se quache errore viene trovato: ritorna 0
; [len=0] CF=1
;
; La funzione calcola la presunta lunghezza dell'array
; riserva la memoria, fa la copia nella memoria allocata
; tenendo conto che e' possibile che le stringhe di origine
; siano cambiate da questo programma o da un altro programma.
;
; esempio:
; u32 len;
; i8 *p;
; p=Replacer_m(&len, "qwerty", "ty", "1111111");
; if(p) printf("%s\n", p);
; else printf("Errore\n")
; free(p);
; risultato -> "qwer1111111"
; 0k,4j,8i,12b,16ra, 20P_Len, 24P_fmt, 28P_WhatSost 32P_Sost + 64
; 84 88 92 96
; 0LedSostitStringa, 4sizeOfResult, 8LedSrtingaSubst\0
; 12LedTheSecondPass
align 4
Replacer_m:
push ebx
push esi
push edi
push ebp
sub esp, 64
cmp dword[esp+ 84], 0
je .e0
mov esi, dword[esp+ 88]
cmp dword[esp+ 92], 0
je .e0
cmp dword[esp+ 96], 0
je .e0
cmp esi, 0
je .e0
mov eax, dword[esp+ 84]
mov dword[eax], 0
mov edi, 0
mov dword[esp+ 0], 0
mov dword[esp+ 4], 0
mov dword[esp+ 8], 0
mov dword[esp+ 12], 0
mov ebx, 0
jmp short .0
.e: push edi
call _free
add esp, 4
.e0: xor eax, eax
stc
jmp .z
.0: cmp ebx, dword[esp+ 4]
jb .1
cmp dword[esp+ 12], 0
je .1
mov ecx, ebx
add ecx, 32
push ecx
push ecx
push edi
call _realloc
add esp, 8
pop ecx
cmp eax, 0
je .e
mov edi, eax
mov dword[esp+ 4], ecx
.1: cmp dword[esp], 1
jne .3
xor eax, eax
mov al, [ebp]
cmp eax, 0
jne .2
mov dword[esp+ 0], 0
cmp dword[esp+ 8], 1
je .7
jmp short .0
.2: cmp dword[esp+ 12], 0
je .2a
mov byte[edi+ebx], al
.2a: inc ebp
inc ebx
jmp short .0
.3: mov ebp, dword[esp+ 92]
xor eax, eax
mov ecx, esi ; cerca di vedere se le stringhe sono uguali
.4: mov al, [ebp]
cmp eax, 0
je .5
cmp al, [ecx]
jne .7
inc ecx
inc ebp
jmp short .4
.5: cmp ecx, esi
jne .5a ; stringa nulla da sostituire
cmp al, [ecx]
jne .7
; se B*c==0 allora sostituisci, altrimenti continua
mov dword[esp+ 8], 1
.5a: mov dword[esp+ 0], 1
mov esi, ecx
mov ebp, dword[esp+ 96]
jmp .0
.ee: jmp .e
.7: mov al, [esi]
cmp dword[esp+ 12], 0
je .8
mov byte[edi+ebx], al
.8: inc esi
inc ebx
cmp eax, 0
je .9
jmp .0
.9: cmp dword[esp+ 12], 0
je .9a
mov eax, edi
cmp ebx, dword[esp+ 4]
je .a ; al primo passaggio ^12==0 => realloc(0, sz)
.9a: push ebx
push edi
call _realloc
add esp, 8
cmp eax, 0
je .ee
; al secondo passaggio => realloc(j, sz) oppure
.a: cmp dword[esp+ 12], 0
jne .b ; esci
mov dword[esp+ 4], ebx
mov esi, dword[esp+ 88]
mov ebx, 0
mov dword[esp+ 12], 1
mov edi, eax
jmp .0 ; inizia di nuovo ma con ^12==1
.b: mov edx, dword[esp+ 84]
dec ebx
mov [edx], ebx
clc
.z:
lea esp, [esp+64]
pop ebp
pop edi
pop esi
pop ebx
ret 16

---------------------
----------------

Test1
Test 1: Find No error
at last here

== 3 of 3 ==
Date: Tues, Feb 16 2010 3:43 am
From: "io_x"

"spinoza1111" <spinoza1111@yahoo.com> ha scritto nel messaggio
news:3691d046-5aa6-41c0-a036-5c8790cf57df@w27g2000pre.googlegroups.com...
On Feb 14, 3:56 pm, "io_x" <a...@b.c.invalid> wrote:
> "io_x" <a...@b.c.invalid> ha scritto nel
> messaggionews:4b6f10b3$0$1114$4fafbaef@reader4.news.tin.it...
>
>
>
>
>
> > ; bcc32 -v this.c that.obj
> > #include <stdio.h>
> > #include <stdlib.h>
>
> > char* __stdcall SostituisciPercS(char* fmt, char* w);
>
> > int main(void)
> > {char *a1="FirstString", *p;
>
> > p=SostituisciPercS("this is fmt %%s =%s %s %s %s % s %s %s now end\n", a1);
> > if(p==0){printf("Errore\n"); return 0;}
> > printf("%s", p);
> > free(p);
> > return 0;
> > }
> > ----------
> > this is fmt %s =FirstString FirstString FirstString FirstString % s
> > FirstString
> > FirstStrin
> > g now end
> > --------------
>
> > gotos, jumps, jn, jnz, jetc are ok
> > section _DATA use32 public class=DATA
>
> > global SostituisciPercS
> > extern _realloc
> > extern _free
>
> > section _BSS use32 public class=BSS
> > section _TEXT use32 public class=CODE
>
> > ; 0k,4j,8i,12b,16ra, 20P_fmt, 24P_etc + 64
> > ; 84 88
> > ; 0inString, 4sizeResult, 8NowArg
> > SostituisciPercS:
> > <b,i,j,k
> > s-=64
> > i=^84|a=&*s+88|^8=a ; 8 is for arg address
> > j=0 ; k=current arg, j array
> > ^0=0 |^4=0|b=0|#.0 ; 0led_isstring b is index [len]
> > .e: _free(j)
> > .e0: a^=a|stc|##.z
> > .0: b>=^4!#.1
> > c=b|c+=32|<c |_realloc(j,c)|s+=8|>c
> > a==0#.e |j=a|^4=c
> > .1: D*s==1!#.3
> > a^=a|al=*k|a==0!#.2
> > ^0=0|#.0
> > .2: B*j+b=al|++k,b|#.0
> > .3: a^=a|al=B*i
> > a=='%'!#.5
> > B*i+1=='%'!#.4
> > B*j+b ='%'|++b |i+=2|#.0
> > .4: B*i+1=='s'!#.5
> > ^0=1|a=^8 |k=*a|i+=2|##.0
> > .ee: ##.e
> > .5: B*j+b=al|++i,b|a==0#.6 |##.0
> > .6: _realloc(j, b)|s+=8|a==0#.ee
> > clc
> > .z:
> > s=&*s+64
> >>b,i,j,k
> > ret 8
>
> very good from the day one

this is false, it has at last one bug in
"_free(j)" it should be "_free<(j)" or
"_free(j)|s+=4"
any way modulo bug i wrote this post
news:4b7118b8$0$1135$4fafbaef@reader1.news.tin.it
----------------------------
#replace is not the answer for the original problem
#it can *not* handle every possible substitution
#instead
#using %s like place where has to be substitution
#and "%%" --> "%" is ok
#example
#in w="This is string sub %%s %s" with s="Sub"
#has answer g="This is string sub %s Sub"
#
#with replace it has answer
#"This is string sub %Sub Sub"
#and never like g string

#the not replace case is cover from
#w="This is string sub %%%s %s" with s="Sub"
--------------
so that routine SostituisciPercS at resolve full the
op problem (modulo bugs)

==============================================================================
TOPIC: Motivation of software professionals
http://groups.google.com/group/comp.lang.c/t/21a3fdec4dd53e6a?hl=en
==============================================================================

== 1 of 3 ==
Date: Tues, Feb 16 2010 2:09 am
From: Nick Keighley

On 16 Feb, 03:40, Seebs <usenet-nos...@seebs.net> wrote:
> On 2010-02-16, James Kanze <james.ka...@gmail.com> wrote:
> > On Feb 14, 4:56 pm, Seebs <usenet-nos...@seebs.net> wrote:
> >> On 2010-02-14, James Kanze <james.ka...@gmail.com> wrote:

> >> > To be really effective, design and code review requires a
> >> > physical meeting. Depending on the organization of the project,
> >> > such physical meetings are more or less difficult.

I've got mixed opinions on this. The real review takes place off line.
Explanation and discussion of possible solutions (I know, a code
walthru isn't supposed to consider solutions- a daft idea if you ask
me [1]) at a meeting.

Design meeetings can work.

[1] my review comments would then read "I know a much better way to do
this! Can you guess what it is {he! he!}?"

<snip>

> > That sort of thing is essential for any review. You do it
> > before the face-to-face meeting. But the reviewer isn't God,
> > either; the purpose of the meeting is to discuss the issues, not
> > to say that the coder did it wrong.

sometimes he *is* wrong! Some things get discussed/argued to death.
There is nothing more tedious than going through everey written
comment on a long list. I'd rather skip along. "Ok you accept items
1-9 but you don't understand what 10 is about- lets discuss item 10"

> If you do it well enough, I don't think the face-to-face meeting does
> anything but cater to superstition.

I find it easier to communicate with someone if I've met him in layer
1 at least once. I like a mental picture of who I'm talking to. Um
except here...

> Most people I know have had the experience of discovering that a particular
> communication worked much better in writing than it did in speech. Real-time
> mechanisms can be a very bad choice for some communications.

try dictating hex patches down a phone line. Or unix commands. You
rapidly discover Italian vowels aren't the same as ours. "ee? do you e
or i?"

Imagine if all programming specifications had to delivered in a
speech. Or chanted in iambic pentameter (no, spinoza, that's not a
challenge)

> You get more data per second if you are watching ten televisions than if
> you're watching only one. That doesn't mean that, if you want to learn a
> lot, the best way to do it is to watch multiple televisions at once. For
> that matter, while a picture may be worth a thousand words, sometimes it's
> only worth the exact thousand words it would take to describe the picture.
> Why would we read code when we could watch a movie of someone reading it,
> complete with facial expressions, tone, and guestures?
>
> Because facial expressions, tone, and guestures swamp our capacity to
> process input, and leave us feeling like we've really connected but with
> a very high probability of having completely missed something because
> we were too busy being connected to think carefully. It's like the way
> that people *feel* more productive when they multitask, but they actually
> get less done and don't do it as well.

== 2 of 3 ==
Date: Tues, Feb 16 2010 2:26 am
From: Arved Sandstrom

James Kanze wrote:
> On Feb 14, 4:54 pm, Lew <no...@lewscanon.com> wrote:
>> James Kanze wrote:
>>>> Did you actually try using any free software back in the early
>>>> 1990's [sic]?
>> Seebs wrote:
>>> I did.
>
>> Same here.
>
>>> NetBSD was for the most part reliable and bulletproof during
>>> that time; it ran rings around several commercial Unixes. I
>>> had no interest in g++; so far as I could tell, at that
>>> time, "a C++ compiler" was intrinsically unusable. But gcc
>>> was stable enough to build systems that worked reliably, and
>>> the BSD kernel and userspace were pretty livable.
>> James Kanze wrote:
>>>> Neither Linux nor g++ were even usable, and emacs (by
>
>> That's pure fantasy.
>
>> I used a couple of Linux distributions in the early nineties,
>> and they worked better than commercial UNIX variants.
>
> And I tried to use them, and they just didn't stop crashing.
> Even today, Linux is only gradually approaching the level of the
> Unixes back then.
[ SNIP ]

I have to agree with you here. My earliest use of Linux was 1993, side
by side with IRIX and SunOS. I don't remember frequent crashing of Linux
but there was no question but that the UNIX systems were more stable,
more polished and had more capability. Granted, everyone back then was
throwing Linux on old PCs, which probably didn't help, but still...

AHS

== 3 of 3 ==
Date: Tues, Feb 16 2010 2:47 am
From: Arved Sandstrom

Seebs wrote:
> On 2010-02-16, James Kanze <james.kanze@gmail.com> wrote:
>> On Feb 14, 4:56 pm, Seebs <usenet-nos...@seebs.net> wrote:
>>> On 2010-02-14, James Kanze <james.ka...@gmail.com> wrote:
>>>> To be really effective, design and code review requires a
>>>> physical meeting. Depending on the organization of the project,
>>>> such physical meetings are more or less difficult.
>
>>> Nonsense.
>
>> The more channels you have available, the better communication
>> works.
>
> Not so. Some channels can swamp others. If you're busy picking up
> facial expressions, instead of properly processing the raw data, the
> extra channel has HARMED your quality of communication.
>
>> There are probably some special exceptions, but other peoples
>> expressions and gestes are a vital part of communications.
>
> They may well be -- but my experience has been that you can communicate
> some things much better without them.
>
>> Not to mention the informal communications which occur when you
>> meet at the coffee pot. I've worked from home, and in the end,
>> I was frustrated by it because I was missing so much of the
>> informal communications which make things go.
>
> I would miss that, except that in my workplace (which spans several
> continents), the "coffee pot" is IRC.
>
>> That sort of thing is essential for any review. You do it
>> before the face-to-face meeting. But the reviewer isn't God,
>> either; the purpose of the meeting is to discuss the issues, not
>> to say that the coder did it wrong.
>
> If you do it well enough, I don't think the face-to-face meeting does
> anything but cater to superstition.
>
>> Almost universally. Ask any psychologist. We communicate
>> through many different channels.
>
> I do, in fact, have a psych degree. And what I can tell you is that, while
> there are many channels, sometimes you get better or more reliable
> communication by *suppressing* the non-analytic channels. Say, if you
> were trying to obtain accurate data about a thing subject to pure analysis,
> rather than trying to develop a feel for someone else's emotional state.
>
> The goal is not to have the largest possible total number of bits
> communicated, no matter what those bits are or what they communicate about;
> it's to communicate a narrowly-defined specific class of things, and for
> that plain text can have advantages.
>
> Most people I know have had the experience of discovering that a particular
> communication worked much better in writing than it did in speech. Real-time
> mechanisms can be a very bad choice for some communications.
[ SNIP ]

There is absolutely no question but that some things - many things -
work better in written form than in speech. Requirements specifications,
design documents, test plans and code itself are good examples.

As for code reviews I believe those can go either way. It depends on
skill levels overall, skill level differences, personalities, and
problems (or lack thereof) with prerequisite artifacts like design and
requirements. A code review that involves dysfunctional prerequisites,
dubious skill levels amongst the coders, and lots of ego - sort of a
common situation actually - is probably best handled f2f. IMHO.

But I've certainly seen code reviews that were handled nicely with no
personal interaction other than email or chat. This usually happened
when good requirements and design informed the whole discussion, all the
programmers were skilled, and the egos weren't too large.

A lot of times in a real code review you most definitely are managing
emotional state. That requires developing a feel for it, which you can't
do over chat. Seeing those blank expressions, or looks of anger, is
quite helpful in steering the review towards a somewhat productive
conclusion.

AHS

==============================================================================
TOPIC: OT: Proper use of PRNGs
http://groups.google.com/group/comp.lang.c/t/6c1d292648f8f699?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Feb 16 2010 2:34 am
From: Nick Keighley

On 15 Feb, 20:57, ralt...@xs4all.nl (Richard Bos) wrote:
> Keith Thompson <ks...@mib.org> wrote:
> > William Hughes <wpihug...@hotmail.com> writes:
> > > On Feb 10, 6:27 pm, Keith Thompson <ks...@mib.org> wrote:
> > [...]
> > >> "We must do something. This is something. Therefore, we must do this."
> > >> -- Antony Jay and Jonathan Lynn, "Yes Minister"
>
> > > I love this quote. Which show is it from?
>
> > If you mean which episode, I have no idea; I've never actually seen
> > the show.
>
> If you are at all interested in British politics - or even in Great
> Britain, or in politics - do so as soon as you can.

apparently both Margaret Thatcher (right wing politician) and Tony
Benn (left wing politician) who had both tangled with the foot
dragging ways of the British civil service thought that the program
was great and very true to life. It has also exported remarkably well.

==============================================================================
TOPIC: why it doesn't work?
http://groups.google.com/group/comp.lang.c/t/e7597b015b3aa247?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Feb 16 2010 2:51 am
From: gwowen

On Feb 15, 9:39 pm, Peter Nilsson <ai...@acay.com.au> wrote:

> But these days, all sorts of debugging information is
> available. So the question of why the standard doesn't
> require a diagnostic in this case is a valid one IMO,
> even if it should be asked in comp.std.c.

I would guess the answer is "because at the time the standard was
first written, such a clause would have required almost every linker
in the world to be rewritten at a fundamental level". Subsequent to
that the answer is "backwards compatibility".

==============================================================================
TOPIC: Earn Guaranteed Easy Money. Absolutely Free. No FAKE No HOAX
http://groups.google.com/group/comp.lang.c/t/a55818b4af834bb9?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Feb 16 2010 2:57 am
From: Naresh Kumar

Guaranteed Money Making Programs on Internet. Absolutely free.
No Fake No Hoax No Spam.
Earn by reading paid emails, clicking on Ads and banners,
Receiving SMS on your Phone / Mobile

Making Handsome Money in free time has never been so easy.

Earn money through Google Adsense. Make your own Blogs. Read all at -

http://guaranteedmoneymaking.blogspot.com

Best online money making programs for Indians and Internationals to
earn free easy and guaranteed money through Internet.

No hidden cost. No Registration Fee. Absolutely free.

Visit for more details -

http://guaranteedmoneymaking.blogspot.com

Start Earning Now...

==============================================================================
TOPIC: derived-type object
http://groups.google.com/group/comp.lang.c/t/cfab7b19dac62701?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Feb 16 2010 3:18 am
From: Ben Bacarisse

lacos@ludens.elte.hu (Ersek, Laszlo) writes:

> In article <zqGdnZnn14NXpufWnZ2dnUVZ8j6dnZ2d@bt.com>, Richard Heathfield <rjh@see.sig.invalid> writes:
>> Phred Phungus wrote:
>
>>> Why did I need to add the -lm
>>> when math.h was already included?
>>
>> There's no particular reason why adding a header should automatically
>> link in its corresponding library (other than good sense, of course!);
>> the GNU folk seem to think it makes sense to drive people nuts with
>> stupid linker error messages, and no doubt they are, in some way,
>> correct, although I can't for the life of me think in what way that
>> might be.
>
> They follow a technical standard. (I'm sure this answer qualifies as
> "good enough" in this group.)

But they could follow the same technical standard by *not* requiring
the option as both your quotes make clear:

> http://www.opengroup.org/onlinepubs/007908775/xcu/c89.html
> ----v----
> -l m
>
> This operand makes visible all functions referenced in <math.h>. An
> implementation may search this library in the absence of this operand.
> ----^----
>
> http://www.opengroup.org/onlinepubs/000095399/utilities/c99.html
> ----v----
> -l m
>
> This operand shall make visible all functions referenced in
> <math.h>, <complex.h>, and <fenv.h>. An implementation may search this
> library in the absence of this operand.
> ----^----

<snip>
--
Ben.

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

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

Tuesday, February 16, 2010

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

0 Comments:

Post a Comment

About Me

Previous Posts