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

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

comp.lang.c@googlegroups.com

Today's topics:

==============================================================================
TOPIC: The answer is "All of it." of course.
http://groups.google.com/group/comp.lang.c/t/3a070a9762275cee?hl=en
==============================================================================

== 1 of 2 ==
Date: Sun, Mar 28 2010 12:00 am
From: Phred Phungus

Ray Vickson wrote:
> On Mar 27, 10:46 pm, Phred Phungus <Ph...@example.invalid> wrote:
>> Dr Malcolm McLean wrote:
>>
>> [broadening x-post to sci.math]

>> Hello sci.math. If rand has a flat pdf on the interval [0, 32768], what
>> is the distribution of rand squared?

> If U is uniformly distributed on interval [0,M], then U^2 will be
> distributed on interval [0,M^2]. Find the distribution as follows: for
> any x in (0,M^2) the cumulative distribution of U^2 is F(x) = Pr{U^2
> <= x} = Pr{U <= sqrt(x)}; we don't have negative values of U, so we
> don't consider the interval from -sqrt(x) to 0. Anyway, for uniform U
> on [0,M], Pr{U <= y} = y/M for y in [0,M]. For y = sqrt(x) this gives
> Pr{U^2 <= x} = sqrt(x)/M [note: the right-hand-side = 1 when x = M^2,
> as it should]. Thus, the density function of U^2 is f(x) = dF(x)/dx =
> (1/2)/[M*sqrt(x)].

Ok. So, if one is to verify, then you're gonna heat up the
pseudorandoms and have M^2 bins. If the product of r = rand() and s =
rand() equals q, then bin number q, initially set to zero, increments.

q2) Does anyone have a statistical model for this event being
pseudorandom as opposed to being clunky in the lower bits?
>
> Note: this assumes continuously-distributed uniform U. For an *actual*
> rand, U will be discrete. Furthermore, for a typical congruential
> generator, the value 0 is never attained, and the distribution will be
> slightly non-uniform over the other values 1, 2, ..., 32768.

Thanks so much for your comment and your minor bounds error above like
the one I made. For clarity's sake, I should stipulate that the
interval is closed about zero and a value stipulated by the C
implementation. I'd like to choose this as [0, 32767] because then I
know I won't be in any trouble with M^2.

q3) How different is the analysis when it goes from continuous to discrete?
--
fred

== 2 of 2 ==
Date: Sun, Mar 28 2010 3:21 am
From: Phil Carmody

Phred Phungus <Phred@example.invalid> writes:
> Dr Malcolm McLean wrote:
> [broadening x-post to sci.math]
>
>> On 27 Mar, 13:35, Eric Sosman <esos...@ieee-dot-org.invalid> wrote:
>>> What makes you think that (RAND_MAX + 1) is defined?
>>>
>>> And what makes him think that rand()*rand() has a
>>> binomial distribution, even if it doesn't overflow?
>>
>> I nodded.
>> A web search turns up that there's no neat way of obtaining the
>> probability density function of a the product of several uniformly-
>> distributed random variables.

What's not neat about the continuous case?

>> Basically you have to go to log space
>> and treat is as a sum (which approximates the normal distribution as N
>> increases).

And why do you introduce an N? There is no N.

> I'm reading this in comp.lang.c, and I don't think we have the
> firepower to determine this distribution, hence the crosspost.
>
> Hello sci.math. If rand has a flat pdf on the interval [0, 32768],
> what is the distribution of rand squared?

We're not squaring anything, we're multiplying 2 (purportedly)
independent values.

Phil
--
I find the easiest thing to do is to k/f myself and just troll away
-- David Melville on r.a.s.f1

==============================================================================
TOPIC: Questions about argv
http://groups.google.com/group/comp.lang.c/t/5eb85a70a33b446c?hl=en
==============================================================================

== 1 of 3 ==
Date: Sun, Mar 28 2010 12:47 am
From: Keith Thompson

