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

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

comp.lang.c@googlegroups.com

Today's topics:

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

== 1 of 13 ==
Date: Sat, Feb 13 2010 10:32 am
From: Leif Roar Moldskred

In comp.lang.java.programmer Seebs <usenet-nospam@seebs.net> wrote:
>
> Agreed.
>
> But it's crucial infrastructure, and any policy discouraging it would deal
> immense damage to fundamental infrastructure.
>
> People *MUST* be free to give code away without any kind of liability.

Why? We're not today, and the gears of the open source engine appears fairly
well greased regardless.

--
Leif Roar Moldskred

== 2 of 13 ==
Date: Sat, Feb 13 2010 10:34 am
From: Seebs

On 2010-02-13, Leif Roar Moldskred <leifm@huldreheim.homelinux.org> wrote:
> Why? We're not today, and the gears of the open source engine appears fairly
> well greased regardless.

In practice we are -- you can give stuff away labeled "WITHOUT ANY WARRANTY"
and no one seems to feel this is a problem.

The proposal that we should legislate that software CANNOT be distributed
without warranty would be destructive.

-s
--
Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

== 3 of 13 ==
Date: Sat, Feb 13 2010 11:43 am
From: Keith Thompson

Seebs <usenet-nospam@seebs.net> writes:
[...]
> They might be hard to apply, but consider that a great deal of free
> software is written without idiots saying "you need to get this done sooner
> so we can book revenue this quarter to please shareholders". It's also
> often written by particularly good developers, who care about their code.
[...]

I'm not convinced that the majority of free software is of
particularly high quality. But I think that most free software
that's sufficiently popular that you or I have heard of it does
tend to be of high quality. There are (at least) two effects here:
good free software tends to become popular, and useful free software
attracts good developers. The latter effect is less pronounced
in non-free software; however much I might like some proprietary
software package, I'm not likely to switch jobs so I can work on it.

But if you looked at the universe of free software, I'd be surprised
if Sturgeon's Law didn't apply (90% of everything is crud).

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

== 4 of 13 ==
Date: Sat, Feb 13 2010 12:04 pm
From: Seebs

On 2010-02-13, Keith Thompson <kst-u@mib.org> wrote:
> I'm not convinced that the majority of free software is of
> particularly high quality. But I think that most free software
> that's sufficiently popular that you or I have heard of it does
> tend to be of high quality. There are (at least) two effects here:
> good free software tends to become popular, and useful free software
> attracts good developers. The latter effect is less pronounced
> in non-free software; however much I might like some proprietary
> software package, I'm not likely to switch jobs so I can work on it.
>
> But if you looked at the universe of free software, I'd be surprised
> if Sturgeon's Law didn't apply (90% of everything is crud).

Sure.

But there's one other huge amplifying effect:

You can read the source so you *know* whether or not it's any good. That
helps a lot. The bad stuff tends to never go anywhere (see our spammer
from last fall with his Unix daemon utility), while the good stuff tends to
do quite well indeed (e.g., Rails).

== 5 of 13 ==
Date: Sat, Feb 13 2010 12:44 pm
From: Lew

Arved Sandstrom wrote:
> Let's take it as a given that free software has a decent model. I've
> been, and still am, a participant in the process of creating free
> software, and I wouldn't do that if it wasn't a good model. However, the
> main problem with it is that it engages only a small fraction of all
> software developers, and accounts for only a very small fraction of all
> software that is written.

Only a small fraction of software developers (and I've known for a long time
you were in that group) are good enough to write good software, free or otherwise.

Most of us do need to get paid, and few of us can make more money than as
software developers or related jobs. That gives those who are good developers
little time to spare for writing free software.

> But the real problem, which is not addressed by free software, and which
> comprises the huge majority of all software, is custom stuff. And it is
> this category that suffers, and suffers badly, from the lack of
> professionalism in our field. It is this category where clients would
> benefit from having proven, guaranteed quantities when it comes to
> employees/contractors and products.

There should be a much wider gap between the pay scale of the good developer
and that of the putz or newbie. Something akin to the gap between top actors
and those who have to wait tables, or top pro athletes and those in the minor
leagues.

--
Lew

== 6 of 13 ==
Date: Sat, Feb 13 2010 1:02 pm
From: Brian

On Feb 13, 2:04 pm, Seebs <usenet-nos...@seebs.net> wrote:
> On 2010-02-13, Keith Thompson <ks...@mib.org> wrote:
>
> > I'm not convinced that the majority of free software is of
> > particularly high quality. But I think that most free software
> > that's sufficiently popular that you or I have heard of it does
> > tend to be of high quality. There are (at least) two effects here:
> > good free software tends to become popular, and useful free software
> > attracts good developers. The latter effect is less pronounced
> > in non-free software; however much I might like some proprietary
> > software package, I'm not likely to switch jobs so I can work on it.
>
> > But if you looked at the universe of free software, I'd be surprised
> > if Sturgeon's Law didn't apply (90% of everything is crud).
>
> Sure.
>
> But there's one other huge amplifying effect:
>
> You can read the source so you *know* whether or not it's any good. That
> helps a lot.

