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 3 ==
Date: Tues, Feb 9 2010 5:23 am
From: Mike Duffy

Roedy Green <see_website@mindprod.com.invalid> wrote in
news:4d5qm59hu2crjdppqr6gun9f5k6mmqvhg1@4ax.com:

> Leaving motivations might include:
>
> personality conflict
> boredom
> too much pressure

- Working hours
- Lack of access to training
- Lack of privacy (email snooping, sharing a desk with others.)

And don't forget work-related health problems or an unhealthy work
environment that management refuses to address. (Harassement, A/C
ventilation, lack of ergonomic furniture, employee security etc.)

Death is always the most compelling reason for not continuing to work.

== 2 of 3 ==
Date: Tues, Feb 9 2010 10:07 am
From: Tom Anderson

On Mon, 8 Feb 2010, Seebs wrote:

> On 2010-02-08, Martin Gregorie <martin@address-in-sig.invalid> wrote:
>> That's easy: anybody who isn't a member of a recognised engineering
>> society should not be called an engineer and should be laughed out of
>> town if they call themselves one.
>
> This strikes me as the polar opposite of an engineering mindset, which
> would be that a thing is what it is, and isn't what it isn't, regardless
> of any labels.

No, the engineering mindset is that a thing is what it's been validated by
testing to be. If it works but you haven't proven it works, then it
doesn't work. You could see qualifications as being the HR equivalent of
testing.

The minor problem here is that no *software* engineering qualifications
are worth shit, because there isn't really such a thing as software
engineering, but that's a different debate.

tom

--
No hay banda

== 3 of 3 ==
Date: Tues, Feb 9 2010 11:12 am
From: Martin Gregorie

On Tue, 09 Feb 2010 18:07:45 +0000, Tom Anderson wrote:

>
> The minor problem here is that no *software* engineering qualifications
> are worth shit, because there isn't really such a thing as software
> engineering, but that's a different debate.
>
...and an MBCS is worth remarkably little because bad apples never seem
to be thrown out.

--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |

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

== 1 of 3 ==
Date: Tues, Feb 9 2010 5:34 am
From: Ben Bacarisse

William Ahern <william@wilbur.25thandClement.com> writes:

> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
> <snip>
>> It's turned on with -Wextra.
>
> Ah, thank you.
>
> This C99 named initialization construct works w/o any warning:
>
> struct test t = { .a = 0 };
>
> I want to say that the standard explicitly says that every other member is
> implicitly zero initialized in this case, but that's just from my poor
> memory.

Yes they are. 6.7.8 p19:

The initialization shall occur in initializer list order, each
initializer provided for a particular subobject overriding any
previously listed initializer for the same subobject; all subobjects
that are not initialized explicitly shall be initialized implicitly
the same as objects that have static storage duration.

--
Ben.

== 2 of 3 ==
Date: Tues, Feb 9 2010 9:44 am
From: Keith Thompson

Phil Carmody <thefatphil_demunged@yahoo.co.uk> writes:
> Keith Thompson <kst-u@mib.org> writes:
>> Phil Carmody <thefatphil_demunged@yahoo.co.uk> writes:
>>> Keith Thompson <kst-u@mib.org> writes:
[...]
>>>> The initializer { 0 } sets all members of the initialized object to
>>>> zero. This is, or should be, a common C idiom. gcc just doesn't
>>>> recognize it.
>>>
>>> Please provide proof that it doesn't recognise it. Please be more
>>> detailed than the above - precisely which bit of the construct do
>>> you think it is unable to cope with? From my perspective, it looks
>>> as if it understands the construct and the legality, and typical use,
>>> of same, perfectly.
>>
>> Hmm. I really thought I was sufficiently clear.
>>
>> gcc, like any conforming C compiler, certainly recognizes the
>> initializer { 0 } and correctly handles its syntax and semantics.
>> What I meant is that it doesn't recognize it *as an idiom* for
>> "recursively initialize this object and all its sub-members and
>> sub-elements to zero".
>
> Hmm. I really thought I was sufficiently clear.

No, I thought you were missing my point, deliberately or otherwise.

> The above is no
> proof that it's not recognised as an idiom for the above. Just
> because it's recognised as an idiom doesn't mean the compiler can't
> throw up warnings about it. Calling something an idiom doesn't
> magically make everything that looks like it safe and not worth
> warning about. Common mistakes can be idiomatic of a language too.

If gcc recognizes { 0 } as an idiom, it doesn't appear to do anything
with the information. As far as I can tell, it doesn't make any
distinction at all between { 0 } and any other initializer that
leaves some sub-objects to take implicit 0 values. It doesn't treat
{ 0 } as any kind of special case. Perhaps you see some meaningful
distinction here. I don't.

