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

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

comp.lang.c@googlegroups.com

Today's topics:

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

== 1 of 4 ==
Date: Thurs, Feb 18 2010 4:16 am
From: spinoza1111

On Feb 18, 2:40 pm, Richard Heathfield <r...@see.sig.invalid> wrote:
> spinoza1111wrote:
> > On Feb 18, 12:48 am, Tim Streater <timstrea...@waitrose.com> wrote:
>
> <prior nonsense snipped>
>
> >> There are certainly programmers who are unable to communicate
> >> meaningfully. I'm not one of those.
>
> > You've given no evidence here.
>
> It is ironic that you, who almost never support your own claims with
> hard facts, should ask for someone else to provide evidence. It is the
> height of hypocrisy.
>
> Nevertheless, Tim Streater is not you, and it is not unreasonable to
> expect some evidence to exist for his claims (unlike yours). I can
> provide some. (It won't convince *you*, obviously, but that doesn't
> bother me in the slightest.)
>
> I have been reading Tim Streater's articles for some time now. I have
> occasionally participated in discussions with him. In those discussions,
> I have never had any cause whatsoever to doubt his ability to
> communicate meaningfully. Anyone who wishes to assure themselves of his
> ability to communicate meaningfully need only pick a dozen samples of
> his articles at random, and read through them. (And anyone who wishes to
> discern whether his correspondent can communicate meaningfully need only
> do the same to /his/ articles.)

You're unable, as we have seen, to do a competent job at constructing
a linked list, so it stands to reason that you'll think in terms of an
external show of expertise, and make this newsgroup a popularity
contest dominated by bullies willing to lie. It's like the art dealer
told me when some thugs on the island on which I lived threatened to
disrupt my one-man show. People don't care about art anymore, just
wine, food, sex and who's in.

You don't give a flying fuck about good programming, Richard, it's
just a meal ticket for you: that's obvious. This is why you're a bully
and an enabler.
>
> <subsequent nonsense snipped>
>
> --
> 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

== 2 of 4 ==
Date: Thurs, Feb 18 2010 4:52 am
From: Richard Heathfield

spinoza1111 wrote:
>
> You're lying.

Wrong *again*.

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

== 3 of 4 ==
Date: Thurs, Feb 18 2010 5:34 am
From: Nick Keighley

On 18 Feb, 09:37, Richard Heathfield <r...@see.sig.invalid> wrote:
> Nick Keighley wrote:
> > On 18 Feb, 08:55, Malcolm McLean <malcolm.mcle...@btinternet.com>
> > wrote:
> >> On Feb 18, 2:53 am, Julienne Walker <happyfro...@hotmail.com> wrote:
>
> >>> I'm afraid I can't imagine how my meaning couldn't be clear: A linked
> >>> list of characters or an "array" of characters. These are one-
> >>> dimensional data structures, completely linear in concept, and easy to
> >>> visualize even for the most remedial of comp sci students. Combining
> >>> them adds complexity and relatively difficult design decisions.
> >> I'm working on DNA data at the moment. Currently I store it as
> >> conventional strings.
>
> >> However the data is a long list of ACGTs. A human can't possibly read
> >> it all, even small sections look meaningless after a bit. The eye is
> >> drawn to repeats and chance combinations like 'TAGACAT'.
> >> However genomes are not unstructured. Different areas have different
> >> statistical characteristics, though we don't know exactly what that
> >> means. My job, basically, is to take the raw strings and turn them
> >> into something else, something that humans can talk about in a
> >> sensible way.
> >> So I will need to build extra layers of structure on top of the
> >> strings.
>
> > are you agreeing or disagreeing?
>
> No, I don't think so.

though interesting, how does the stuff about DNA add to this sub-
thread?

== 4 of 4 ==
Date: Thurs, Feb 18 2010 6:46 am
From: Julienne Walker

On Feb 17, 9:36 pm, spinoza1111 <spinoza1...@yahoo.com> wrote:
> On Feb 18, 8:53 am, Julienne Walker <happyfro...@hotmail.com> wrote:
> > On Feb 17, 10:52 am,spinoza1111<spinoza1...@yahoo.com> wrote:
> > > On Feb 17, 10:07 pm, Julienne Walker <happyfro...@hotmail.com> wrote:
> > > > On Feb 16, 7:22 pm,spinoza1111<spinoza1...@yahoo.com> wrote:
> > > > > On Feb 16, 9:59 pm, Julienne Walker <happyfro...@hotmail.com> wrote:
> > > > > > On Feb 16, 2:28 am,spinoza1111<spinoza1...@yahoo.com> wrote:
>
> > > > > > One can alleviate that waste by storing arrays of characters in each
> > > > > > node rather than a single character, but that increases the complexity
>
> > > > > No no no no no. LINKS, please. A pointer to the segment in mallocated
> > > > > space and its length.
>
> > > > A detail quite irrelevant to my point. Now you're managing a linked
> > > > list, blocks of contiguous characters, *and* the relationship between
> > > > them to represent a single string. If the original goal is easy
> > > > modification, I'd be dubious about how successful this design is
> > > > compared to the simpler list of characters or block of characters.
>
> > > Verbiage, Julienne, of the sort that torpedoes good ideas in
> > > structured walkthroughs, because it is HARD to "modify" strings
> > > maintained as what you seem to mean by "the simpler list of characters
> > > or block of characters" (your meaning is not clear.
>
> > I'm afraid I can't imagine how my meaning couldn't be clear: A linked
> > list of characters or an "array" of characters. These are one-
> > dimensional data structures, completely linear in concept, and easy to
> > visualize even for the most remedial of comp sci students. Combining
> > them adds complexity and relatively difficult design decisions.
>
> No, "a linked list of string segments" solves our problem. You do wish
> to solve the problem, don't you?