Michael Tsang <miklcct@gmail.com> writes:
> WD wrote:
>> main(x,y)
>> {
>
> This is illegal. What do you mean?

In C90, that's a legal definition. C90, and even C99, still support
K&R-style function definitions. C90 supports implicit int, which C99
does not. A more explicit verison of the above would be:

int main(x, y)
int x;
int y;
{
...

> You want
>
> int main(int x, char **y)
>
> ?

Yes, there's (almost?) never a good reason to use K&R-style
function definitions. But of course it should be:

int main(int argc, char **argv)

The language doesn't require those names, but they're conventional,
and there's no good reason not to use them.

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

== 2 of 3 ==
Date: Sun, Mar 28 2010 3:03 am
From: pete

Keith Thompson wrote:
>
> Michael Tsang <miklcct@gmail.com> writes:
> > WD wrote:
> >> main(x,y)
> >> {
> >
> > This is illegal. What do you mean?
>
> In C90, that's a legal definition.

No, it isn't. y[x] is not a null pointer.

ISO/IEC 9899: 1990

5.1.2.2.1 Program startup

The function called at program startup is named main.
The implementation declares no prototype for this function.
It can be defined with no parameters:

int main(void) { /*...*/ }

or with two parameters
(referred to here as argc and argv, though any names may be used,
as they are local to the function in which they are declared):

int main(int argc, char *argv[]) { /*...*/ }

If they are defined, the parameters to the main function
shall obey the following constraints:

— The value of argc shall be nonnegative.
— argv[argc] shall be a null pointer.

--
pete

== 3 of 3 ==
Date: Sun, Mar 28 2010 2:25 am
From: Phred Phungus

pete wrote:
> Keith Thompson wrote:
>> Michael Tsang <miklcct@gmail.com> writes:
>>> WD wrote:
>>>> main(x,y)
>>>> {
>>> This is illegal. What do you mean?
>> In C90, that's a legal definition.
>
> No, it isn't. y[x] is not a null pointer.
>
> ISO/IEC 9899: 1990
>
> 5.1.2.2.1 Program startup
>
> The function called at program startup is named main.
> The implementation declares no prototype for this function.
> It can be defined with no parameters:
>
> int main(void) { /*...*/ }
>
> or with two parameters
> (referred to here as argc and argv, though any names may be used,
> as they are local to the function in which they are declared):
>
> int main(int argc, char *argv[]) { /*...*/ }
>
> If they are defined, the parameters to the main function
> shall obey the following constraints:
>
> � The value of argc shall be nonnegative.
> � argv[argc] shall be a null pointer.
>

Pete looks right to me, and if so would be the third time in a month
that Keith went down on the facts.

It seems unusual to me, but maybe he always had Chuck to make an error
first.

I can be wrong as well.
--
fred

==============================================================================
TOPIC: Containers: The iterator object
http://groups.google.com/group/comp.lang.c/t/662f02788cfa0c97?hl=en
==============================================================================

== 1 of 3 ==
Date: Sun, Mar 28 2010 12:51 am
From: jacob navia

ng2010 a écrit :
> jacob navia wrote:
>>. If you disagree with something I write, it is
>> not enough to say "That is false" but you have to explain why you
>> consider it false.
>
> You are obviously wrong on that assertion. _I_ don't have to GIVE you
> anything.
>

(snip)

OK. This is Usenet, you can say whatever you feel like. Personally,
since you do not propose any arguments and just dismiss everything I say
without any arguments I will stop discussing with you.

== 2 of 3 ==
Date: Sun, Mar 28 2010 1:14 am
From: Richard Heathfield

In <4ba9bfc9$0$17874$ba4acef3@reader.news.orange.fr>, jacob navia
wrote:

> ng2010 a écrit :

<snip>

>> It is only false to you, for you don't
> know any better (apparently).
>
> Anybody can say that. If you disagree with something I write, it is
> not enough to say "That is false" but you have to explain why you
> consider it false.

Agreed. Neither is it sufficient to say "That is a lie" (which you
very often do say); you have to explain not only why you consider it
to be untrue but also why you think it is a *deliberate* untruth.

<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

== 3 of 3 ==
Date: Sun, Mar 28 2010 3:14 am
From: Nick Keighley

On 28 Mar, 05:35, "ng2010" <ng2...@att.invalid> wrote:
> jacob navia wrote:
> > ng2010 a écrit :
> >> "jacob navia" <ja...@spamsink.net> wrote in message
> >>news:ho39f3$n55$1@speranza.aioe.org...

> >>> In the last discussion we discussed how to do "GetNext" etc with
> >>> containers.
>
> >>> I think it is important that the user code stays as abstract as
> >>> possible, without getting into the specifics of any container, as Mr
> >>> Becarisse said (if I remember correctly).
>
> >>> Well, this could be done as follows. Please tell me what do you
> >>> think. Thanks
>
> >>> All containers should be able to support the "GetNext" and the
> >>> "GetPrevious" functions.

this seems too prescriptive. A container could allow forward iteration
only.

> >> That, of course, is false. It is only true to you, for you don't
> >> know any better (apparently).
>
> > That, of course, is true. It is only false to you, for you don't know
> > any better (apparently).
>
> > Anybody can say that. If you disagree with something I write, it is
> > not enough to say "That is false" but you have to explain why you
> > consider it false.
>
> You are obviously wrong on that assertion. _I_ don't have to GIVE you
> anything.

and at this point you choose not have a technical debate. bye.

<snip>

==============================================================================
TOPIC: Implementing strstr
http://groups.google.com/group/comp.lang.c/t/a3fe05ab352d5774?hl=en
==============================================================================

== 1 of 5 ==
Date: Sun, Mar 28 2010 12:59 am
From: Keith Thompson

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> Keith Thompson <kst-u@mib.org> writes:
>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
[...]
>>> I should not have brought up gcc because that is too specific. gcc
>>> (at least my current version of gcc) gives _Bool a single value bit
>>> so, since gcc is a conforming implementation, the above just shows
>>> that all the other bit settings in a _Bool are trap representations.
>>> This was pointed out by Keith Thompson in a thread earlier this year.
>>
>> Hmm. I don't remember making that particular point.
>
> I was thinking of this: Message-ID: <lny6jq51ty.fsf@nuthaus.mib.org>

I see, my argument was based on bit fields. I had forgotten about
that.

[...]

>> Note that the existence of padding bits doesn't imply the existence
>> of trap representations. For example, I think any of the following
>> would be a valid implementation;
>>
>> 1. _Bool has 8 bits, of which 1 is a value bit and the other 7 are
>> padding bits.
>>
>> 1a. A representation with any padding bit set to 1 is a trap
>> representation.
>>
>> 1b. Padding bits are ignored; only the single value bit contributes to
>> the value. For example, after using memset to copy the byte
>> values 0x00 and 0xf0 into two _Bool objects, the "==" operator
>> will report that their values are equal.
>>
>> 2. _Bool has 8 bits, all of which are value bits.
>>
>> Case 2 can be treated as 1a depending entirely on the implementation's
>> documentation; it's just a matter of which behavior the implementation
>> chooses to leave undefined.
>
> I am not sure I understand this last remark. Do you mean that no
> conforming program can tell the difference between 2 and 1a? If so, I
> agree, bit I think a programmer can tell the difference in that a
> diagnostic is required for
>
> struct s { _Bool b : 2; };
>
> in the case of 1a.
>
> <snip>

I forgot about bit fields. Yes, that is a difference between cases 1a
and 2. (Well, mostly. Implementations are allowed to produce extra
diagnostics whenever they like, so you can't *really* distinguish the
cases based on that, but you can if you assume that this particular
message is not a lie.)

== 2 of 5 ==
Date: Sun, Mar 28 2010 3:32 am
From: spinoza1111

On Mar 28, 2:10 am, blm...@myrealbox.com <blm...@myrealbox.com> wrote:
> In article <52ae4a94-4361-417c-871d-a72b9fbde...@t17g2000prg.googlegroups.com>,
>
> spinoza1111 <spinoza1...@yahoo.com> wrote:
> > On Mar 20, 1:40 am,spinoza1111<spinoza1...@yahoo.com> wrote:
> > > On Mar 20, 1:27 am, Seebs <usenet-nos...@seebs.net> wrote:
>
> [ snip ]
>
> > > So, once more, asshole. How do you know the assignments in a first
> > > year CS class?
>
> There are any number of ways a person might know the assignments in
> a first-year CS class without ever having taken one. Do I really need
> to list them?
>
> I find it amusing, by the way, that even though Seebs has never
> taken a CS course he on many occasions produces paragraphs that
> I could almost have written myself for inclusion in something to
> be distributed as part of such a course -- the academic party
> line about choosing variable names well, for example, or not
> optimizing before you know you need to. I guess it *could*
> be coincidence ....

It's talking the talk, but he cannot walk the walk. This is evident in
the code he's submitted here: an off by one one line strlen, a string
replace program which didn't work that he was proud of, and in his
queue.c program, case statements falling through to error on non-error
cases.

He is in fact a published writer who writes "clearly" both in the
sense that he admits Schildt writes, and possibly in the sense that he
knows what he's talking about when he writes about scripts.

But he cannot claim to base his claims on programming on other than
tertiary and some secondary sources IF the best writers on programming
are real programmers, like Knuth.

And this is fine, save for his utter dishonesty and uncollegiality.
Which in my mind would make him at best a rather closely supervised
academic gofer in your case. And if you hire him, watch your back.
>
> [ snip ]
>
> --
> B. L. Massingill
> ObDisclaimer: I don't speak for my employers; they return the favor.

== 3 of 5 ==
Date: Sun, Mar 28 2010 3:45 am
From: spinoza1111

On Mar 28, 2:11 am, blm...@myrealbox.com <blm...@myrealbox.com> wrote:
> In article <0.f287701983fb1d46cc58.20100320150607GMT.87634rghi8....@bsb.me.uk>,
> Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
>
> >spinoza1111<spinoza1...@yahoo.com> writes:
> > <snip>
> > > About ten minutes of work produces rel 1.12. This fixes the bug that
> > > Ben noted, where a = was used in place of ==.
>
> > I did not claim that = in place of == was a bug. In fact it is
> > obvious that putting == back introduces more bugs. My point was that
> > you did not know what your code was doing: you reported favourably on
> > a bug fix that could not possibly have any effect. You can't fix (or
> > do pretty much anything with) code you don't understand.
>
> For suitable definitions of "understand", I would claim. At a
> previous place of employment I developed some skill at fixing
> bugs in code I understood just well enough to figure out where it
> was going wrong. Not that I'm claiming that ignorance is good,
> exactly, only that if complete understanding is not feasible,
> it is often useful to be able to proceed from partial understanding.

Indeed, it is often in corporate programming necessary to do this, but
this is, I claim, part of the problem. And in Dweebach's case, it
gives him no standing to criticize Schildt.

Contrary to the mythos, it is possible to "understand" large systems
by way of separation of concerns. But, this full understanding
increases the control of real stakeholders, including low level
employees and customers, vis a vis top management, and in American
business this is a no-no.

Which isn't to say that many top managements "understand" their
systems. In fact, the case of Ken Lay at Enron and in the 2008 crash,
it became clear that the managers, by preventing others from getting
this understanding (and its concomitant control), had also blinded
themselves.

Bell Northern Research at Mountain View responded to Ottawa's layoff
of the SL/1 compiler team by hiring me and saddling me with the
responsibility of not only discovering but actually fixing bugs, as
well as creating new versions and creating a rational installer. I
struggled to understand "everything". But in the management playbook,
I should have whined and nagged for employees to work for me so that
they and I could go to Hooters, since our collective ignorance would
mean that no one person would be "indispensable".

Years later I got the job of making something reasonable out of a DNA
assembly system. I documented everything in sight, got it more or less
working, and when given an assistant installed a regime of extreme
pair programming. But because the former Navy man who'd invented the
system but didn't know software thought I was a homo, I was thanked
effusively and demoted to tech writer while still expected to manage.
I trained my assistant up to the point where he could take over, and
split for China.

Nonetheless, I still prefer end to end creation as opposed to sitting
around some office sending bugs on to Timbuctoo and back-stabbing.

>
> [ snip ]
>
> --
> B. L. Massingill
> ObDisclaimer: I don't speak for my employers; they return the favor.

== 4 of 5 ==
Date: Sun, Mar 28 2010 3:47 am
From: spinoza1111

On Mar 28, 2:14 am, blm...@myrealbox.com <blm...@myrealbox.com> wrote:
> In article <7ae1b474-9b3e-4513-8f76-72ee1bea4...@v34g2000prm.googlegroups.com>,
>
> spinoza1111 <spinoza1...@yahoo.com> wrote:
> > On Mar 21, 1:00 pm,spinoza1111<spinoza1...@yahoo.com> wrote:
> > > On Mar 21, 9:35 am, Seebs <usenet-nos...@seebs.net> wrote:
>
> [ snip ]
>
>
>
>
>
> > > The following code, from Peter's "pseudo root simulator", is submitted
> > > to this discussion group as evidence that he is incompetent, and is
> > > unethically using this newsgroup to get debugging assistance for code
> > > that he will then claim as his own. And because he is incompetent, he
> > > has defamed Herb Schildt and myself in a legally actionable sense.
>
> > > If I am wrong I will apologize for basing this charge on this evidence
> > > but will not withdraw the charge, since other evidence exists. I am
> > > the best programmer in this newsgroup, but by no means the best C
> > > programmer, so I may have missed something.
>
> > > Sources: the thread starts athttp://groups.google.com.hk/group/comp.lang.c/msg/54dfb34c84373f26?hl=en
> > > ("A hunk of not-very-portable code I've written"). This post
> > > references code in github athttp://github.com/wrpseudo/pseudo/blob/master/pseudo.c
> > > line 664 at this moment in time.
>
> > > int
> > > pseudo_server_response(pseudo_msg_t *msg, const char *tag) {
> > > switch (msg->type) {
> > > case PSEUDO_MSG_PING:
> > > msg->result = RESULT_SUCCEED;
> > > if (opt_l)
> > > pdb_log_msg(SEVERITY_INFO, msg, tag, "ping");
> > > return 0;
> > > break;
> > > case PSEUDO_MSG_OP:
> > > return pseudo_op(msg, tag);
> > > break;
> > > case PSEUDO_MSG_ACK:
> > > case PSEUDO_MSG_NAK:
> > > default:
> > > pdb_log_msg(SEVERITY_WARN, msg, tag, "invalid message");
> > > return 1;
> > > }
>
> > > }
>
> [ snip ]
>
>
>
>
>
> > In this particular case, it is possible that Seebach never got around
> > to deciding and coding what ack and nak should do. A nak sounds like
> > an error in which you should wait until a maximum. But I do not
> > understand how an ack could be an error. "hey, I'm here! Fuck you,
> > you're an error! Mom!"
>
> > I am waiting for him to lie about this situation.
>
> > Furthermore, there is a command processor switch statement directly
> > above the code I'm discussing: it seems to want to process pseudo root
> > commands. Many commands seem "stubbed", yet strangely, not with a
> > break to get out of the switch statement. As a result, a mkdir will do
> > a mknod.
>
> > [Parenthetically, one wonders what a pseudo root is for. OK, you want
> > to make directories and stuff without bothering Linux or being in
> > protected mode? Or maybe you are a programmer only in virtual reality
> > and you like simulating what the big boys do? Hell, I love writing
> > simulators myself. But isn't Linux really, really good at making
> > directories in reality? Are we reinventing the wheel? Don't get me
> > wrong, I might be The Greatest Programmer in the World but I know dick
> > about Linux.]
>
> > The code, which is too large to include, starts at line 456 at
> >http://github.com/wrpseudo/pseudo/blob/master/pseudo.c.
>
> > I do not understand why the operations he has supported at this time
> > have a break but the unsupported operations do not. The apparent error
> > is consistent, and Peter has told us that he gets trivial matters
> > wrong.
>
> > However, programming isn't high level conceptual handwaving. When I
> > wrote the compiler for "Build Your Own .Net Language and Compiler" I
> > wrote all 26K lines by myself. Real programmers don't like
> > collaboration save for pair programming.
>
> > I believe that if I'd submitted this code, Peter would have been on me
> > like a fly on shit, claiming that I am both incompetent and insane,
> > once others noticed the error. I believe he's no better than somebody
> > coming here for homework completion, and possibly worse.
>
> > Here's another troubling error, in the function containing the
> > troubling case statements. A "pseudo_msg_t" named db_header is
> > declared with no initialization, and then assigned using this code:
>
> > if (found_ino && (prefer_ino || !found_path)) {
> > db_header = by_ino;
> > } else if (found_path) {
> > db_header = by_path;
> > }
>
> > Hmm...if you have found an ino and you prefer it, or if no path was
> > found, then you set db_header to by_ino. Otherwise if you have a path
> > you use that.
>
> > [Oh shit, I hope I know how else and if and stuff work. Yup I think
> > that the above if has sprung a leak.]
>
> > OK, perhaps this is an error which "can't happen". However, competent
> > programmers handle many (but not all) things which can't happen. I
> > worry in strstr about a null target. I don't worry AT THIS TIME (after
> > two hours work) about a target or a master that is NULL.
>
> > But...Peter says this code has been worked on by him for two months.
> > It is to me unwise to not put in error checking early so as to "eat
> > your own dog food" when errors occur.
>
> > Nope, I think the code is globally incompetent and was brought here to
> > be beat into shape by slaves for whom Peter, and Wind River Systems,
> > have naught but contempt, as indicated by his treatment of dissident,
> > uppity slaves like me.
>
> I'm quoting this because while I haven't read it all carefully some
> of it sounds like possibly-legitimate critique, and I'm curious about
> what Seebs has to say about it. (I'm guessing that he's still not
> reading your posts directly.)
>
> > Is this what Open Source has come to?
>
> > I would have given db_header an initial null value.
>
> Ah, but would you? The bug I found in your code -- wasn't that
> a matter of not always assigning an initial value to a variable?
> Just sayin'.

Commodity fetishism generates this type of thinking. Yes, I've
forgotten to initialize variables...but after two months work? Not
hardly.

Don't presume to classify me with Dweebach. I am not a gadget.
>
>
>
>
>
> > OK, is this
> > attention disorder in action, which conceals A Heartbreaking Work of
> > Staggering Genius? Is this the first pseudo root thingie ever written
> > for linux, and did many a man try and fail to solve this problem?
>
> > Oh, here is a switch statement at line 88. It uses GNU getopt with a
> > smartass remark to the effect that GNU did it wrong; Peter, at an
> > early age, seems to have regarded himself as a Superior and Gifted
> > person who Just Knew that you study calculus before trig, and that you
> > don't have to take computer science to be a Genius Programmer. Perhaps
> > big hairy guys that rode motorcycles and looked like Schildt made fun
> > of him and give him noogies and swirlies.
>
> > OK, all cases have a break and all do something. Cool.
>
> > Oh crumbs, no default handler, with an error message, perhaps snarkily
> > blaming the error on GNU.
>
> > Two months work? Wow.
>
> --
> B. L. Massingill
> ObDisclaimer: I don't speak for my employers; they return the favor.

== 5 of 5 ==
Date: Sun, Mar 28 2010 3:49 am
From: spinoza1111

On Mar 28, 4:52 am, Seebs <usenet-nos...@seebs.net> wrote:
> On 2010-03-27, blmblm myrealbox.com <blm...@myrealbox.com> wrote:
>
> > In article <52ae4a94-4361-417c-871d-a72b9fbde...@t17g2000prg.googlegroups.com>,
> >spinoza1111 <spinoza1...@yahoo.com> wrote:
> >> > So, once more, asshole. How do you know the assignments in a first
> >> > year CS class?
>
> (Thanks for quoting this, I never see his garbage except when quoted.)
>
> > There are any number of ways a person might know the assignments in
> > a first-year CS class without ever having taken one. Do I really need
> > to list them?
>
> The most obvious: Most of my college friends did CS. I used to kibitz
> and offer advice. Furthermore, having read a number of books on C,
> including their exercises, I have the luxury of knowing what kinds of
> exercises they contain.

Yes, but did you do them? On time?

>
> Basically, if I were teaching people who had about the cognitive skills
> and study abilities I'd expect from first-year college students C, I'd
> have expected them to be able to do something like that well before the
> end of the first semester, and if a substantial fraction couldn't, I'd
> think it reflected badly on me as an instructor.

Actually, even exercises in CS classes tend on the whole to be more
challenging than Korporate Kode.

>
> > I find it amusing, by the way, that even though Seebs has never
> > taken a CS course he on many occasions produces paragraphs that
> > I could almost have written myself for inclusion in something to
> > be distributed as part of such a course -- the academic party
> > line about choosing variable names well, for example, or not
> > optimizing before you know you need to. I guess it *could*
> > be coincidence ....
>
> Most of it's honestly pretty obvious if you do any programming and
> think about it -- or if you read a lot of books on the topic of
> software design and development. Reading things like _The Practice
> of Programming_, or the _Programming on Purpose_ series, will do a
> lot towards covering the material that would otherwise have been
> scattered in among the basic language syntax.
>
> Also, I have to say, several friends have gone far above and beyond
> in teaching me about programming (hi Mike!), to say nothing of the
> excellent advice and handholding I got from comp.lang.c regulars back
> in the late 80s and early 90s. I think it's safe to say that people like
> Chris Torek and Steve Summit did a lot to teach me about effective use
> of C.

...in a world without grownups...like Peter Pan.

>
> As to whether it's worked... I have published my latest project, and
> I continue to push updates to the public git tree before running them
> through the internal code review process, in the interests of leaving
> a public record.

It seems to me that you over-rely on others to fix your bugs and then
take the credit, based on queue.c.

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

==============================================================================
TOPIC: Is it good to use char instead of int to save memory?
http://groups.google.com/group/comp.lang.c/t/40bfc7048b74630b?hl=en
==============================================================================

== 1 of 1 ==
Date: Sun, Mar 28 2010 1:10 am
From: Dr Malcolm McLean

On 28 Mar, 00:43, James Harris <james.harri...@googlemail.com> wrote:
> On 18 Mar, 17:40, spinoza1111 <spinoza1...@yahoo.com> wrote:
>
>
> > Malcolm seems to be referring to the lack of zero in Roman arithmetic.
> > The Romans
> ...
> > are the reason the nineteenth century starts with 1800 and not 1900, I
> > believe.
>
> A nitpick but since you brought up the absence of zero it is ironic
> that you started the nineteenth century in 1800. Strictly speaking it
> probably started in 1801. (Zero was as absent from the span of years
> as it was from Roman numerals!)
>
Absoutely.
My cousin refused to have anything to do with the 2000 millenium
celbrations, and waited until 2001.

Apparently the Greeks also refused to recognise 1 as "a number". All
mathematical proofs had to be done for the case of unity, and for the
case of numbers. So we have an interesting trend here. Extrapolating,
we'll soon have languages with -1-based arrays.

==============================================================================
TOPIC: nothing much
http://groups.google.com/group/comp.lang.c/t/3040e7c069dc5b93?hl=en
==============================================================================

== 1 of 3 ==
Date: Sun, Mar 28 2010 1:08 am
From: Keith Thompson

Phred Phungus <Phred@example.invalid> writes:
> Seebs wrote:
>> On 2010-03-23, Phred Phungus <Phred@example.invalid> wrote:
>>> 1 implementation-defined behavior
>>> unspecified behavior where each implementation documents how the
>>> choice is made. EXAMPLE An example of implementation-defined
>>> behavior is the propagation of the high-order bit when a signed
>>> integer is shifted right.
>>
>>> So, if an implementation *doesn't* document how propagation occurs
>>> in the above example, is the behavior just unspecified or does it
>>> get bumped to undefined, as non-entities are?
>>
>> Neither. In that case, the implementation is broken, and does not conform
>> to the standard.
>
> Broken? How about imperfect?

The standard distinguishes between conforming and non-conforming
implementations. It doesn't distinguish between slightly
non-conforming (imperfect) and badly non-conforming (broken)
implementations.

Of course, you're free to make such a distinction if you like. Seebs
apparently chooses not to do so.

== 2 of 3 ==
Date: Sun, Mar 28 2010 1:38 am
From: Phred Phungus

Keith Thompson wrote:

> The standard distinguishes between conforming and non-conforming
> implementations. It doesn't distinguish between slightly
> non-conforming (imperfect) and badly non-conforming (broken)
> implementations.

Ok. That was the lesser of the outstanding questions. The other goes
to the contemporary ISO requirement. If it was annexed in '89, then
there is a well-trodden path to what a conforming-implementation *must*
document.

Right?
--
fred

== 3 of 3 ==
Date: Sun, Mar 28 2010 2:58 am
From: Nick Keighley

On 28 Mar, 05:00, Phred Phungus <Ph...@example.invalid> wrote:
> Nick Keighley wrote:
> > On 24 Mar, 00:49, Keith Thompson <ks...@mib.org> wrote:
> > I'm not sure what you mean. Section F.3 of the 1989 ANSI Standard (the
> > ISO Standard numbers things slightly differently) lists the
> > implementaion defined behaviours. There are about 14 sub-sections
> > covering everything from identifier length to the behaviour of the
> > register directive to various twisty corners of the library.
>
> >>>> See Section 3.4.1.
> >>> 3.4.1
> >>> 1 implementation-defined behavior
> >>> unspecified behavior where each implementation documents how the
> >>> choice is made. EXAMPLE An example of implementation-defined behavior
> >>> is the propagation of the high-order bit when a signed integer is
> >>> shifted right.
> >>> So, if an implementation *doesn't* document how propagation occurs in
> >>> the above example, is the behavior just unspecified or does it get
> >>> bumped to undefined, as non-entities are?
> >> If an implementation doesn't document the behavior in a case
> >> where the standard requires it to do so, then the implementation
> >> is non-conforming, and the standard has nothing to say about it
> >> other than that it's non-conforming.
>
> > shoot. So when we asked our compiler supplier to send us the
> > documentaion and he sent us the ANSI stanbdard instead we didn't have
> > a conforming implementaion! On the other hand I still have a copy of
> > the ANSI Standard...
>
> >> In practice, of course, people aren't typically going to reject an
> >> implementation entirely just because some particular feature isn't
> >> properly documented. The point is that the standard doesn't specify
> >> a fallback position for implementations that fail to conform to it.
>
> Ok, so is there a list of what a contemporary ISO implementation must
> document?

http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf

that's C99 plus technical corrigenda (sp?). So that makes it C05 or
something

==============================================================================
TOPIC: MACRO help
http://groups.google.com/group/comp.lang.c/t/e4782f8fe8934348?hl=en
==============================================================================

== 1 of 1 ==
Date: Sun, Mar 28 2010 1:34 am
From: Michael Tsang

new wrote:

>
> 1.c
> -----------------------------
> #include<stdio.h>
>
> #define PRINT(x) printf("x = %d\n",x)
>
> int main()
> {
> int i =9, j=2;
> PRINT(i);
> PRINT(j);
> return 0;
> }
> -------------------------------
> The output will be :
> x = 9
> x = 2
>
> But what if I want to get the output as below:
> i = 9
> j = 2
>

#define PRINT(x) printf(#x " = %d\n", x)

==============================================================================
TOPIC: 16:32 far pointers in OpenWatcom C/C++
http://groups.google.com/group/comp.lang.c/t/4728dadef590aafe?hl=en
==============================================================================

== 1 of 2 ==
Date: Sun, Mar 28 2010 3:04 am
From: Phil Carmody

Branimir Maksimovic <bmaxa@hotmail.com> writes:
> Keith Thompson <kst-u@mib.org> wrote:
>> A pointer object's stored value may be copied to an array of unsigned
>> char, scrambled, unscrambled, and then stored back in the same or
>> another pointer object; this must not change its value.
>
> Clever. As I remember computer memory lesson, least addressable unit
> is byte which has to be wide enough to encode character
> set or something like that. char>=byte is that correct?
> Since there are machines with char == 32 bits, and actually
> char == byte

The way the C standard uses the words, in terms of sizes at least,
char == byte (FSVO '=='). Fortunately it also defines the terms it
uses. (I would say that in terms of semantics, byte is part 'char',
part 'unsigned char', depending on which particular property is being
emphasized, but it's a bit of a mistake to try to apply C semantics
to 'byte', as byte is supposed to be the abstraction of the machine.)

Phil
--
I find the easiest thing to do is to k/f myself and just troll away
-- David Melville on r.a.s.f1

== 2 of 2 ==
Date: Sun, Mar 28 2010 3:47 am
From: "io_x"

"Jonathan de Boyne Pollard" <J.deBoynePollard-newsgroups@NTLWorld.COM> ha
scritto nel messaggio
news:IU.D20100327.T052544.P2443.Q0@J.de.Boyne.Pollard.localhost...
> >
>>>
>>> The thing is, you can laugh yourself silly now. Henry Spencer gave "All the
>>> world's a 386." as a heresy equivalent to "All the world's a VAX.". The
>>> people who argue that the whole planet is flat, because their platform of
>>> choice gives them a tiny/flat memory model, are forgetting that the very
>>> processor architecture that they are using is one of the
>>> reasons that the C and C++ languages are careful not to provide such
>>> sweeping conversion (and other) semantics for pointers in the first place.
>>>
>> Maybe one of the reasons, but machines like the PDP-10 are another. [...
>> discussion of pointers to 9-bit char on PDP-10 ...]
>>
> Which is why I didn't say "the reason". (-: It's worth thinking about
> whether there now exist many mainstream processor architectures that provide
> flat addressing where instruction set addresses are the same width as, or
> narrower than, the general-purpose data registers, and whether processor
> architectures that are even close to the I=L=P model are not overwhelmingly in
> the minority. It's true for IA64 that IS addresses are the same width as data
> registers (GR0 and IP being both 64 bits wide). It's also true for the 68xx
> and the 680x0 architectures, that M. Flass was lamenting, earlier, to be
> rarities these days, and no longer really part of the personal computer
> market. It's certainly not the case for the x86 architecture (48-bit CS:EIP
> being wider than 32-bit EAX).