>> Consider the following translation unit:
>>
>> struct s { int x; int y; int z; };
>> struct s s1 = { 0 };
>> struct s s2 = { 0, 0 };
>>
>> With "-Wmissing-field-initializers" or equivalent, gcc warns about
>> both initializers. With "-Wno-missing-field-initializers", gcc
>> doesn't warn about either of them.
>>
>> What I would like is a way to make gcc, or whatever compiler I happen
>> to be using, to warn about the initialization of s2 (because it's
>> missing an initializer for z), but not about the initialization
>> of s1 (because it's using the "{ 0 }" idiom, and I *deliberately*
>> omitted explicit initializers for most of the members).
>>
>> One possible drawback is that if I write "{ 0 }", I might really
>> have meant that the object has exactly one member or element rather
>> than that I don't want to specify how many it has.
>
> Exactly. Treating elision to denote intent is dangerous. Sufficiently
> dangerous for gcc to consider it worth a warning with most common
> invocations.

Which may well be why gcc doesn't recognize { 0 } as an idiom (i.e.,
treat it as a special case that doesn't require a warning).

Nevertheless, I think that the risk of failing to warn about
{ 0 } when it's incorrect is outweighed by the benefit of dropping
the warning in the majority of cases where it's correct.

Then again, there's another way to do this, though it requires
an extra declaration:

const static struct s struct_s_zero;
struct s s1 = struct_s_zero;

>> What I'd like even better is a change to the language so that "{ }"
>> is equivalent to what "{ 0 }" currently means, but I can expect a
>> compiler not to warn me about it.
>
> I approve of that, certainly.
>
>> I have another idea, but it would break tons of existing code, so it's
>> unlikely ever to make it into the language. By default, require
>> explicit initializers for all subobjects. Allow "..." to indicate
>> that the current subobject and everything following it is implicitly
>> zero. Thus:
>>
>> struct s s1 = { 0 }; /* constraint violation */
>> struct s s2 = { 42, ... }; /* x = 42, y = 0, z = 0 */
>> struct s s3 = { ... }; /* initialize all members to 0 */
>> struct s s4 = { 1, 2, 3, ... }; /* probably ok */
>>
>> There would be a lot of details to work out; since it would break
>> existing code, I won't bother.
>
> I approve of an explicit '...' to represent an explicit request
> (to initialise all further subobjects to 0) too. Only the orthogonal
> addition of the requirement for other initialisations to be fully
> explicit causes breakage.

The problem with that variation of the idea is that, assuming "..."
is permitted when there are no remaining subobjects, it doesn't
mean anything. Any initializer with ", ..." still means exactly
the same thing if you delete the ", ...". A compiler could use the
presence of ", ..." to decide not to issue a warning (in a context
that doesn't require a diagnostic anyway), but I doubt that the
committee would accept that as a good enough reason to add a new
feature to the language. A comment would serve the same purpose.

If the ", ..." is permitted only when there are additional
subobjects, so that my example
struct s s4 = { 1, 2, 3, ... };
is a constraint violation, it might be a useful feature. But then you
couldn't use { 0, ... } in all cases.

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

== 3 of 3 ==
Date: Tues, Feb 9 2010 9:53 am
From: Malcolm McLean

On Feb 9, 2:05 am, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
>
> You accept topicality drift within a thread -- into the merits of
> Norman Wisdom's slapstick for example -- but you seem to be suggesting
> that how one might configure gcc's warnings is beyond the pale.
>
>
There's a difference between topic drift (from C's logical operators
to binary numbers to the possibility of building a base phi computer
to Fibbonacci series generally to connections between Fibbonaci series
and the Mandelbrot set to computer graphics to X-windows bad graphics
capabilities to gcc warnings) and starting off a thread on gcc
warnings.

==============================================================================
TOPIC: a question about 1-dimension and 2-dimension array
http://groups.google.com/group/comp.lang.c/t/12a853df84e98d5c?hl=en
==============================================================================

== 1 of 7 ==
Date: Tues, Feb 9 2010 5:48 am
From: Ben Bacarisse

dimilar <zhus@in.tum.de> writes:
> Luuk <luuk@invalid.lan> writes:
>
>> Op 9-2-2010 13:42, Dimilar Zhu schreef:
>>> ....., which is faster? ......
>>
>> btw, why do you care about speed,
>> you are living in the FUTURE!
>
> just a question, yesterday my boss asked me. he is a doctor, and do not know
> much about detail of computer language. but at that time i do not know how
> to answer it. so I said, "it depends....blablabla".

Good answer, though you could have said that data structures aren't
fast or slow, it is algorithms that have certain performance
characteristics. In particular, it is the pattern of accesses that
determines what the best data structure is for a particular problem.

If this is something that needs a fuller answer, then post on
comp.programming with an outline of what it is you are trying to do
(at the highest level -- invert a matrix, find a clique in a graph
etc.) because this is not really a C question.

--
Ben.