I'm not aware there was a problem that needed to be solved. It seems
to me more like we've been discussing solutions looking for a problem.
Or do you have an application where both C-style strings and Paul's
better string library are woefully unsuitable? Having a concrete
problem to work with would make weighing alternatives a great deal
easier.

> > > If you mean that strings should be maintained in the current way, if a
> > > NUL terminated string is a "simpler" list of characters or block, then
> > > making deletions and insertions is actually quite difficult and time-
> > > consuming. It requires that the entire string, no matter how long, be
> > > completely reallocated.
>
> > As for reallocation, that really depends on the current capacity and
> > your needs. Insertion wouldn't require reallocation if the blocks
> > capacity is already large enough
>
> How do you know this?

You're not the only one with experience. ;-) But it takes little more
than common sense to see that if there's room left in the glass, you
can add more water. String libraries typically allocate more memory
than needed for that very reason. It avoids excessive calls to the
memory manager.

> >. Deletion would only require
> > reallocation if you want to trim unused memory. If strings were
> > immutable, it might be a different story, but that's not the case in
> > C.
>
> > > Whereas deletions and insertions in a linked list are always simple,
> > > both conceptually (once you get the hang of it) and in terms of
> > > computational complexity. It involves no excess or wasted movement of
> > > characters.
>
> > Agreed. But let's not forget that you have more than just the link
> > surgery of a linked list. Consider the following data structure you
> > described. Each node is a pointer to a block of characters:
>
> > "this" -> "is" -> "a" -> "test"
>
> > If this string representation were to be useful at all, you'd need to
> > support deleting parts of each block (such as the "hi" from "this")
> > and inserting inside each block. I have a hard time believing how this
> > doesn't add complexity, and depending on your design decisions, it
> > could easily involve excess or wasted movement of characters.
>
> You have a hard time believing how this doesn't add complexity because
> you haven't done this type of work, can be my only conclusion here.
> This is mental complexity not "complexity".

I say it adds complexity *because* I've done this type of work. Quite
a bit of it, actually. You have a bad habit of concluding that I don't
know what I'm talking about or haven't "done my homework" when you
disagree with me.

> > > > > > of the data structure, which means you're probably going to see a
> > > > > > performance hit. Whether that hit is significant would require
> > > > > > profiling, but even if it weren't, I'd say the benefit of a linked
> > > > > > list is no longer clear.
>
> > > > > My entire point was that Richard's approach is wrong. In fact, a
> > > > > programmer with uni compsci would never have done what he did.
>
> > > > I went home and checked my copy of the book. Personally, I think
> > > > you're overreacting. The C Unleashed design is a viable one in that
> > > > the data structure owns its data, as opposed to having the data owned
> > > > by something else and merely storing pointers to said data. In the
> > > > former case the data structure can make specific claims of correctness
> > > > and integrity while in the latter case you can end up with dangling
> > > > pointers and unexpected aliasing. On the down side, in the former case
> > > > you end up copying data around when it might not be necessary, and
> > > > making copies might not be desirable from a functionality standpoint.
>
> > > This type of "ownership" is overrated.
>
> > Please elaborate.
>
> It is purely psychological. You're insecure with my solution because I
> am not in authority over you, whereas Richard is a bully who always
> wants to get his way, and women have a tendency to defer to bullying.
> He has a sort of "virtual" authority. But the fact remains that his
> code shows no evidence of education or skill in this matter.

Lots of words and no substance. I asked for a scientific explanation
of why that type of "ownership" is overrated, not some amateur psych
evaluation. I understand both solutions as well as the advantages and
disadvantages of both. I understand that they're suitable in different
situations, but you claim that your solution is better because
"ownership" is overrated and I want to know why.

> > > However, using Richard's solution, quite apart from its performance,
> > > if the copied data changed, you end up in many scenarios with
> > > what .Net authority and nice guy Dan Appleman calls the worst kind of
> > > error...one that you don't know about.
>
> > Scenarios such as what?
>
> Richard's code is using the copy in the linked list but the original
> data is changed.

If you maintain two copies of the same data but expect only one, the
application's design is fundamentally flawed to begin with. We're
talking about the design of the linked list itself, not stupid uses of
it.

> > > Although corporate programmers without excess university training are
> > > somewhat biased, in my experience, towards copying data, I'd say it's
> > > usually better given my compiler experience in addition to my business
> > > experience to link to it.
>
> > "Usually better" may indeed be the case in your experience. In my
> > experience, linking vs. copying is situational. Now we're entering the
> > realm of objectivity, which is a good thing. Opinions are clearly
> > stated as opinion, and words are carefully chosen so as to avoid
> > making absolute statements.
>
> Such as "oh, I think you should think like a manager and not an
> engineer?" Or "in my opinion, the fact that no insulation piece has
> been, so far, has caused any damage means it's not a problem". Or, "in
> my opinion, General Shinseki, you're asking for too many troops?" Or,
> "in my opinion, Saddam Hussein has WMDs".

No, such as "take your head out of your ass and stop using your
emotions to guide technical arguments". You make the strangest
connections and then lay them out as if they're conclusive arguments.
Debating by confusing one's opponent only works at the lowest levels.

> > > > There are advantages and disadvantages to both, which is typical in
> > > > software design. Choose the one that best suits your needs, and you'll
> > > > end up with higher quality software. Being dogmatic about one or the
> > > > other limits your options.
>
> > > Why is it in corporations that the most vague admonitions are used to
> > > make irrevocable and costly decisions, whereas knowledge is equated
> > > with dogma?
>
> > Failure to apply the full extent of knowledge is equated with dogma.
> > I'd find it laughable if you weren't aware of the advantages of
> > copying data and the disadvantages of linking data. But your
> > statements clearly make it appear as if copying data has no advantages
> > and linking has no disadvantages. There are no vague admonitions. If
> > we were actually trying to make a decision, I'd be forcing you to
> > consider all of the alternatives I could think of so that the best
> > possible decision could be made.
>
> There is, in fact, no downside to a correctly implemented linked list
> of pointers, whereas there IS a considerable downside, which you don't
> seem to understand, to a correctly implemented link list of copied
> data. I've shown you, but shall repeat: Richard Heathfield's reusable
> tool will blow up, performance-wise, if passed large nodes