is it possible to use 48-bit CS:EAX for point one big array
of len=3FFF_FFFF_FFFF in one program?

something like

.0:
mov bl, CS:eax
inc eax
jnc .1
inc CS
.1: push ebx
call f
etc etc

>It's not the case for AS/400s, where SLS pointers are 128 bits and Teraspace
>pointers are 64 bits, and hence the choices are 4-4-16 (ILP) and 4-4-8.
>

==============================================================================
TOPIC: How should I test for a null pointer?
http://groups.google.com/group/comp.lang.c/t/ac6fdf22358cde1a?hl=en
==============================================================================

== 1 of 2 ==
Date: Sun, Mar 28 2010 3:22 am
From: Nick Keighley

On 26 Mar, 00:21, Nobody <nob...@nowhere.com> wrote:
> On Mon, 22 Mar 2010 07:41:25 -0700, Nick Keighley wrote:

> >> >!ptr is the same as (ptr != 0), and the 0 would be converted to a null
> >> >pointer.
>
> >> Of course you meant ptr == 0.
>
> >> >In short, no matter what pattern of bits in memory represents a "null
> >> >pointer", it compares equal to zero, and is thus "false".
>
> > which is why I don't use the !ptr form, I find it too error prone...
>
> Odd; That's why I don't use ptr==0 or ptr!=0.
>
> "!=0" is a postfix no-op,