== 2 of 7 ==
Date: Tues, Feb 9 2010 6:22 am
From: richard@cogsci.ed.ac.uk (Richard Tobin)

In article <87pr4ev8mv.fsf@dimilar.localdomain>,
dimilar <zhus@in.tum.de> wrote:

>for 2-dimension array, it is necessary to do much multiplication to obtain the
>index of element.

Certainly accessing a 2d array *conceptually* involves multiplication.
But if you can straightforwardly use a 1d array instead, then quite
likely so can the compiler. For example, in

int a[n1][n2];

for(i=0; i<n1; i++)
for(j=0; j<n2; j++)
... do something with a[i][j] ...;

a reasonable compiler will not calculate i*n2+j from scratch each time
round the inner loop. It can compute i*n2 once each time round the
outer loop, and may not even do that.

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

== 3 of 7 ==
Date: Tues, Feb 9 2010 8:00 am
From: dimilar

richard@cogsci.ed.ac.uk (Richard Tobin) writes:

> In article <87pr4ev8mv.fsf@dimilar.localdomain>,
> dimilar <zhus@in.tum.de> wrote:
>
>>for 2-dimension array, it is necessary to do much
> multiplication to obtain the
>>index of element.
>
> Certainly accessing a 2d array *conceptually* involves
> multiplication.
> But if you can straightforwardly use a 1d array instead,
> then quite
> likely so can the compiler. For example, in
>
> int a[n1][n2];
>
> for(i=0; i<n1; i++)
> for(j=0; j<n2; j++)
> ... do something with a[i][j] ...;

for the case you described here, multiplication is not a problem because you are
accessing elements in a certain order. but if we randomly access
many elements from a large 2d array. many multiplication is
inevitable. although I am also not sure it is a bottleneck.

however, I think it is really an algorithms dependent problem.
Thanks for you reply :)

> a reasonable compiler will not calculate i*n2+j from scratch
> each time
> round the inner loop. It can compute i*n2 once each time
> round the
> outer loop, and may not even do that.
>
> -- Richard

== 4 of 7 ==
Date: Tues, Feb 9 2010 8:24 am
From: Mark Bluemel

On 9 Feb, 12:42, Dimilar Zhu <z...@in.tum.de> wrote:
> I have 10000 numbers. Now i need to choose a kind of data structure to save them.
> of 1-dimension and 2-dimension array, which is faster? does it depend
> on factors such as degree of order, correlation, operations?

As I think others have said, this really isn't that much of a C
question. It's more a general computing question, and even then you
haven't given us enough information to go on.

What do your 10000 numbers represent? How do you expect to populate
the data structure and how do you expect to access it?

If the natural representation of your data is as a two-dimensional
array, I don't see how it would be any advantage for you to flatten it
to one dimension and do the maths to access your target cells.

Equally, if the natural representation is one dimensional, why would
you do anything else?

== 5 of 7 ==
Date: Tues, Feb 9 2010 8:59 am
From: Malcolm McLean

On Feb 9, 2:42 pm, Dimilar Zhu <z...@in.tum.de> wrote:
> I have 10000 numbers. Now i need to choose a kind of data structure to save them.
> of 1-dimension and 2-dimension array, which is faster? does it depend
> on factors such as degree of order, correlation, operations?

In C a 2-dimensional array is stored as a flat structure continuously
in memory. So the only performance difference is (potnetially) due to
the difference between accessing array[y][x] as opposed to
array[y*width+x]. It's hard to think of circumstances where the first
would be slower, but often the second mght be slower because it is
harder for the compiler to optimise out constants.
However typically the dimensions of a 2d array are either not known at
compile time, or are undesireable to hardcode into low-level
functions. So the 1d method is usually the way to go, in C.

== 6 of 7 ==
Date: Tues, Feb 9 2010 12:33 pm
From: Tor Rustad

Dimilar Zhu wrote:
> I have 10000 numbers. Now i need to choose a kind of data structure to save them.
> of 1-dimension and 2-dimension array, which is faster? does it depend
> on factors such as degree of order, correlation, operations?

it depends. :)

what matter is how you access the data, for example how FORTRAN and C
store data in a matrix (i.e. 2-dimensional array) is different... in
FORTRAN it's optimized for matrix computations, while in C the matrix
components is stored column wise, that is, given

int matrix[i][j];

then has matrix[0][0] is at first memory location, and at the second
location we have matrix[0][1]... hence if you don't access the matrix
components that way, you risk triggering cache misses. To avoid cache
misses, you need locality of data during access, and it's a good idea to
avoid unaligned data as well.

Consider this inner loop

for (k=0; k < max; k++)
{
sum += a[i][k] * b[k][j];
}

here matrix a[][] is accessed column wise (same as C store the data),
but matrix b[][] is *not*... and you may risk stalling the cache pipeline.

Which may not matter a thing when doing disk or network I/O, as your CPU
then usually is idle most of the time anyway.... :)