And your "better" design will blow up if linked to local data that
goes out of scope or memory that is released by unwitting client code.
I'm afraid that's a downside, despite your claim that none exist.

> creates a copy of data which has to be maintained in parallel with the
> original.

It's easy to make a library design look bad when you assume it's being
used by an idiot. The C++ container libraries take ownership of data
by copying, and nobody seems to have a problem with them. Further, by
copying pointers to the data rather than the data itself you get the
same effect as linking.

> > > > > > > Frankly, Julienne, I'm tired of the facility in which
> > > > > > > ordinary garden-variety transform "the need to think" into "wasting
> > > > > > > overhead" as if their brains == their computer.
>
> > > > > > I can't decide if you're insulting me or using my post to enable
> > > > > > attacks on your usual clc nemeses. Either way I think I'll simply
> > > > > > ignore it and focus on the topic at hand.
>
> > > > > Neither. What concerns me is that in nearly all offices, a language
> > > > > game is played that produces crumby software. Here, it's resistance to
> > > > > good solutions which are hard for some to think about based on false
> > > > > appeals to a misapprehension of "structured programming" and the false
> > > > > inference from "it is difficult for me to think about this" to "this
> > > > > must be an inefficient kludge".
>
> > > > May I direct you to the irony of this statement and your resistance to
>
> > > My dear Julienne, let us not simulate, even in dulcet tones, the
> > > corporate situation in which independence thought is reduced to a bad
> > > attitude, irrational resistance and behavior. Thank you.
>
> > Your attitude toward me has been hostile despite perfectly civil
>
> If disagreement is hostility, then who's hostile?

You're too intelligent not to realize how insulting and condescending
your posts are. Are you really trying to imply that you've managed to
insult my experience, my intelligence, my ethics, and my gender all
without knowing it? I actually find that impossible to believe. Once
again, I'm not stupid, and I'm not timid. I can see what you're doing
and I'm not afraid to point it out.

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

== 1 of 5 ==
Date: Thurs, Feb 18 2010 4:21 am
From: spinoza1111

On Feb 18, 7:47 pm, Walter Banks <wal...@bytecraft.com> wrote:
> spinoza1111wrote:
> > On Feb 18, 12:33 pm, Walter Banks <wal...@bytecraft.com> wrote:
> > > spinoza1111wrote:
> > > > On Feb 18, 6:08 am, Walter Banks <wal...@bytecraft.com> wrote:
>
> > > > > Software development practices have improved a lot as applications
> > > > > have become more complex and requirements better defined.
>
> > > > How can "defining requirements" improve "software development
> > > > practices"? "Defining requirements" is being able to express the
> > > > requirements in English, other human languages, visuals, and if
> > > > necessary mathematical formalisms: if you define them in code, you're
> > > > not, by definition, "defining requirements": you are coding.
>
> > > You just answered your own question.
>
> > But dear boy, you said that software improves if we define
> > requirements.
>
> Correct, you finally got it.
>
> > Please explain how this work, and note that industrial
> > experience is that the success of a software development project is
> > completely independent of requirements quality.
>
> Are you asking or telling?
>
> > Sometimes, beautiful
> > requirements produce beautiful code, sometimes, beautiful requirements
> > beautifully miss the point. Sometimes,
>
> But does the code do what is needed?
>
> > Extreme programming projects
> > start out with no requirements and beauty results.
>
> That makes no sense. No matter what comes out of a program with no
> requirements must be correct, novel approach to guaranteed success

No, the programmers themselves are human beings and able, in some
cases better than users, to express the requirements. The myth of
requirements started as a conspiracy between incompetent and
irresponsible programmers who wanted to be indemnified for their
ignorance and stupid mistakes, and users who wanted credit and
"control".
>
> You really need to work on comprehension.
>
> w..
>
> --- news://freenews.netfront.net/ - complaints: n...@netfront.net ---

== 2 of 5 ==
Date: Thurs, Feb 18 2010 5:58 am
From: Nick Keighley

On 18 Feb, 11:54, spinoza1111 <spinoza1...@yahoo.com> wrote:
> On Feb 18, 4:07 pm, Nick Keighley <nick_keighley_nos...@hotmail.com>
> > On 18 Feb, 06:02,spinoza1111<spinoza1...@yahoo.com> wrote:
> > > On Feb 18, 12:33 pm, Walter Banks <wal...@bytecraft.com> wrote:
> > > > spinoza1111wrote:
> > > > > On Feb 18, 6:08 am, Walter Banks <wal...@bytecraft.com> wrote:

> > > > > > Software development practices have improved a lot as applications
> > > > > > have become more complex and requirements better defined.
[...]
> > > > > How can "defining requirements" improve "software development
> > > > > practices"?
>
> > acquiring good requirements is part of good software development
> > practice.

<snip>

> > > Please explain how this work, and note that industrial
> > > experience is that the success of a software development project is
> > > completely independent of requirements quality.
>
> > really, could you expand on that. I was under the impression that many
> > projects had failed due to badly defined requirements.
>
> Requirements are by definition inadequate for if they were adequate,
> we could build a compiler to compile them.

comp.lang.lisp are discussing this at the moment. They have a slightly
different view in that they program in the Highest Level Possible
Langage (HLPL) hence if someone is going to write a specification in a
formal language they might as well just write it in Lisp, and then
execute it.

The point was raised that a requirement can be complete but not
specify a program.

- compute 1 million digits of pi
- decrypt an encypted message given only the public key

> The demand for
> "requirements definition" presupposes that the "analysts", thought to
> be of a higher social class, know by virtue of their social class more
> than the "mere" programmers.