a rather bizzre way of looking at things. It looks like an infix
inequality operator to me...

> while "==0" is a postfix negation.

if you want to think that way go ahead. But it looks nothing like a
"negation" operator to me. And what does it mean to "negate" a
pointer?

> But (as
> Seebs demonstrated) it's very easy to confuse the two.

but we seem todisagree about what confused him...

> If I want to invert "x", I'll write "!x"; if I want "x" without any
> inversion, I'll just write "x".

I've never had a nedd to invert a pointer. Flip all the bits?

> If the value being tested was an actual C99 "bool", would you write:
>
> if (x != false)
> and:
> if (x == false)
>
> in preference to:
>
> if (x)
> and:
> if (!x)
>
> ?

no, but we are talking about pointers not bools. I'd use the same
codeif I were writing C89 code with x an int that was logically
boolean. bool is about the only useful addition to C99.

> I wouldn't, and I wouldn't do it for pointers, either.

a pointer is not a bool...

== 2 of 2 ==
Date: Sun, Mar 28 2010 3:23 am
From: Nick Keighley

On 26 Mar, 10:53, Dr Malcolm McLean <malcolm.mcle...@btinternet.com>
wrote:
> On 25 Mar, 17:46, Kenneth Brody <kenbr...@spamcop.net> wrote:> On 3/23/2010 1:40 PM, Eric Sosman wrote:
>
> > > It's said that the best response to a bug report is
> > > "Thank you."
>
> > Assuming, of course, that it's really a bug. As opposed to, say, a report
> > that says something to the effect of "IsLeap(2000) returns true".
>
> Or sometimes the bug report is real, but attended with a lot of abuse.
> This can be dangerous, because people who don't have much experience
> in programming often don't realise that even the best programmers
> continually make "idiotic" errors, like off by one errors in
> calculating a loop or failing to check for a divide by zero.