--
Tor <echo bwzcab@wvtqvm.vw | tr i-za-h a-z>

== 7 of 7 ==
Date: Tues, Feb 9 2010 1:47 pm
From: ram@zedat.fu-berlin.de (Stefan Ram)

Dimilar Zhu <zhus@in.tum.de> writes:
>I have 10000 numbers. Now i need to choose a kind of data structure to save them.

If you have 10000 number you already /have/ a data structure
to hold them, otherwise you would not /have/ them.

If you want to /save/ them to a file, you do not need a data
structure but a data language (aka a file format) to
serialize (marshal, pickle, shelve) them to.

>of 1-dimension and 2-dimension array, which is faster?

Arrays do not have a speed at all. Only operations
have a speed.

==============================================================================
TOPIC: A bit resistant to disruption
http://groups.google.com/group/comp.lang.c/t/a5ddb7c1aa07c7e5?hl=en
==============================================================================

== 1 of 3 ==
Date: Tues, Feb 9 2010 6:10 am
From: Seebs

On 2010-02-09, Francois Grieu <fgrieu@gmail.com> wrote:
> [I messed up my earlier reply, sorry; let me try again]

No worries. I already found a bug in this one, which is that if we're
currently pointing at cell 1, and cell 1 and cell 0 are different, multiple
successive bRead() calls could inadvertantly flip back to cell 0 without
a toggle.

Hmm.

Does an eErase() of a cell which is already zero risk creating indeterminacy,
or does it stay zero regardless of disruptions?

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

== 2 of 3 ==
Date: Tues, Feb 9 2010 6:30 am
From: Francois Grieu

Seebs wrote:
> On 2010-02-09, Francois Grieu <fgrieu@gmail.com> wrote:
>> [I messed up my earlier reply, sorry; let me try again]
>
> No worries. I already found a bug in this one, which is that if we're
> currently pointing at cell 1, and cell 1 and cell 0 are different, multiple
> successive bRead() calls could inadvertantly flip back to cell 0 without
> a toggle.
>
> Hmm.
>
> Does an eErase() of a cell which is already zero risk creating indeterminacy,

No. I wanted that to be implied by "After undisrupted eErase, eRead
returns 0 until eProgram is invoked." and confirmed by "An EEPROM cell
can be left neither erased nor programmed by a disrupted eErase unless
that cell was already erased".

> or does it stay zero regardless of disruptions?

I stays zero.

It took some effort to have the maker of the EEPROM assert that. I have
strong arguments towards the conjecture that the problem can't be solved
if this insurance is removed.

Francois Grieu

== 3 of 3 ==
Date: Tues, Feb 9 2010 6:58 am
From: Seebs

On 2010-02-09, Francois Grieu <fgrieu@gmail.com> wrote:
>> Does an eErase() of a cell which is already zero risk creating indeterminacy,
>
> No. I wanted that to be implied by "After undisrupted eErase, eRead
> returns 0 until eProgram is invoked." and confirmed by "An EEPROM cell
> can be left neither erased nor programmed by a disrupted eErase unless
> that cell was already erased".
>
>> or does it stay zero regardless of disruptions?
>
> I stays zero.

Okay.

> It took some effort to have the maker of the EEPROM assert that. I have
> strong arguments towards the conjecture that the problem can't be solved
> if this insurance is removed.

I believe you are correct.

So, it seems like the key gimmick would be to have values where "0" is a
safe state, so if they look to be 0, you can set them to 0 unconditionally.

Hmm. This is pretty tricky. I am pretty sure it's doable, but everything
I've come up with so far ends up in a case where you can't tell which bit
is indeterminate, and trying to stabilize them risks leaving two bits
indeterminate.

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

== 1 of 5 ==
Date: Tues, Feb 9 2010 6:13 am
From: Seebs

On 2010-02-09, Walter Banks <walter@bytecraft.com> wrote:
> I seem to have missed the design and test spec for this exercise.

There really wasn't one.

The original goal was to calculate a particular value, then insert it at
marked locations into strings. We seem to have generalized to:
replace(a, b, c);
=> A newly allocated pointer containing a copy of c in which each occurrence
of a has been replaced by the contents of b, not rescanning for occurrences of
a.

== 2 of 5 ==
Date: Tues, Feb 9 2010 9:02 am
From: spinoza1111

On Feb 9, 10:13 pm, Seebs <usenet-nos...@seebs.net> wrote:
> On 2010-02-09, Walter Banks <wal...@bytecraft.com> wrote:
>
> > I seem to have missed the design and test spec for this exercise.
>
> There really wasn't one.
>
> The original goal was to calculate a particular value, then insert it at
> marked locations into strings. We seem to have generalized to:
> replace(a, b, c);
> => A newly allocated pointer containing a copy of c in which each occurrence
> of a has been replaced by the contents of b, not rescanning for occurrences of
> a.