no, I just think the guy who is going to use the thing ought to give
us vague idea of what he wants and what he expects to do with it. If
you want to call the people who extract this information "analysts",
so be it.

<snip>

> > > Sometimes, Extreme programming projects
> > > start out with no requirements and beauty results.
>
> > in a sense you're deriving the requirement by iterative refinement.
> > Have you read "Principles of Software Engineering Management" by Tom
> > Gilb. He was extreme programming before the (slightly silly) name was
> > invented.
>
> Yes, I've read Gilb...a member of the Scandinavian school of data
> processing theory, which took the needs of the workers into account.

and despite this, writes a rattling good book!

He's firmly of the belief that the requirements are never complete. In
part because the program changes its environment. The existence of the
program causes working practices to change and hence requirements to
alter. The solution is "evolutionary delivery". A series of deliveries
that asymptopically approach the (hopefully!) settling requirment.

== 3 of 5 ==
Date: Thurs, Feb 18 2010 6:08 am
From: Nick Keighley

On 18 Feb, 13:58, Nick Keighley <nick_keighley_nos...@hotmail.com>
wrote:
> On 18 Feb, 11:54, spinoza1111 <spinoza1...@yahoo.com> wrote:

<snip>

> > Requirements are by definition inadequate for if they were adequate,
> > we could build a compiler to compile them.
>
> comp.lang.lisp are discussing this at the moment. They have a slightly
> different view in that they program in the Highest Level Possible
> Langage (HLPL) hence if someone is going to write a specification in a
> formal language they might as well just write it in Lisp, and then
> execute it.

the thread is called "a defense of ad hoc software development"

***
The difference between specifications and programs is a
difference in degree, not a difference in kind. Once we realize this,
it seems strange to require that one write specifications for a
program before beginning to implement it. If the program has to be
written in a low-level language, then it would be reasonable to
require that it be described in high-level terms first. But as the
programming language becomes more abstract, the need for
specifications begins to evaporate. Or rather, the implementation and
the specifications can become the same thing.
If the high-level language is going to be re-implemented in a
lower-level language, it starts to look even more like
specifications.
[...] in other words, [...] the specifications for C programs could
be
written in Lisp.
***

<snip>

== 4 of 5 ==
Date: Thurs, Feb 18 2010 6:08 am
From: Walter Banks

spinoza1111 wrote:

> I don't know where you . . . get that claim you said I made:
> that I wish to destroy this newsgroup.

I have never said that.

Is that your wish?

w..

== 5 of 5 ==
Date: Thurs, Feb 18 2010 6:27 am
From: Walter Banks

spinoza1111 wrote:

> On Feb 18, 4:07 pm, Nick Keighley <nick_keighley_nos...@hotmail.com>
> wrote:
> > On 18 Feb, 06:02,spinoza1111<spinoza1...@yahoo.com> wrote:
> >
> > > On Feb 18, 12:33 pm, Walter Banks <wal...@bytecraft.com> wrote:
> > > > spinoza1111wrote:
> > > > > On Feb 18, 6:08 am, Walter Banks <wal...@bytecraft.com> wrote:
> > > > > > Software development practices have improved a lot as applications
> > > > > > have become more complex and requirements better defined.
> >
> > I'm not sure this is true !
> >
> > > > > How can "defining requirements" improve "software development
> > > > > practices"?
> >
> > acquiring good requirements is part of good software development
> > practice.
> >
> > > > > "Defining requirements" is being able to express the
> > > > > requirements in English, other human languages, visuals, and if
> > > > > necessary mathematical formalisms:
> >
> > yes. Though various graphical representaions are popular as well.
> >
> > > > > if you define them in code, you're
> > > > > not, by definition, "defining requirements": you are coding.
> >
> > well yes, but he didn't say define the requirements in code
> >
> > > > You just answered your own question.
> >
> > > But [...] you said that software improves if we define
> > > requirements.
> >
> > no he didn't he said "Software development practices [are] improved
> > [if] requirements [are] better defined." (the actual quote is at the
> > beginning of the post).
> >
> > > Please explain how this work, and note that industrial
> > > experience is that the success of a software development project is
> > > completely independent of requirements quality.
> >
> > really, could you expand on that. I was under the impression that many
> > projects had failed due to badly defined requirements.
>
> Requirements are by definition inadequate for if they were adequate,
> we could build a compiler to compile them.

Defining how an application is supposed to behave is very different
from an application design and implementation. Requirements provide
clear input into software design and application testing.

w..

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

== 1 of 1 ==
Date: Thurs, Feb 18 2010 4:26 am
From: Ben Bacarisse

"io_x" <a@b.c.invalid> writes:

> "Ben Bacarisse" <ben.usenet@bsb.me.uk> ha scritto nel messaggio
> news:0.e6be55c75fde5c5b1f8e.20100207132700GMT.87ljf5w50b.fsf@bsb.me.uk...
>> Willem <willem@stack.nl> writes:
>>
>>> santosh wrote:
>>> ) Anyway, I didn't follow the previous discussions in the thread
>>> ) closely, but for what it appears to do, your code appears to be an
>>> ) overkill. What about a solution involving strstr(), malloc()/realloc()
>>> ) and strcat()?
>>>
>>> I've never liked strcat(), and I'm not sure about the performance of
>>> realloc(), so this is roughly what I would do:
>> <snip code>
>>
>> Snap! Here is what I'd do. I think it is structurally the same:
>>
>> char *replace(const char *src, const char *match, const char *replacement)
>> {
>> size_t mlen = strlen(match), matches = 0;
>> for (const char *t, *s = src; t = strstr(s, match); s = t + mlen)
>> ++matches;
>> size_t rlen = strlen(replacement);
>> char *result = malloc(strlen(src) + matches*rlen - matches*mlen + 1);
>
> How are you so sure that
> strlen(src) + matches*rlen - matches*mlen + 1
> not overflow the unsigned type?

I'm not. In fact I know that there can't be any simple expression
that does not cause the result to be wrong because it can be wrong "by
logic" so to speak. If the input is "axxxx....xxx" of length SIZE_MAX
replacing the 'a' with "bb" will result in a string whose length is
not representable in a size_t.

You have a good point none the less. I should have written

strlen(src) - matches*mlen + matches*rlen + 1

because it will work for a wider range of inputs.

>> if (result) {
>> char *dst = result;
>> const char *s = src;
>> for (const char *t; t = strstr(s, match); s = t + mlen) {
>> memcpy(dst, s, t - s);
>> memcpy(dst += t - s, replacement, rlen);
>> dst += rlen;
>> }
>> strcpy(dst, s);
>> }
>> return result;
>> }
>
> this fail my test for
> src match replacement expected n. of test
> r*=tester( "" , "", "", "", 52);
> r*=tester( "x", "", "", "x", 54);
>
> going in one never ending loop