my favourite bug report
"it doesn't fucking work"

==============================================================================
TOPIC: FT and FFT
http://groups.google.com/group/comp.lang.c/t/b8ebbc43989d24b6?hl=en
==============================================================================

== 1 of 2 ==
Date: Sun, Mar 28 2010 3:25 am
From: Jean-Christophe <5.d@free.fr>

Hi all,

I'm writing a frequency analyzer so I implemented
a Fourier Transform and it's working pretty well.
Now I need to speed-up the computing of the FT :
that would be great if someone could post
here a comprehensive routine for the FFT.

TIA

Note : the following code is not otimized, it's just
here to show the clarity of the Fourier Transform.
//------------------------------------------------------------
// time = time buffer input
// freq = frequency buffer output
// size = buffer size
//------------------------------------------------------------
void FT( double *time, double *freq, unsigned int size )
{
const double dpi = 6.283185307179586476925286766559;
double phi, real, imag; // angle, real and imaginary part
unsigned int f, t; // buffer indexes

for( f=0; f < size; ++f ) // frequency index
{
real = imag = 0.0; // reset cumulative values

for( t=0; t < size; ++t ) // time index
{
phi = dpi * (double)(f) * (double)(t) / (double)(size); // angle
real += time[t] * cos(phi); // real part
imag += time[t] * sin(phi); // imaginary part
}

freq[f] = pow((real*real)+(imag*imag),0.5) / (double)(size); //
amplitude
}
}
//------------------------------------------------------------