Das ist ein Anders, yet another consideration.

Repeat the replace until the number of replacements comes back as
zero. I suggest that there is no reason why this could not be built on
top of a one shot replace, with a name like rereplace or
mungUntilZero.

Certainly a consideration for my Issues list: should replace() provide
this, or is it really a separate function point? I am obliged to you
for a change.

It would probably be a mistake to overload replace() with a lot of
options. But given that we have seen that the function and its name
are so very polysemic, having multiple meanings, it is important to
clarify which of the particular styles of replace is supported.

Which the C libraries so signally fail to do. Instead, they present a
hegemonic view of reality, in which strings are "normally" terminated
with Nul, etc.

We have: left to right, right to left, some other order including
inside out and random, and repeated.

Ham.
Well said old Mole, can'st worke i'th' ground so fast?
A worthy Pioner, once more remoue good friends.

Hor.
Oh day and night: but this is wondrous strange.

Ham.
And therefore as a stranger giue it welcome.
There are more things in Heauen and Earth, Horatio,
Then are dream't of in our Philosophy.

An arrogant silence however reigns in the computing discourse which
proclaims that the solution is easy, simple, and unitary. Rather like
Tea Party politics.

== 3 of 5 ==
Date: Tues, Feb 9 2010 9:09 am
From: spinoza1111

On Feb 9, 9:18 pm, Walter Banks <wal...@bytecraft.com> wrote:
> spinoza1111wrote:
> > I just crap out with a deliberate planned abort()
>
> > There are other theoretical issues such as left to right versus right
> > to left and whether ana occurs once or twice in banana which shall be
> > addressed, hopefully.
>
> I seem to have missed the design and test spec for this exercise.

Are you kidding? This is Extreme Programming. I just said to myself a
few days ago that it was time to show Peter how it's done. I sorta
decided, screw string.h. So the design contract was "develop a simple
replace() without using the string library". Which has been done.

I would like to return this newsgroup to collaborative work in an
atmosphere of civil discourse and common problem solving, as opposed
to the usual sniping. I did so in the Shakespeare group by getting my
enemies there to help me write a sonnet.

Richard Heathfield is probably closeted with Dr. Evil at this point,
getting yelled at for losing control of the group.

It's all good.
>
> w..

== 4 of 5 ==
Date: Tues, Feb 9 2010 9:24 am
From: spinoza1111