Yes. I opted to make the fact that match should not be empty part of
the contract with the caller, in the same way that the pointers can't
be null either. This may seem odd and it is certainly debatable, but
there is some logic to it. When using C, I am not a fan of functions
that use the narrow channel of the return value to tell the caller
things that they know (or could know very simply) such as a NULL
argument or an empty match. The caller must decide what to do when
the match string is null so making that part of the contract forces
the caller to either ensure that this situation does not happen or to
handle it as they see fit. Returning NULL (as some people have
chosen to do) seems to me to be unhelpful. The caller needs to check for
NULL anyway, but will now have to disambiguate between NULL due to no
memory and NULL due to some other logic error that they could have
tested for before the call rather than after getting a NULL return.

The only time that returning NULL is a clear win is when that
is exactly what the caller wants in the particular situation and I
think that is probably not true for this particular case.

I say "in C" because in a language with exceptions I'd be happy to
have the function signal different error conditions that way. The
exceptions simply provide another way to structure the code: the
caller can test for empty match strings /before/ the call of they can
handle the "null match" exception after.

--
Ben.

==============================================================================
TOPIC: A good opportunity to investment
http://groups.google.com/group/comp.lang.c/t/805e86b238c353d8?hl=en
==============================================================================

== 1 of 2 ==
Date: Thurs, Feb 18 2010 4:48 am
From: anitha raj

Social Networking has been effectively used in reaching the goal of
bringing down the prices of costly items through volume shopping. Go
shopping with http://www.shoppingreps.com?SourceId=1243
You can earn online, NO INVESTMENT, NO DEPOSIT, NO MLM and NO JOINING
FEES!!!!! http://www.shoppingreps.com?SourceId=1243 DON'T miss this
opportunity, join today for free, and earn more without paying single
rupees...NO SCAM ALL THE BEST

== 2 of 2 ==
Date: Thurs, Feb 18 2010 4:55 am
From: anitha raj

Social Networking has been effectively used in reaching the goal of
bringing down the prices of costly items through volume shopping. Go
shopping with http://www.shoppingreps.com?SourceId=1244
You can earn online, NO INVESTMENT, NO DEPOSIT, NO MLM and NO JOINING
FEES!!!!! http://www.shoppingreps.com?SourceId=1244 DON'T miss this
opportunity, join today for free, and earn more without paying single
rupees...NO SCAM ALL THE BEST

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

== 1 of 3 ==
Date: Thurs, Feb 18 2010 4:41 am
From: Ertugrul Söylemez

Willem <willem@snail.stack.nl> wrote:

> Suppose that program was one in a hundred programs that were written
> without regard for free()ing every resource. Then, afterward you had
> to go back and fix everything, which took ten times as long as it
> would have for the original programmers. For that one program. In
> total, it would have taken the original programmers ten times as long
> as it took now for all those programs combined.

Wrong. If freeing resources properly is part of your natural
programming behaviour, it takes little time in most cases. However, not
doing that causes a maintainance hell, in which such bugs need to be
found first, before they can be fixed. You find, fix, text, find, fix,
text, etc. until the program shows the correct behaviour. And even if
it does, there is no guarantee that you haven't overlooked something.

Clearly doing it properly in the first place is the better choice. Bug
fixing always takes much longer than writing correct code.

> And, of course, there may have been more pragmatic solutions
> available, such as the extra layer of memory management mentioned
> elsethread, or some kind of loop that fork()s, runs the process in the
> child fork, and wait()s in the parent fork for the child to finish
> before starting the next iteration.

That's neither pragmatic, nor a solution. Pragmatic would be
determining the scope of a resource and freeing it after that scope is
left. The solution is to find and fix the bugs. What you're proposing
here is just a workaround for bad program behaviour. Also it leads to
even worse maintainance hells, because now you need to manage processes
as an additional resource.

Greets
Ertugrul

--
nightmare = unsafePerformIO (getWrongWife >>= sex)
http://blog.ertes.de/

== 2 of 3 ==
Date: Thurs, Feb 18 2010 4:52 am
From: Ertugrul Söylemez

Ertugrul Söylemez <es@ertes.de> wrote:

> [...] You find, fix, text, find, fix, text, etc. [...]

'test', not 'text'.

Greets
Ertugrul

--
nightmare = unsafePerformIO (getWrongWife >>= sex)
http://blog.ertes.de/

== 3 of 3 ==
Date: Thurs, Feb 18 2010 6:43 am
From: cri@tiac.net (Richard Harter)

On Thu, 18 Feb 2010 00:32:22 -0800 (PST), Nick Keighley
<nick_keighley_nospam@hotmail.com> wrote:

>On 17 Feb, 18:46, Ertugrul S=F6ylemez <e...@ertes.de> wrote:
>
><snip>
>
>> What the hell is wrong with freeing resources? =A0It takes twenty seconds
>> to write the code to do it. =A0The code itself uses at most one or two
>> seconds to execute and guarantees correctness.
>
>it only "guarantees correctness" because you defined correctness as
>"freeing all resources at the end of a program".
>
>> We all know how well most commercial programs work. =A0If that is your
>> "enconomically relevant, balanced" portability, then commercial
>> application development is in a bad state.
>>
>> Serious programmers won't even argue about this topic. =A0
>
>so you, me, Seebs and Kaz aren't serious programmers?

From your mouth to the world's ears.

Richard Harter, cri@tiac.net
http://home.tiac.net/~cri, http://www.varinoma.com
Infinity is one of those things that keep philosophers busy when they
could be more profitably spending their time weeding their garden.

==============================================================================
TOPIC: Portable IEEE754 write routine
http://groups.google.com/group/comp.lang.c/t/126301772b46ce23?hl=en
==============================================================================

== 1 of 2 ==
Date: Thurs, Feb 18 2010 4:50 am
From: pacman@kosh.dhis.org (Alan Curry)

In article <21e31c8c-eb8b-47ea-8182-89ffb3ded132@j31g2000yqa.googlegroups.com>,
Malcolm McLean <malcolm.mclean5@btinternet.com> wrote:
|
|Thanks for running the test.
|It's losing a bit. If native format is not IEEE754 (but something very
|close) the loss of a bit or two is inevitable. However if the mantissa
|is exactly the same size, it would be nice to preserve the exact
|pattern.

PowerPC not IEEE754? News to me...

It's not just that bit though. It seems to be losing the entire lower 32
bits, replacing them with 7fffffff, whenever the high bit of those 32 bits is
1 in the input. Otherwise, the output exactly matches the input.

Here's a more complete list of values

Before After
0x1.00000feedfacep+1 0x1.000007fffffffp+1
0x1.0000f0eedfacep+1 0x1.0000f0eedfacep+1
0x1.0000000000000p+1 0x1.0000000000000p+1
0x1.0000000000001p+1 0x1.0000000000001p+1
0x1.0000000000010p+1 0x1.0000000000010p+1
0x1.0000000000100p+1 0x1.0000000000100p+1
0x1.0000000001000p+1 0x1.0000000001000p+1
0x1.0000000010000p+1 0x1.0000000010000p+1
0x1.0000000100000p+1 0x1.0000000100000p+1
0x1.0000001000000p+1 0x1.0000001000000p+1
0x1.0000002000000p+1 0x1.0000002000000p+1
0x1.0000004000000p+1 0x1.0000004000000p+1
0x1.0000008000000p+1 0x1.0000008000000p+1
0x1.0000010000000p+1 0x1.0000010000000p+1
0x1.000007fffffffp+1 0x1.000007fffffffp+1
0x1.0000080000000p+1 0x1.000007fffffffp+1
0x1.0000080000001p+1 0x1.000007fffffffp+1
0x1.0000080000010p+1 0x1.000007fffffffp+1
0x1.0000080000100p+1 0x1.000007fffffffp+1
0x1.0000080001000p+1 0x1.000007fffffffp+1
0x1.0000080010000p+1 0x1.000007fffffffp+1
0x1.0000080100000p+1 0x1.000007fffffffp+1
0x1.0000081000000p+1 0x1.000007fffffffp+1
0x1.0000082000000p+1 0x1.000007fffffffp+1
0x1.0000084000000p+1 0x1.000007fffffffp+1
0x1.0000088000000p+1 0x1.000007fffffffp+1
0x1.0000090000000p+1 0x1.000007fffffffp+1
0x1.00000ffffffffp+1 0x1.000007fffffffp+1

int main(void)
{
FILE *f;
double x;
double *p;
double testdoubles[] =
{
0x1.00000feedfacep+1, 0x1.0000f0eedfacep+1, 0x1.0000000000000p+1,
0x1.0000000000001p+1, 0x1.0000000000010p+1, 0x1.0000000000100p+1,
0x1.0000000001000p+1, 0x1.0000000010000p+1, 0x1.0000000100000p+1,
0x1.0000001000000p+1, 0x1.0000002000000p+1, 0x1.0000004000000p+1,
0x1.0000008000000p+1, 0x1.0000010000000p+1, 0x1.000007fffffffp+1,
0x1.0000080000000p+1, 0x1.0000080000001p+1, 0x1.0000080000010p+1,
0x1.0000080000100p+1, 0x1.0000080001000p+1, 0x1.0000080010000p+1,
0x1.0000080100000p+1, 0x1.0000081000000p+1, 0x1.0000082000000p+1,
0x1.0000084000000p+1, 0x1.0000088000000p+1, 0x1.0000090000000p+1,
0x1.00000ffffffffp+1, 0
};

printf("%-30s%-30s\n", "Before", "After");
for(p=testdoubles;*p;++p) {
x = *p;

printf("%-30.13a", x);

f=fopen("fnord", "w+");
if(!f)
return 1;
fwriteieee754(x, f, 1);
rewind(f);
if(!fread(&x, sizeof x, 1, f))
return 1;
remove("fnord");

printf("%-30.13a\n", x);
}

return 0;
}
--
Alan Curry

== 2 of 2 ==
Date: Thurs, Feb 18 2010 5:59 am
From: Malcolm McLean