I think its helpful to be able to read code generated
by a compiler. I'm not talking about assembly
although that is helpful, but higher-level code.
In C++ due to a number of language features it's
easy to misunderstand what you are reading. If you
are having a problem and need to research the cause,
reading the later output can help detect the problem.

In my case, I have both open source code --
http://webEbenezer.net/build_integration.html --
and closed source code. The output from the closed
source code is also open source.

Brian Wood
http://webEbenezer.net
(651) 251-9384

== 7 of 13 ==
Date: Sat, Feb 13 2010 1:03 pm
From: Arved Sandstrom

Jerry Coffin wrote:
> In article <hku5go$af0$1@news.eternal-september.org>,
> John.koy@example.com says...
>
> [ ... ]
>
>> Exactly. Engineering is about measurable outcomes, quantification.
>> What's the equivalent of "this building can withstand a quake of
>> magnitude 7.5 for 30 seconds" in software? Can any of us state "this
>> software will stand all virus attacks for 12 months" or "this software
>> will not crash for 2 years, and if it does your loss won't exceed 20% of
>> all digital assets managed by it" ?
>
> Your analogy is fatally flawed, in quite a number of ways.
>
> First of all, a particular piece of software is only one component in
> a much larger system of both hardware and software -- where the final
> system is generally designed and assembled by a somebody who's not an
> engineer at all. What you're asking for isn't like a warranty on a
> building. It's more like asking a vendor of steel beams to warrant
> that any possible building of any design will withstand earthquake X
> as long as it includes this particular component.
[ SNIP ]

And to continue the analogy, what would be reasonable to ask for is that
the steel beam vendor warrant his steel beams provided that they are
properly used according to his specifications. We can actually do that
for software components as well.

AHS

== 8 of 13 ==
Date: Sat, Feb 13 2010 1:09 pm
From: Arved Sandstrom

Seebs wrote:
> On 2010-02-13, Keith Thompson <kst-u@mib.org> wrote:
>> I'm not convinced that the majority of free software is of
>> particularly high quality. But I think that most free software
>> that's sufficiently popular that you or I have heard of it does
>> tend to be of high quality. There are (at least) two effects here:
>> good free software tends to become popular, and useful free software
>> attracts good developers. The latter effect is less pronounced
>> in non-free software; however much I might like some proprietary
>> software package, I'm not likely to switch jobs so I can work on it.
>>
>> But if you looked at the universe of free software, I'd be surprised
>> if Sturgeon's Law didn't apply (90% of everything is crud).
>
> Sure.
>
> But there's one other huge amplifying effect:
>
> You can read the source so you *know* whether or not it's any good. That
> helps a lot. The bad stuff tends to never go anywhere (see our spammer
> from last fall with his Unix daemon utility), while the good stuff tends to
> do quite well indeed (e.g., Rails).
>
> -s

*In theory* you can read the source. However, not many professional
developers actually have the time to assess open source code quality by
doing code inspections. I myself tend to go with reviews, previous
experience of software by the same people, experience of older versions
of the same program, and the provided documentation.

And I've used a number of programs for which the source was available
where problems caused us to dive into the code. The code passed visual
inspection, no problem...but it still had defects.

AHS

== 9 of 13 ==
Date: Sat, Feb 13 2010 1:13 pm
From: "osmium"

"Leif Roar Moldskred" wrote:

> In comp.lang.java.programmer Seebs <usenet-nospam@seebs.net> wrote:
>>
>> Agreed.
>>
>> But it's crucial infrastructure, and any policy discouraging it would
>> deal
>> immense damage to fundamental infrastructure.
>>
>> People *MUST* be free to give code away without any kind of liability.
>
> Why? We're not today, and the gears of the open source engine appears
> fairly
> well greased regardless.

Your post implies someone can be harmed by giving away software. What
country can that happen in and where can we find out more about it? Has
someone *actually* been harmed?

== 10 of 13 ==
Date: Sat, Feb 13 2010 1:17 pm
From: Richard Heathfield

osmium wrote:

<snip>

> Your post implies someone can be harmed by giving away software. What
> country can that happen in and where can we find out more about it? Has
> someone *actually* been harmed?

Phil Zimmermann came pretty close. :-)

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

== 11 of 13 ==
Date: Sat, Feb 13 2010 1:22 pm
From: "Mike Schilling"

Lew wrote:
> There should be a much wider gap between the pay scale of the good
> developer and that of the putz or newbie.
----

I do not think that words means what you think it means.

== 12 of 13 ==
Date: Sat, Feb 13 2010 1:18 pm
From: Seebs

On 2010-02-13, Arved Sandstrom <dcest61@hotmail.com> wrote:
> *In theory* you can read the source. However, not many professional
> developers actually have the time to assess open source code quality by
> doing code inspections. I myself tend to go with reviews, previous
> experience of software by the same people, experience of older versions
> of the same program, and the provided documentation.