== 2 of 2 ==
Date: Sun, Mar 28 2010 3:46 am
From: Glenn

Jean-Christophe wrote:
> Hi all,
>
> I'm writing a frequency analyzer so I implemented
> a Fourier Transform and it's working pretty well.
> Now I need to speed-up the computing of the FT :
> that would be great if someone could post
> here a comprehensive routine for the FFT.
>
> TIA
>
>
>
>
> Note : the following code is not otimized, it's just
> here to show the clarity of the Fourier Transform.
> //------------------------------------------------------------
> // time = time buffer input
> // freq = frequency buffer output
> // size = buffer size
> //------------------------------------------------------------
> void FT( double *time, double *freq, unsigned int size )
> {
> const double dpi = 6.283185307179586476925286766559;
> double phi, real, imag; // angle, real and imaginary part
> unsigned int f, t; // buffer indexes
>
> for( f=0; f < size; ++f ) // frequency index
> {
> real = imag = 0.0; // reset cumulative values
>
> for( t=0; t < size; ++t ) // time index
> {
> phi = dpi * (double)(f) * (double)(t) / (double)(size); // angle
> real += time[t] * cos(phi); // real part
> imag += time[t] * sin(phi); // imaginary part
> }
>
> freq[f] = pow((real*real)+(imag*imag),0.5) / (double)(size); //
> amplitude
> }
> }
> //------------------------------------------------------------