On Feb 9, 3:55 pm, Seebs <usenet-nos...@seebs.net> wrote:
> On 2010-02-09, Richard Heathfield <r...@see.sig.invalid> wrote:
>
> >spinoza1111wrote:
> ><Seebs's parody code snipped>
>
> >> You've written this code and presented it as mine. This is egregious
> >> dishonesty and highly unprofessional.
> > It's called "parody", and is perfectly legal (except in North Dakota
> > during the summer months). As parody, it excels, since you think he's
> > presenting the code as if you'd written it, whereas in fact all he's
> > really doing is caricaturing your style. There is nothing dishonest or
> > unprofessional about parody.
>
> Allow me to quote my post to clarify:
>
> >>>I just hope he never realizes that his implementation of a string length
> >>>counter is not particularly overth^H^H^H^H^Hrobustly engineered. If he
> >>>does, we'll get something like this:
>
> (line breaks altered from the original).
>
> Note: "something like this" is clearly intended to demonstrate that I am
> talking about the *style* or *manner* of the Nilges code we've seen, such
> as a hundred lines of extraordinarily bad code trying to solve a problem
> that could easily be solved in about fifteen lines of code... and it
> didn't even work after three or four edits to fix bugs introduced by
> an overly baroque style.
>
> I do not have any worries about people mistaking my parody code for
> actual Nilges code, nor did I present it as such. For one thing, I
> didn't use the sort of bastardized and botched systems Hungarian Nilges
> uses. I can do a lot for art, but there are limits. For another thing,
> I did manage in a few places to go beyond the level of insanity we
> normally see in his code. For instance, <malloc.h> is silly, but
> <emmintrin.h> is ridiculous. (It's, so far as I can tell, a gcc internal).
>
> I also cleaned it up some by using ~0 rather than -1 as "true" -- I figure
> if you're going to ask for all-bits-one, you might as well do it explicitly.
>
> In short, to some extent, it's not a very good caricature; I didn't really
> pick up some of the most odious stuff, but I think I did a reasonable job
> of capturing the essence of over-engineering informed by mind-numbing
> ignorance, coupled with random and misdirected vitriol and name dropping.
>
> -s
> --
> Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.nethttp://www.seebs.net/log/<-- lawsuits, religion, and funny pictureshttp://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

No, you did it for the same reason Richard claimed that I'd never been
accepted in the moderated group comp.risks. You hoped that people
would understand that your "parody" was representative of my code and
would be remembered instead. You threw shit at the wall to see what
would stick like an enraged toddler.

You see, Fascists and Nazis have no sense of humor whatsoever. The
Nazis highjacked cabaret satire of the Weimar era for their own
purposes. The progressive artists that created Weimar satire meant to
poke fun at the Establishment: the Nazis on the other hand wanted
their caricature of "der ewige Juden" to become the reality in the
public mind.

(Yeah, Godwin. As I have said before, Godwin doesn't know his ass from
a hole in the ground, because he doesn't know that the real tendency
in the downsized technical lower middle class is indeed towards
Fascism, and in many cases, the Hitler comparision is apt.)

In a grim little fashion, in the grim little way you "made fun of"
Herb Schildt to advance your career by destroying his (at which
project you failed), you're not having any fun at all. The way you
frantically posted Monday morning my time showed you were having a
panic attack because your pathetic little code had been carpet bombed
by a correct solution.

Your caricature isn't reality. The reality is that working a few hours
after not using C for near to twenty hours, I coded a far more
competent program. The style you call "baroque" is in fact a more
careful and precise layout and your term, "baroque", is used in the
slop corporate way, where "baroque", like "verbose", means, "I don't
have time to shave, so how does this unknown clown with a funny name,
how does this Nilges find the time to construct a complete sentence or
format code as to meaning?"

Finally, dear little Peter, my code works thanks to my efforts and the
testing of santosh and Ike Naar. You have yet to fix your original
solution. If this is "over-engineering", so be it.

You want the lazy and attention disordered, the creepy and the rude,
to just glance at this thread and see my name associated with the
caricature. Unfortunately the truth will out.

== 5 of 5 ==
Date: Tues, Feb 9 2010 9:36 am
From: spinoza1111

On Feb 9, 3:50 pm, Richard Heathfield <r...@see.sig.invalid> wrote:
> spinoza1111wrote:
> > On Feb 9, 4:32 am, Keith Thompson <ks...@mib.org> wrote:
> >> Squeamizh <sque...@hotmail.com> writes:
>
> >> [...]
>
> >>> I don't know what's more funny- Spinoza's inability to get this simple
> >>> problem right, or Seebs' continued childish insistence that he only
>
> > As I said, I posted the code for COLLABORATIVE development and
> > testing,
>
> If that's true, why did you make it so hard to read? Or, if you think it
> *should* be hard to read, why didn't you make it harder to read?
>
> > and I received professional assistance from Santosh and Ike
> > Naar, which helped me to complete the project.
>
> If that's a complete project, I'm a Dutchman.
>
> > That is what this ng was meant for: not for posting "satiric" code as
> > mine in an actionably libelous lie.
>
> > Santosh and Ike Naar found problems which I fixed in a few hours on
> > Sunday.
>
> And I found a problem that took you several hours to fix all by itself.

You're Bedlam.

The "problems" to which you refer are "problems" only to fools like
you who irresponsibly believe that C code can be ported without line
by line review! Whereas in the past and up until Sunday I accepted
this trivial "portability of #include" points, I now realize you make
them because you're not qualified.

There are in fact strong arguments for keeping #include usage
idiomatic to a particular compiler, because code that has NOT been
reviewed line by line should not compile.

You don't understand that the worst bug is the one you don't know
about (such as the bugs you've left behind you at your clients). If a
"standard" approach is used with the "correct" includes, the code
below the includes can be in fact complete crap.

It is in fact, in C, malpractice to at any time claim "my code is
truly portable because it is standard, and I know all the fashionable
shibboleths". This is because there are hundreds, perhaps thousands,
of compilers for what is commonly understood to be C which violate
your standard. To make the claim without having several machines and
several compilers to hand, and without testing the code on each, is
irresponsible.

Yet this is what you recommend. It is very possible, of course, that
you have several machines and compilers in your rec room amidst the
pizza boxes and beer cans, and for your clients you may multitest. But
it's insane for you to think that everyone can or should do this.

I started out in computing long before you, in all probability. I find
it's "matured" to sclerosis, for it's become a field wherein people
think they're indemnified against the mess they make by rules
following, and refuse to take responsibility either for the problems
they cause or the malicious falsehoods they purvey.

> Deleting a single line can be terribly, terribly, difficult, can't it?
>
> > Heathfield and Seebie have demonstrated that they are disruptive
> > creeps.
>
> > Don't you DARE compare me to them!
>
> That's up to him, but I can't say I'm overly excited by the idea of
> being in the same comparison as you, and I don't suppose Seebs is either.

You are welcome to consider yourself a different order of being. Such
as Homunculus or Troglodyte. Or just plain blowhard and fool.

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

==============================================================================
TOPIC: compiling C program containing Xutil functions
http://groups.google.com/group/comp.lang.c/t/d8c280c034411583?hl=en
==============================================================================

== 1 of 2 ==
Date: Tues, Feb 9 2010 7:28 am
From: Fred

On Feb 8, 3:10 pm, happytoday <ehabaziz2...@gmail.com> wrote:
> On Feb 9, 12:30 am, toucan <tou...@zoo.invalid> wrote:
>
>
>
>
>
> > happytoday wrote:
> > > I failed to compile that program as written below with those error
> > > messages :
> > > The conditions of compiling this program are not available any longer
> > > in the net so please help me compiling this program .
>
> > > Error messages :
> > > ------------------------
> > > root @ Homer /export/home/unix.d/programs.d/clang.d/GUI>cc plot_data.c
> > > "plot_data.c", line 15: warning: implicit function declaration:
> > > create_int_dialog_entry
> > > "plot_data.c", line 16: warning: implicit function declaration:
> > > create_float_dialog_entry
> > > "plot_data.c", line 20: warning: implicit function declaration:
> > > set_up_dialog
> > > "plot_data.c", line 24: warning: implicit function declaration:
> > > read_dialog_window
> > > Undefined first referenced
> > > symbol in file
> > > create_int_dialog_entry plot_data.o
> > > create_float_dialog_entry plot_data.o
> > > read_dialog_window plot_data.o
> > > set_up_dialog plot_data.o
> > > ld: fatal: Symbol referencing errors. No output written to a.out
>
> > > Sources code :
> > > ------------------------
> > > #include </usr/openwin/share/include/X11/Xlib.h>
> > > #include </usr/openwin/share/include/X11/Xutil.h>
>
> > It would be better to write
> > #include <X11/Xlib.h>
> > #include <X11/Xutil.h>
>
> > then, probably something like the following, assuming your
> > lib files are in /usr/openwin/lib (e.g. libXlib.a if it's
> > the correct name for your library)
> > cc -I/usr/openwin/share/include -L/usr/openwin/lib -lXlib -lXutil
>
> > > #include <stdio.h>
> > > #include <math.h>
>
> > > int main()
> > > {
> > > /* Define default values: */
>
> > > int n = 0;
> > > float x = 0.0;
>
> > > /* Define contents of dialog window */
>
> > > create_int_dialog_entry("n", &n);
> > > create_float_dialog_entry("x", &x);
>
> > > /* Create window with name "Setup" and top-left corner at (0,0) */
>
> > > set_up_dialog("Setup", 0, 0);
>
> > > /* Display the window and read the results */
>
> > > read_dialog_window();
>
> > > /* Print out the new values */
>
> > > printf("n = %d, x = %f\n", n, x);
> > > return 0;
> > > }
>
> The problem that I do not know what library files should be included
> to resolve these functions
> so I compiled with the below errors :
>
> root @ Homer /clang>head plot_data.c
> #include <X11/Xlib.h>
> #include <X11/Xutil.h>
> #include <stdio.h>
> #include <math.h>
>
> int main()
> {
> /* Define default values: */
>
> int n = 0;
> root @ Homer /clang>
>
> root @ Homer /clang>cc -I/usr/openwin/share/include -L/usr/openwin/lib
> -lXlib -lXutil plot_data.c

Are you sure you want "-I/usr/openwin/share/include" instead of
"-L/usr/openwin/share/include" ?

Where are libX11.aand libXutil.a on your system?

In my experience, Sun Unix platforms put them in "/usr/openwin",
while most other -nix platforms put them (or at least links to them)
in /usr/lib or /usr/X11R6.

You need to find where thosw libraries are on your system, and
set the "-L" options appropriately to point to them.

> "plot_data.c", line 15: warning: implicit function declaration:
> create_int_dialog_entry

Line 15 of your source code apparently references a function
named "create_int_directory_entry" without you having provided
a prototype for that function.

> "plot_data.c", line 16: warning: implicit function declaration:
> create_float_dialog_entry
> "plot_data.c", line 20: warning: implicit function declaration:
> set_up_dialog
> "plot_data.c", line 24: warning: implicit function declaration:
> read_dialog_window

Ditto for these warnings.

> ld: fatal: library -lXlib: not found
> ld: fatal: library -lXutil: not found

libXlib.a and libXutil.a could not be found in the paths you provided.

> ld: fatal: File processing errors. No output written to a.out- Hide quoted text -
>
> - Show quoted text -

--
Fred K

== 2 of 2 ==
Date: Tues, Feb 9 2010 9:11 am
From: toucan

happytoday wrote:

> The problem that I did know well what files concerning these functions
> so I compiled with the below errors :
> root @ Homer /clang>head plot_data.c
> #include <X11/Xlib.h>
> #include <X11/Xutil.h>
> #include <stdio.h>
> #include <math.h>
>
> int main()
> {
> /* Define default values: */
>
> int n = 0;
> root @ Homer /clang>
>
>
> root @ Homer /clang>cc -I/usr/openwin/share/include -L/usr/openwin/lib
> -lXlib -lXutil plot_data.c
> "plot_data.c", line 15: warning: implicit function declaration:
> create_int_dialog_entry
> "plot_data.c", line 16: warning: implicit function declaration:
> create_float_dialog_entry
> "plot_data.c", line 20: warning: implicit function declaration:
> set_up_dialog
> "plot_data.c", line 24: warning: implicit function declaration:
> read_dialog_window
> ld: fatal: library -lXlib: not found
> ld: fatal: library -lXutil: not found
> ld: fatal: File processing errors. No output written to a.out

It looks like something is wrong : did you check the "implicitly
declared" function are really in those header files ? Did you check
the lib file are really in this directory ?

==============================================================================
TOPIC: calling a singly-linked list
http://groups.google.com/group/comp.lang.c/t/163ef25eec8f0a79?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Feb 9 2010 7:45 am
From: Kaz Kylheku

On 2010-02-09, Phred Phungus <Phred@example.invalid> wrote:
> Tom St Denis wrote:
>> On Feb 8, 5:26 am, Phred Phungus <Ph...@example.invalid> wrote:
>>> , am I correct to think that the list is visible to entire program? My
>>> question is how main would correctly output what I input.
>>
>> There is no variable named "list" in the entire program. There is a
>> struct named 'list' which is visible to the entire unit.
>>
>> Tom
>
> So it doesn't go away until the entire program does, right?

Since it is a type, ``struct list'' goes away before the program even
starts,

A common feature of C programming environments is that types may be
retained in the form of debugging information, but that's not required
by the language.

==============================================================================
TOPIC: My GetDirectoryTreeSize() function, couple of questions.
http://groups.google.com/group/comp.lang.c/t/4d2252c07e2c2c0f?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Feb 9 2010 12:31 pm
From: Poster Matt

First of all if the code below is a mess on your screen, or if you'd prefer to
read it on a web page, then it's up on pastie - here: http://pastie.org/816917

I'm back doing some C coding on Linux, having not coded in C for 15 years...

My project needs the total file size of all the files in a directory tree, so I
wrote the function below. It calls itself recursively (wow, haven't needed to
use recursion in a while!). The function works fine, but I have a couple of
questions.

1) Am I freeing the memory correctly?

2) It seems like a lot of code to do something so simple. I had a look at
basically the same thing I wrote in C# a couple of years ago (which uses the
same recursive logic but uses only 10 lines of code). Is the code below more
lengthy than need be? In other words, have I missed an easier way of doing it,
by my choice of C standard library functions?

3) Any glaring mistakes in the code? I know I'm not checking malloc's return
value (I'll use my own mallocOrDie() function later), and ditch the printf()s.

Thanks all.

// Returns the size in bytes of a dir tree.
// Make sure char* dirName ends in a '/'.
long GetDirectoryTreeSize(char* dirName)
{
// Total in bytes
long total = 0;

DIR *directory;
struct dirent *dirItem;
struct stat statbuf;

// Open dir for reading or exit()
directory = opendir(dirName);
if (directory == NULL)
{
printf("\nCan't open dir: %s", dirName);
exit(1);
}

// Loop through files and subdirs.
while ((dirItem = readdir(directory)) != NULL)
{
// If item is a file, make full path and add its file size.
if (dirItem->d_type != DT_DIR)
{
// Make full path to the file.
int fullPathLen = strlen(dirName) + strlen(dirItem->d_name) + 1;
char* fullPath = (char*) malloc(fullPathLen);
sprintf(fullPath, "%s%s", dirName, dirItem->d_name);

// Call stat(), put file stats in statbuf.
int ret = stat(fullPath, &statbuf);

// On sucess stat() returns 0.
if (ret == 0)
total += statbuf.st_size;

printf("\n%s - %ld", fullPath, statbuf.st_size);

free(fullPath);
fullPath = NULL;
}
// If item is a dir, but not '.' or '..', make recursive call.
else
{
if ( (strcmp(dirItem->d_name, ".") != 0) &&
(strcmp(dirItem->d_name, "..") != 0) )
{
// Make full path to subdir, add a final '/'.
int fullPathToSubDirLen = strlen(dirName) +
strlen(dirItem->d_name) + 2;
char* fullPathToSubDir = (char*) malloc(fullPathToSubDirLen);
sprintf(fullPathToSubDir, "%s%s/", dirName, dirItem->d_name);
printf("\nNew Dir: %s", fullPathToSubDir);

// Make recursive call.
total += GetDirectoryTreeSize(fullPathToSubDir);

free(fullPathToSubDir);
fullPathToSubDir = NULL;
}
}
}
closedir(directory);

return total;
}

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

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

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

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

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

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

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

twitter

Tuesday, February 9, 2010

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

0 Comments:

Post a Comment

About Me

Previous Posts