I do too, but the moment I have to look at something, I can start evaluating
it. I pitched a several-week project to management on the basis that I'd
read the code of a component we were using, and concluded from quality
issues where the code worked but wasn't pretty that it would not be worth it
to try to fix the cases where it didn't work.

> And I've used a number of programs for which the source was available
> where problems caused us to dive into the code. The code passed visual
> inspection, no problem...but it still had defects.

Oh, sure. Nearly all code still has defects. The questions that are more
interesting are how easy it will be to work on the code, or how likely it
will be that fixing one defect will reveal others.

== 13 of 13 ==
Date: Sat, Feb 13 2010 1:24 pm
From: "osmium"

"Richard Heathfield" wrote:

> osmium wrote:
>
> <snip>
>
>> Your post implies someone can be harmed by giving away software. What
>> country can that happen in and where can we find out more about it? Has
>> someone *actually* been harmed?
>
> Phil Zimmermann came pretty close. :-)

Very good point, but that is not the kind of harm I had in mind. In the
good old USA, too.

Not *your* old, *our* old.

==============================================================================
TOPIC: Suggestion: allow multiple updaters of the C FAQ
http://groups.google.com/group/comp.lang.c/t/41aaefd157191f19?hl=en
==============================================================================

== 1 of 1 ==
Date: Sat, Feb 13 2010 10:35 am
From: Andrew Poelstra

On 2010-02-13, James Harris <james.harris.1@googlemail.com> wrote:
> Given the recent discussions over the C FAQ has it been discussed
> whether it's worth storing it in a form that multiple people can
> update it? Could you open it to public updates? I guess not but maybe
> a few updaters could be chosen by consensus.
>

There is a wiki at:
http://clc-wiki.net/wiki/Main_Page