Hi Jean-Christophe

Look in the code of a library:

http://www.google.dk/search?q=fft+c%2B%2B+library
http://www.google.dk/search?q=fft+c+library

http://www.fftw.org/

May 10, 2007, A Simple and Efficient FFT Implementation in C++, Part I:
http://www.drdobbs.com/embedded-systems/199500857

http://www.mathtools.net/C_C__/FFT/index.html

Glenn

==============================================================================
TOPIC: Letter sent to Apress with concerns about Peter Seebach's online
behavior
http://groups.google.com/group/comp.lang.c/t/482b38643777da3c?hl=en
==============================================================================

== 1 of 1 ==
Date: Sun, Mar 28 2010 3:36 am
From: Nick Keighley

On 27 Mar, 22:28, Seebs <usenet-nos...@seebs.net> wrote:
> On 2010-03-27, Dr Malcolm McLean <malcolm.mcle...@btinternet.com> wrote:

> > Though it's surprising how seldom people will admit that a book they
> > disagree with is well-written.
>
> This is not surprising, IMHO.
>
> For one thing, most of the time, people have a strong cognitive bias
> against something they disagree with -- for that matter, badly-written
> books may inspire disagreement. For another, many people are uncomfortable
> granting any positive traits to something they dislike, because it creates
> an ambiguity which may be stressful.

I try to train myself out of cognitive dissonance. I read newspapers I
disagree with and I'm quite happy to say editorials are well writen
but wrong. In political debates I listen to I'm willing to conceed
that someone spoke well even if I disagree. I dislike people I
disagree with being shouted down. I *want* to hear them. With books
it's harder, I dislike too many cartoons, big margins and cute icons
in technical books even if their content is reasonable.

We should all listen to religious, political and technical opinions we
disagree with. People you disagree with aren't always stupid or insane
or even poor writers.

> I finally accepted that life was full of boundary cases, and I'm much happier
> now.

shades of grey

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

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

Sunday, March 28, 2010

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

0 Comments:

Post a Comment

About Me

Previous Posts