On Feb 18, 2:50 pm, pac...@kosh.dhis.org (Alan Curry) wrote:
> In article <21e31c8c-eb8b-47ea-8182-89ffb3ded...@j31g2000yqa.googlegroups.com>,
> Malcolm McLean <malcolm.mcle...@btinternet.com> wrote:
> |
> |Thanks for running the test.
> |It's losing a bit. If native format is not IEEE754 (but something very
> |close) the loss of a bit or two is inevitable. However if the mantissa
> |is exactly the same size, it would be nice to preserve the exact
> |pattern.
>
> PowerPC not IEEE754? News to me...
>
> It's not just that bit though. It seems to be losing the entire lower 32
> bits, replacing them with 7fffffff, whenever the high bit of those 32 bits is
> 1 in the input. Otherwise, the output exactly matches the input.
>
> Here's a more complete list of values
>
> Before After
> 0x1.00000feedfacep+1 0x1.000007fffffffp+1
> 0x1.0000f0eedfacep+1 0x1.0000f0eedfacep+1
> 0x1.0000000000000p+1 0x1.0000000000000p+1
> 0x1.0000000000001p+1 0x1.0000000000001p+1
> 0x1.0000000000010p+1 0x1.0000000000010p+1
> 0x1.0000000000100p+1 0x1.0000000000100p+1
> 0x1.0000000001000p+1 0x1.0000000001000p+1
> 0x1.0000000010000p+1 0x1.0000000010000p+1
> 0x1.0000000100000p+1 0x1.0000000100000p+1
> 0x1.0000001000000p+1 0x1.0000001000000p+1
> 0x1.0000002000000p+1 0x1.0000002000000p+1
> 0x1.0000004000000p+1 0x1.0000004000000p+1
> 0x1.0000008000000p+1 0x1.0000008000000p+1
> 0x1.0000010000000p+1 0x1.0000010000000p+1
> 0x1.000007fffffffp+1 0x1.000007fffffffp+1
> 0x1.0000080000000p+1 0x1.000007fffffffp+1
> 0x1.0000080000001p+1 0x1.000007fffffffp+1
> 0x1.0000080000010p+1 0x1.000007fffffffp+1
> 0x1.0000080000100p+1 0x1.000007fffffffp+1
> 0x1.0000080001000p+1 0x1.000007fffffffp+1
> 0x1.0000080010000p+1 0x1.000007fffffffp+1
> 0x1.0000080100000p+1 0x1.000007fffffffp+1
> 0x1.0000081000000p+1 0x1.000007fffffffp+1
> 0x1.0000082000000p+1 0x1.000007fffffffp+1
> 0x1.0000084000000p+1 0x1.000007fffffffp+1
> 0x1.0000088000000p+1 0x1.000007fffffffp+1
> 0x1.0000090000000p+1 0x1.000007fffffffp+1
> 0x1.00000ffffffffp+1 0x1.000007fffffffp+1
>
> int main(void)
> {
> FILE *f;
> double x;
> double *p;
> double testdoubles[] =
> {
> 0x1.00000feedfacep+1, 0x1.0000f0eedfacep+1, 0x1.0000000000000p+1,
> 0x1.0000000000001p+1, 0x1.0000000000010p+1, 0x1.0000000000100p+1,
> 0x1.0000000001000p+1, 0x1.0000000010000p+1, 0x1.0000000100000p+1,
> 0x1.0000001000000p+1, 0x1.0000002000000p+1, 0x1.0000004000000p+1,
> 0x1.0000008000000p+1, 0x1.0000010000000p+1, 0x1.000007fffffffp+1,
> 0x1.0000080000000p+1, 0x1.0000080000001p+1, 0x1.0000080000010p+1,
> 0x1.0000080000100p+1, 0x1.0000080001000p+1, 0x1.0000080010000p+1,
> 0x1.0000080100000p+1, 0x1.0000081000000p+1, 0x1.0000082000000p+1,
> 0x1.0000084000000p+1, 0x1.0000088000000p+1, 0x1.0000090000000p+1,
> 0x1.00000ffffffffp+1, 0
> };
>
> printf("%-30s%-30s\n", "Before", "After");
> for(p=testdoubles;*p;++p) {
> x = *p;
>
> printf("%-30.13a", x);
>
> f=fopen("fnord", "w+");
> if(!f)
> return 1;
> fwriteieee754(x, f, 1);
> rewind(f);
> if(!fread(&x, sizeof x, 1, f))
> return 1;
> remove("fnord");
>
> printf("%-30.13a\n", x);
> }
>
> return 0;}
>
> --
> Alan Curry

This
lowlong = (long) (significand - hibits * 4294967296);
should be
lowlong = (unsigned long) (significand hibits * 4294967296).

Well tested.

==============================================================================
TOPIC: using precedence and associativity to parse an expression
http://groups.google.com/group/comp.lang.c/t/e7c80acb4c62dbd9?hl=en
==============================================================================

== 1 of 3 ==
Date: Thurs, Feb 18 2010 4:58 am
From: spinoza1111

On Feb 15, 9:09 pm, "junky_fel...@yahoo.co.in"
<junky_fel...@yahoo.co.in> wrote:
> Hi,
>
> As I read in previous threads in this newsgroup, that there is no
> precedence and associativity in C. Still, precedence and associativity

Nice job, Seebach, nice job:
Destroy knowledge rather than create it:
Your conduct has created fear, uncertainty, and doubt:
That was your goal, destruction: it was to destroy you set out.

> rules may be used to parse an expression.
> Applying precedence/associativity is easier rather than applying
> grammar rules.
>
> My question is, if all expressions that can be parsed using ANSI C
> grammar, can also be parsed using precedence and associativity
> rules ?
> Is there anything that cannot be parsed or will give different result
> when parsed using precedence/associativity as compared to ANSI C
> grammar.
>
> thanks,
> rahul

== 2 of 3 ==
Date: Thurs, Feb 18 2010 5:01 am
From: spinoza1111

On Feb 15, 10:37 pm, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
> "junky_fel...@yahoo.co.in" <junky_fel...@yahoo.co.in> writes:
> > As I read in previous threads in this newsgroup, that there is no
> > precedence and associativity in C. Still, precedence and associativity
> > rules may be used to parse an expression.
> > Applying precedence/associativity is easier rather than applying
> > grammar rules.
>
> First off, we have to dismiss a problem. C's grammar (as printed)
> does not describe C's syntax (as parsed by compilers) because of the
> ability to define a type alias. Let's just put such annoyances to one
> side for the moment.