But nobody really used it. :(

> Options:
>
> - a wiki (public updates or updates only to known userids)
> - a Google site (not tried but AIUI can be limited to userids)
> - anything similar
>
> As an example the FAQ for another Usenet group, alt.os.development,
> was placed on a wiki. You can see it at the first of the following
> links.
>
> http://aodfaq.wikispaces.com/
> http://codewiki.wikispaces.com/faq
>
> The second link (from a different wiki but with the same provider)
> deals with some of the potential concerns of the wiki mechanism:
> security, protection against vandalism, backups, notification of
> updates and requiring one or more people to have overall control such
> as the current editor, Steve(?).
>
> Wikispaces is the only one I've tried that I can recommend but there
> are other options. I mention it principally because it addresses some
> of the concerns I expect people may have.
>
> Lessons learned from aodfaq.wikispaces.com? At some point we'll
> probably split it to smaller sections rather than use a single page.
> Othter than that it has been a good solution. Periodic reminders are
> posted to the newsgroup but all they do is point to the wiki.
>
> What about the C FAQ? Could anything similar bring benefits?
>
> James

==============================================================================
TOPIC: portable floating-point read/write
http://groups.google.com/group/comp.lang.c/t/7c848009bd0fc355?hl=en
==============================================================================

== 1 of 1 ==
Date: Sat, Feb 13 2010 11:46 am
From: Barry Schwarz

On Sat, 13 Feb 2010 04:12:40 +0000 (UTC), pacman@kosh.dhis.org (Alan
Curry) wrote:

>In article <d546a4c7-30f6-4fd0-9713-28678a6f6e39@d27g2000yqf.googlegroups.com>,
>Malcolm McLean <malcolm.mclean5@btinternet.com> wrote:
>|Anyone got a routine to portably read/write 64 bit IEEE numbers in
>|litle-endian format?
>|
>|(I mean so that it is compatible with fwrite(&x, sizeof(double), 1,
>|fp) ona Windows PC, and won't break should the program be run on a
>|machine with a diferent internal floating-point unit).
>
>It occurs to me that cross-compilers (or cross-assemblers) have to
>solve this problem, if they're going to be able to embed static float
>initializers in an object file.

Yes. But they already know the machine they run on and the target
machine the code will run on. "Portable" in this case is not open
ended.

My system doesn't normally use it so I don't keep up with IEEE
floating point but aren't there two different IEEE standards and
wouldn't the answer be different depending on which one the OP had in
mind?

Is there any way for fwrite to produce a 64 bit IEEE floating point
object that would be compatible with, for example, the Decimal
Floating Point format used by IBM z-Architecture mainframes? Or the
Hexadecimal Floating Point format used since the 1960s by the System
360 family and its descendents? Does the question even make sense?

--
Remove del for email

==============================================================================
TOPIC: HOW this program is executing plz explain the program
http://groups.google.com/group/comp.lang.c/t/3fb552296fac02d8?hl=en
==============================================================================

== 1 of 3 ==
Date: Sat, Feb 13 2010 11:46 am
From: Barry Schwarz

On Sat, 13 Feb 2010 01:39:48 -0800 (PST), manish sahu
<manish.comp05@gmail.com> wrote:

>#include<stdio.h>
>#include<conio.h>
>
>main()
>{
> int i,j;
>
> clrscr();
> scanf("%d%d"+scanf("%d%d",&i,&j));
> printf("%d %d",i,j);
> getch();
> return 0;
>}

Please put your question in the body of your post, even if it just
duplicates your subject.

The program works only if you are very careful with your inputs. In
other cases, it invokes undefined behavior which, among other things,
means there is no explanation.

The inner call to scanf accepts at most two integers. If you do not
enter two integers, at least one of the two integers printed has an
indeterminate value and evaluating it causes undefined behavior.

If you do enter two integers, they must be of the form
int_1 int_2 ??? <ENTER>
where the quantity and choice of white space characters are irrelevant
as long as there is one between the two integers and one after the
second integer. The ??? represent additional optional data which will
not be processed by this call to scanf. The use of the enter key
assumes you are using a keyboard but your system may have other
methods of determining that the input is complete.

scanf will stop processing the input at the first character that is
not part of int_2 and this character will be made available to the
next attempt to read from stdin. At this point, both i and j have
been set and scanf will return 2, indicating that two values were
successfully converted.

The argument of the outer call to scanf is a pointer value formed by
the pointer arithmetic expression. The left operand of the addition
operator is the address of the string literal which is stored in your
program as an unnamed static array of char. The array consists of the
five characters '%', 'd', '%', 'd', and '\0'. The address of this
array is the address of the first '%'. The right operand is the int
returned by scanf, which we are assuming is 2. The result of this
addition is the address of the second '%'. Therefore, the effective
argument passed to scanf is "%d".

Thus, the outer call to scanf will accept at most one integer. One of
the features of the %d conversion specifier is that it will skip over
white space looking for the start of the integer. Assuming you did
not enter any ??? data, it will skip over all the white space
following int_2, including the '\n' generated by the enter key. It
will then wait for you to enter more data. Presumably, you hit enter
again. But this is just more white space to ignore. At this point,
you must force end of file or enter a non-numeric character followed
by the enter key. Either of these actions will cause the conversion
to fail and scanf to return. You should have no trouble with the
remaining code.

If you enter any numeric data when scanf is waiting, or if you entered
a characters sequence starting with a number after int_2, then this
outer call to scanf will attempt to convert that data into an int
value and store it somewhere. That somewhere would be specified by
the next argument to scanf but there is no other argument. This also
results in undefined behavior.

In summary, the program may have worked but if it did so it is only
because you cleverly, or luckily, avoided all the pitfalls.

It is also possible that the program did not work properly but only
appeared to. Improper input during either call to scanf results in
undefined behavior. One of the more undesirable manifestations of
undefined behavior is to appear to do what is expected, this time.

--
Remove del for email

== 2 of 3 ==
Date: Sat, Feb 13 2010 12:11 pm
From: ram@zedat.fu-berlin.de (Stefan Ram)

manish sahu <manish.comp05@gmail.com> writes:
>clrscr();
>scanf("%d%d"+scanf("%d%d",&i,&j));

This does something implementation-specified
and then something undefined.

== 3 of 3 ==
Date: Sat, Feb 13 2010 1:07 pm
From: Keith Thompson

Barry Schwarz <schwarzb@dqel.com> writes:
> On Sat, 13 Feb 2010 01:39:48 -0800 (PST), manish sahu
> <manish.comp05@gmail.com> wrote:
>
>>#include<stdio.h>
>>#include<conio.h>
>>
>>main()
>>{
>> int i,j;
>>
>> clrscr();
>> scanf("%d%d"+scanf("%d%d",&i,&j));
>> printf("%d %d",i,j);
>> getch();
>> return 0;
>>}
>
> Please put your question in the body of your post, even if it just
> duplicates your subject.
>
> The program works only if you are very careful with your inputs. In
> other cases, it invokes undefined behavior which, among other things,
> means there is no explanation.

The program's behavior is undefined no matter how careful you are
with your inputs.

[...]

> Thus, the outer call to scanf will accept at most one integer. One of
> the features of the %d conversion specifier is that it will skip over
> white space looking for the start of the integer. Assuming you did
> not enter any ??? data, it will skip over all the white space
> following int_2, including the '\n' generated by the enter key. It
> will then wait for you to enter more data. Presumably, you hit enter
> again. But this is just more white space to ignore. At this point,
> you must force end of file or enter a non-numeric character followed
> by the enter key. Either of these actions will cause the conversion
> to fail and scanf to return. You should have no trouble with the
> remaining code.

C99 7.19.6.2p2 (describing fscanf, but the same applies to scanf):

If there are insufficient arguments for the format, the behavior
is undefined. If the format is exhausted while arguments remain,
the excess arguments are evaluated (as always) but are otherwise
ignored.

Note that the behavior is undefined if there are insufficient
arguments *for the format*, whether any attempt is made to store
values or not.

In practice, this is likely to be harmless, but an implementation
could attempt to access all the objects into which values might be
stored, perhaps for the purpose of detecting this kind of problem
before consuming any input.

==============================================================================
TOPIC: Stats for comp.lang.c (last 7 days)
http://groups.google.com/group/comp.lang.c/t/a0f85cef46aadf3b?hl=en
==============================================================================

== 1 of 1 ==
Date: Sat, Feb 13 2010 12:07 pm
From: CLC stats

============================================================================
Analysis of posts to comp.lang.c
============================================================================
(stats compiled with a script by Garry Knight)

Total posts considered: 1,017 over 7 days
Earliest article: Sat Feb 6 20:08:11 2010
Latest article: Sat Feb 13 20:04:04 2010
Original articles: 36, replies: 981
Total size of posts: 3,240,703 bytes (3,164K) (3.09M)
Average 145 articles per day, 0.44 MB per day, 3,186 bytes per article
Total headers: 1,348 KB bodies: 1,816 KB
Body text - quoted: 790 KB, original: 770 KB = 49.37%, sigs: 248 KB
Total number of posters: 145, average 22,349 bytes per poster
Total number of threads: 66, average 49,101 bytes per thread
Total number of User-Agents: 34

============================================================================
Top 20 posters by number of articles
============================================================================
1: Seebs <usenet-nospam@seebs.net>................................ : 107
2: spinoza1111 <spinoza1111@yahoo.com>............................ : 97
3: Richard Heathfield <rjh@see.sig.invalid>....................... : 49
4: Nick Keighley <nick_keighley_nospam@hotmail.com>............... : 34
5: Ben Bacarisse <ben.usenet@bsb.me.uk>........................... : 33
6: santosh <santosh.k83@gmail.com>................................ : 32
7: Keith Thompson <kst-u@mib.org>................................. : 29
8: James Kanze <james.kanze@gmail.com>............................ : 21
9: Andrew Poelstra <apoelstra@localhost.localdomain>.............. : 19
10: Arved Sandstrom <dcest61@hotmail.com>.......................... : 18
11: Michael Foukarakis <electricdelta@gmail.com>................... : 17
12: Francois Grieu <fgrieu@gmail.com>.............................. : 17
13: jacob navia <jacob@nospam.org>................................. : 16
14: Eric Sosman <esosman@ieee-dot-org.invalid>..................... : 16
15: Phred Phungus <Phred@example.invalid>.......................... : 15
16: Phil Carmody <thefatphil_demunged@yahoo.co.uk>................. : 15
17: Tor Rustad <bwzcab@wvtqvm.vw>.................................. : 15
18: "io_x" <a@b.c.invalid>......................................... : 14
19: Nobody <nobody@nowhere.com>.................................... : 13
20: lacos@ludens.elte.hu (Ersek, Laszlo)........................... : 13

============================================================================
Top 20 posters by avg. article size in bytes
(at least 5 posts)
============================================================================
1: spinoza1111 <spinoza1111@yahoo.com>............................ : 6316
2: "io_x" <a@b.c.invalid>......................................... : 5219
3: happytoday <ehabaziz2001@gmail.com>............................ : 4821
4: James Kuyper <jameskuyper@verizon.net>......................... : 3964
5: Arved Sandstrom <dcest61@hotmail.com>.......................... : 3922
6: "James" <no@spam.invalid>...................................... : 3746
7: blmblm@myrealbox.com <blmblm@myrealbox.com>.................... : 3731
8: Brian <coal@mailvault.com>..................................... : 3670
9: santosh <santosh.k83@gmail.com>................................ : 3495
10: Willem <willem@stack.nl>....................................... : 3460
11: William Ahern <william@wilbur.25thandClement.com>.............. : 3425
12: Lew <noone@lewscanon.com>...................................... : 3396
13: James Kanze <james.kanze@gmail.com>............................ : 3363
14: Phred Phungus <Phred@example.invalid>.......................... : 3254
15: Moi <root@invalid.address.org>................................. : 3237
16: idontuse@email.com............................................. : 3216
17: Richard <rgrdev_@gmail.com>.................................... : 3176
18: Francois Grieu <fgrieu@gmail.com>.............................. : 3084
19: Keith Thompson <kst-u@mib.org>................................. : 3078
20: Michael Foukarakis <electricdelta@gmail.com>................... : 3038

============================================================================
Top 20 responders by original text (at least 5 posts)
============================================================================
1: "io_x" <a@b.c.invalid>......................................... : 82.80%
2: lacos@ludens.elte.hu (Ersek, Laszlo)........................... : 79.56%
3: gwowen <gwowen@gmail.com>...................................... : 78.63%
4: "James" <no@spam.invalid>...................................... : 73.04%
5: ram@zedat.fu-berlin.de (Stefan Ram)............................ : 69.94%
6: markhobley@hotpop.donottypethisbit.com (Mark Hobley)........... : 68.62%
7: ike@localhost.claranet.nl (Ike Naar)........................... : 67.25%
8: "Bill Cunningham" <nospam@nspam.invalid>....................... : 66.16%
9: Seebs <usenet-nospam@seebs.net>................................ : 64.88%
10: Phred Phungus <Phred@example.invalid>.......................... : 64.20%
11: Tor Rustad <bwzcab@wvtqvm.vw>.................................. : 63.22%
12: richard@cogsci.ed.ac.uk (Richard Tobin)........................ : 62.64%
13: Nobody <nobody@nowhere.com>.................................... : 62.40%
14: Malcolm McLean <malcolm.mclean5@btinternet.com>................ : 62.39%
15: J <seaworthyjeremy@gmail.com>.................................. : 59.90%
16: James Kuyper <jameskuyper@verizon.net>......................... : 59.60%
17: William Ahern <william@wilbur.25thandClement.com>.............. : 59.22%
18: Kaz Kylheku <kkylheku@gmail.com>............................... : 59.02%
19: cri@tiac.net (Richard Harter).................................. : 57.29%
20: jacob navia <jacob@nospam.org>................................. : 54.67%

============================================================================
Bottom 20 responders by original text (at least 5 posts)
============================================================================
1: Richard <rgrdev_@gmail.com>.................................... : 15.01%
2: Dirk Bruere at NeoPax <dirk.bruere@gmail.com>.................. : 17.49%
3: happytoday <ehabaziz2001@gmail.com>............................ : 23.35%
4: blmblm@myrealbox.com <blmblm@myrealbox.com>.................... : 24.54%
5: Ian Collins <ian-news@hotmail.com>............................. : 24.69%
6: Phil Carmody <thefatphil_demunged@yahoo.co.uk>................. : 26.02%
7: Brian <coal@mailvault.com>..................................... : 28.31%
8: Flash Gordon <smap@spam.causeway.com>.......................... : 30.19%
9: Nick Keighley <nick_keighley_nospam@hotmail.com>............... : 30.53%
10: Michael Foukarakis <electricdelta@gmail.com>................... : 33.80%
11: Joe Wright <joewwright@comcast.net>............................ : 35.19%
12: santosh <santosh.k83@gmail.com>................................ : 36.59%
13: Ben Bacarisse <ben.usenet@bsb.me.uk>........................... : 38.30%
14: James Kanze <james.kanze@gmail.com>............................ : 38.37%
15: Tim Streater <timstreater@waitrose.com>........................ : 40.53%
16: Ben Pfaff <blp@cs.stanford.edu>................................ : 41.14%
17: Andrew Poelstra <apoelstra@localhost.localdomain>.............. : 41.31%
18: spinoza1111 <spinoza1111@yahoo.com>............................ : 41.32%
19: Luuk <luuk@invalid.lan>........................................ : 42.02%
20: Francois Grieu <fgrieu@gmail.com>.............................. : 42.47%

============================================================================
Top 20 threads by no. of articles
============================================================================
1: Warning to newbies............................................. : 227
2: Motivation of software professionals........................... : 156
3: The C FAQ...................................................... : 96
4: Efficency and the standard library............................. : 64
5: Missing braces around {0} initializer?!........................ : 42
6: A bit resistant to disruption.................................. : 35
7: newbie question on understanding the main() function........... : 21
8: calling a singly-linked list................................... : 18
9: pointers....................................................... : 18
10: a question about 1-dimension and 2-dimension array............. : 18
11: printf the values of a macro................................... : 17
12: My GetDirectoryTreeSize() function, couple of questions........ : 17
13: Looking for external program invocations....................... : 17
14: OT: Proper use of PRNGs........................................ : 17
15: Making FILE opaque............................................. : 16
16: C99 is not a failure (continued)............................... : 16
17: portable floating-point read/write............................. : 14
18: void * arithmetic.............................................. : 13
19: representation of register's fields............................ : 13
20: compiling C program containing Xutil functions................. : 12

============================================================================
Top 20 threads by size in KB
============================================================================
1: Warning to newbies............................................. : 943
2: Motivation of software professionals........................... : 491
3: The C FAQ...................................................... : 251
4: Efficency and the standard library............................. : 248
5: A bit resistant to disruption.................................. : 110
6: Missing braces around {0} initializer?!........................ : 97
7: newbie question on understanding the main() function........... : 52
8: My GetDirectoryTreeSize() function, couple of questions........ : 50
9: calling a singly-linked list................................... : 48
10: OT: Proper use of PRNGs........................................ : 47
11: representation of register's fields............................ : 44
12: compiling C program containing Xutil functions................. : 42
13: printf the values of a macro................................... : 40
14: Looking for external program invocations....................... : 36
15: pointers....................................................... : 35
16: Making FILE opaque............................................. : 34
17: So I want to exhaust a lot of memory........................... : 33
18: a question about 1-dimension and 2-dimension array............. : 32
19: reading the source of calling a singly-linked list............. : 31
20: void * arithmetic.............................................. : 30

============================================================================
Top 10 cross-posted groups
============================================================================
1: comp.lang.c++.................................................. : 151
2: comp.lang.java.programmer...................................... : 150
3: comp.lang.javascript........................................... : 150
4: microsoft.public.dotnet.general................................ : 144
5: comp.lang.c.moderated.......................................... : 19
6: comp.programming............................................... : 16
7: comp.lang.misc................................................. : 12
8: comp.unix.solaris.............................................. : 12
9: comp.unix.programmer........................................... : 12
10: comp.std.c..................................................... : 7

============================================================================
Top 10 User Agents by poster
============================================================================
1: G2/1.0......................................................... : 44
2: Mozilla........................................................ : 15
3: Thunderbird 2.0.0.23 (Windows/20090812)........................ : 11
4: rn............................................................. : 11
5: Gnus........................................................... : 8
6: KNode.......................................................... : 7
7: Microsoft Outlook Express...................................... : 7
8: Thunderbird 2.0.0.23 (X11/20090817)............................ : 6
9: Unknown........................................................ : 5
10: tin............................................................ : 5

============================================================================
Top 10 User Agents by number of posts
============================================================================
1: G2........................................................ : 314 (31%)
2: slrn...................................................... : 144 (14%)
3: Thunderbird 2.0.0.23 (Windows............................. : 114 (11%)
4: Gnus...................................................... : 93 ( 9%)
5: Mozilla................................................... : 59 ( 6%)
6: Thunderbird 2.0.0.23 (X11................................. : 54 ( 5%)
7: trn 4.0-test76 (Apr 2, 2001).............................. : 39 ( 4%)
8: Outlook Express........................................... : 35 ( 3%)
9: Pan....................................................... : 28 ( 3%)
10: Thunderbird 2.0.0.23 (Macintosh........................... : 25 ( 2%)

============================================================================
Top 10 time zones
============================================================================
1: UTC............................................................ : 386
2: -0800.......................................................... : 376
3: +0100.......................................................... : 117
4: -0500.......................................................... : 54
5: -0600.......................................................... : 33
6: -0700.......................................................... : 20
7: +0200.......................................................... : 17
8: +1300.......................................................... : 10
9: +0900.......................................................... : 1
10: +0800.......................................................... : 1

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

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

== 1 of 1 ==
Date: Sat, Feb 13 2010 12:09 pm
From: Keith Thompson

Seebs <usenet-nospam@seebs.net> writes:
[...]
> That said, I do like the idiom
> size_t lenstr(char *string) {
> char *end = string;
> while (*end++)
> ;
> return end - string;
> }
>
> Not that it's likely to make a noticeable difference. Or that it's likely
> worth it when obviously the standard library one will be fine.

Note that ``end - string'' yields a value of type ptrdiff_t, a signed
type which very likely can't represent all values of type size_t.

This is unlikely to be an issue in practice. On typical 32-bit
systems, problems show up only for strings longer than 2 gigabytes,
and even then the properties of 2's-complement arithmetic are likely
to result in the correct answer anyway.

But all this analysis, resulting in the conclusion that it will
almost certainly work properly, becomes unnecessary if you just
use strlen().

==============================================================================
TOPIC: The C FAQ
http://groups.google.com/group/comp.lang.c/t/b75c0ae09abf3345?hl=en
==============================================================================

== 1 of 4 ==
Date: Sat, Feb 13 2010 12:16 pm
From: lacos@ludens.elte.hu (Ersek, Laszlo)

In article <slrnhndqrj.6g.usenet-nospam@guild.seebs.net>, Seebs <usenet-nospam@seebs.net> writes:
> On 2010-02-13, Ersek, Laszlo <lacos@ludens.elte.hu> wrote:

>> As a lame "trick" question, how does the expression look where you
>> assign the value returned by dlsym(RTLD_NEXT, "open") to your
>> "orig_open" function pointer? :)
>
> I don't. :)
>
> What I have is:
>
> 1. I define a function named open() with the same signature as the syscall.
> 2. I define a function named dummy_open() with that same signature, too.
> 3. I define a pointer-to-function named real_open() with the same signature.
> 4. I define a function named wrap_open() with the same signature.

I was calling your pointer-to-function named real_open "orig_open". How
do you initialize it? :)

Thank you for the description,
lacos

== 2 of 4 ==
Date: Sat, Feb 13 2010 12:39 pm
From: pacman@kosh.dhis.org (Alan Curry)

In article <slrnhndmbn.2el.usenet-nospam@guild.seebs.net>,
Seebs <usenet-nospam@seebs.net> wrote:
|
|What this ends up doing is allowing me to intercept every system call that
|deals with the filesystem and is affected by privileges, and act as though
|you had root privileges, or at least, make it look as though it acted as

Somebody already did this. It's called fakeroot. Terrible duplication of
effort if you reinvented it from scratch

--
Alan Curry

== 3 of 4 ==
Date: Sat, Feb 13 2010 1:20 pm
From: Seebs

On 2010-02-13, Ersek, Laszlo <lacos@ludens.elte.hu> wrote:
> I was calling your pointer-to-function named real_open "orig_open". How
> do you initialize it? :)

With a magic bit of code using "dlsym()" to look up symbols in other
libraries, relying on a feature where it's possible to specify "give me
the next version after the one you already found". :)

== 4 of 4 ==
Date: Sat, Feb 13 2010 1:29 pm
From: Seebs

On 2010-02-13, Alan Curry <pacman@kosh.dhis.org> wrote:
> In article <slrnhndmbn.2el.usenet-nospam@guild.seebs.net>,
> Seebs <usenet-nospam@seebs.net> wrote:
>|What this ends up doing is allowing me to intercept every system call that
>|deals with the filesystem and is affected by privileges, and act as though
>|you had root privileges, or at least, make it look as though it acted as

> Somebody already did this. It's called fakeroot. Terrible duplication of
> effort if you reinvented it from scratch

We used to use fakeroot. It was unsuitable for our purposes in a number
of ways.

Among them:

1. Not much persistency. Fakeroot's good at handling a single build run
which completes in a few minutes. Our system has to handle doing dozens or
hundreds. Over a period of months.
2. Extreme vulnerability to database corruption if anything is changed
outside of it.
3. No real database to speak of; on exit, it writes a flat file list of
plain text data, and it can slurp that back in.
4. No file name tracking. This makes it harder to detect other errors.
5. Can get confused enough to, say, report that a directory is a plain
file, or vise versa.
6. Occasionally crashes, breaking programs relying on it.
7. Also, in default configuration, leaves shared memory segments allocated
and not cleaned up.

There were other issues. After careful study, we concluded that it would be
best to write one from scratch, from the ground up, addressing many of these
concerns.

Mine's called pseudo, and we're currently doing a code clean-up pass before
making it more widely available under some GPL variant. Key differences:

* Tracks file names in nearly-all cases. (You can get past it, but it is
very good at finding out file names.)
* Persistent database using sqlite3 maintained by the daemon.
* Database tracks both names and dev/inode pairs.
* Server does consistency checks and correctly handles cases such as, say,
a database entry which has the same inode as an incoming query, but has
a necessarily-incompatible type (e.g., is tagged as a directory but is
not).
* Client code can automatically restart the server if it goes away or isn't
available, so server doesn't need to be encouraged to stay running for a
long time just because a build might be slow.
* Can log every filesystem action it sees.

We used fakeroot in production systems for a couple of product releases.
Typically, if you loaded things up (say, started and stopped it dozens of
times during an extended build series), sooner or later, it would start
yielding garbage like claiming that a plain file was a directory, or giving
arbitrarily wrong results for files, or lose parts of the recorded state.
Or just crash. On average, if you were using the build system heavily, you'd
hit some kind of "fakeroot failed, you have to re-install all target packages"
thing about once or twice a week.

Since we put in pseudo, we've had one customer bug (which was in an area where
we'd decided to not fully implement something in the first release). When the
bug was reported, the report could tell us what file name pseudo expected to
see for a given file, and what file name had shown up, and why this was
surprising, allowing us to fix the bug in five minutes rather than spending
hours trying to figure out when that inode had been created or freed. We've
had a handful of bugs discovered internally during development, but as of this
writing, I have out for review fixes for the last bugs we are aware of that
have ever caused any kind of failure. (In fact, the last bugs we are aware
of. There have been bugs that didn't cause any failures, because pseudo is
extremely aggressive about sanity-checking its results.)

Basically, if you just look at the time that our developers lost to project
directories that got harmed by fakeroot failures, we've gotten the time I put
back on this returned to us about five-fold since I started.

I would not call it a waste of effort. We did research the alternatives
before trying this, and none of them were a good fit for our usage scenario.

(Relevance, such as it is: It's worth noting that there IS such a thing as
a time to rebuild something that already exists.)

==============================================================================
TOPIC: Missing braces around {0} initializer?!
http://groups.google.com/group/comp.lang.c/t/4e761f5803fec708?hl=en
==============================================================================

== 1 of 1 ==
Date: Sat, Feb 13 2010 1:24 pm
From: Azazel

On 2010-02-08, Ben Pfaff <blp@cs.stanford.edu> wrote:
> Andrew Poelstra <apoelstra@localhost.localdomain> writes:
>
>> Even for
>>
>> struct test {
>> int a;
>> int b;
>> int c;
>> }
>>
>> int main(void) {
>> struct test t = { 0 };
>> return 0;
>> }
>>
>> gcc warns me. And it's a particularly irritating warning because
>> it individually lists each struct member with a message that I am
>> "missing initialization".
>
> It's annoying.
>
> In practice I often end up doing this:
>
> struct test {
> int a;
> int b;
> int c;
> };
>
> #define TEST_INITIALIZER { 0, 0, 0 }
>
> int main(void) {
> struct test t = TEST_INITIALIZER;
> return 0;
> }