...and make things even more unclear to newbies in order to maintain
"expertise". Ben, it's sad to see a great programmer like you
corrupted. You've made a statement on an area (compiler development)
in which you have no standing and which is false.
>
> > My question is, if all expressions that can be parsed using ANSI C
> > grammar, can also be parsed using precedence and associativity
> > rules ?
>
> This is probably not the question you wanted to ask! Precedence and
> associativity rules can be very general. Some (formal) systems allow
> different left and right precedence and these are (probably) enough to
> describe C's expression syntax.
>
> A slightly different question is whether a given set of rules describe
> C's expression accurately and that, of course, depends on the rules.
>
> > Is there anything that cannot be parsed or will give different result
> > when parsed using precedence/associativity as compared to ANSI C
> > grammar.
>
> The usual listing of operators, grouped by precedence, with an
> annotation describing the associativity[1] are not quite up to the job
> but come so close that it rarely matters. Neither the ternary
> operator (?:) nor the subscript operator ([]) can be fully described
> in this way because they both permit a full expression as a sub-part
> of the operator (inside the []s or between the ? and the :). It is
> simple enough to describe these exceptions with, say, a footnote.
>
> But even the plain unary operators are problematic. Most tables put
> all prefix unary operators in the same precedence group, all with
> right-to-left associativity. That means that:
>
> op1 op2 op3 identifier
>
> means
>
> (op1 (op2 (op3 identifier)))
>
> for all prefix unary operator opN. lets pick three: sizeof, !
> (negation) and (char) (convert to char type). The tables therefore
> suggest that
>
> sizeof (char) ! x
>
> parses in the same way as
>
> sizeof ! (char) x
>
> but it does not. In fact the first is a syntax error. I don't think
> (but I am not sure) that any simple table can capture the syntax of
> these sorts of expressions.
>
> [1] For example:http://www.difranco.net/cop2220/op-prec.htm
> --
> Ben.

== 3 of 3 ==
Date: Thurs, Feb 18 2010 5:09 am
From: Nick Keighley

On 18 Feb, 13:01, spinoza1111 <spinoza1...@yahoo.com> wrote:
> On Feb 15, 10:37 pm, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
> > "junky_fel...@yahoo.co.in" <junky_fel...@yahoo.co.in> writes:

> > > As I read in previous threads in this newsgroup, that there is no
> > > precedence and associativity in C. Still, precedence and associativity
> > > rules may be used to parse an expression.
> > > Applying precedence/associativity is easier rather than applying
> > > grammar rules.
>
> > First off, we have to dismiss a problem. C's grammar (as printed)
> > does not describe C's syntax (as parsed by compilers) because of the
> > ability to define a type alias. Let's just put such annoyances to one
> > side for the moment.
>
> ...and make things even more unclear to newbies in order to maintain
> "expertise".

I don't consider pointing out a potential problem to be making things
unclear.

> Ben, it's sad to see a great programmer like you
> corrupted. You've made a statement on an area (compiler development)
> in which you have no standing and which is false.

I suspect he knows a lot more about the subject than you (yes, I know
you wrote a book). If you consider he has said something that is
untrue it would make things much cleaer if you explained which bit
what he had said was incorrect.

<snip>

==============================================================================
TOPIC: NOW Watch Hot Sexy Star Aishwarya rai <NUDE> Bathing Videos In All
Angles.
http://groups.google.com/group/comp.lang.c/t/773234689d712fe8?hl=en
==============================================================================

== 1 of 1 ==
Date: Thurs, Feb 18 2010 5:32 am
From: "ranga..............."

NOW Watch Hot Sexy Star Aishwarya rai <NUDE> Bathing Videos In All
Angles at

http://blogcreationandhosting.blogspot.com/2009/11/play-with-internet.html

< Due to high sex content,I have hidden these videos inside an Image.
In that website,click on big vertical shining image on the right side
of website & watch the videos >

==============================================================================
TOPIC: decoding a declaration
http://groups.google.com/group/comp.lang.c/t/259df4a3d0342511?hl=en
==============================================================================

== 1 of 3 ==
Date: Thurs, Feb 18 2010 6:17 am
From: t@t.com

Thanks to all who responded with suggestions
about books, coding style, how to recognize it,
using cdecl and keeping a good attitude.

Thanks again.

P.S. Don't understand why my reply did not show up earlier
though i was told by my newsreader that it posted properly.

== 2 of 3 ==
Date: Thurs, Feb 18 2010 6:17 am
From: t@t.com

Thanks to all who responded with suggestions
about a book, cdecl, coding style, typedef and high spirit attitude.

I will read the suggested books and use cdecl.

Thanks again.

== 3 of 3 ==
Date: Thurs, Feb 18 2010 6:17 am
From: t@t.com

On 17-Feb-2010, Keith Thompson <kst-u@mib.org> wrote:

> You posted the same followup 5 times. Please investigate what caused
> that to happen.

My apologies. I did not want to post 5 times. I am using Newsrover as the
newsreader software. When it did
not give me the message posting successfully and told me authentication
failed. I restarted Newsrover and tried to
do it again. After the same issue occurred, I gave up thinking i should try
tomorrow. This is what led to these five posts.
Sorry for that.

==============================================================================
TOPIC: NOW Watch Hot Sexy Star Aishwarya rai Bathing Videos In All Angles.
http://groups.google.com/group/comp.lang.c/t/d8f01f14e0fbf732?hl=en
==============================================================================

== 1 of 1 ==
Date: Thurs, Feb 18 2010 6:27 am
From: jaagar

NOW Watch Hot Sexy Star Aishwarya rai Bathing Videos In All Angles at

http://blogcreationandhosting.blogspot.com/2009/11/1-per-click-in-adsense-programs.html

< Due to high sex content,I have hidden these videos inside an Image.
In that website,click on big vertical shining image on the right side
of website & watch the videos >

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

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, February 18, 2010

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

0 Comments:

Post a Comment

About Me

Previous Posts