Warning to newbies

[Seebs]

I don't comprehend this. How can it be an excess of care to do something
which makes a program fail to compile on some standard compilers, without
adding functionality or reliability on any compiler distributed since sometime
in the 80s?

This is a usage of "colleague" that seems strange to me. So you
regard everyone who has had something published by the people
who published your book as a colleague, even those you've never
met and know nothing about. "Just sayin'", maybe.

In any event, it rather supports my statement that I don't care about
reputation. If the net result of these arguments is that people conclude
that I must be some sort of twit to have been published by the people who
published the Nilges book, well, then that's what happens. I don't think
that's likely, though. APress has published some really great books and
a few maybe not-so-great. It's really hard to tell in advance which books
are going to work out, and having worked in writing and editing both in
the past, I can say that it's very hard to tell up front whether someone
is actually going to do a good job with a book. Once you've got sunk costs,
it's often preferable to publish a slightly sub-standard book than to just
write them off.

In any event, I still think the idea of trying to "establish chops in C" by
writing something I'd have viewed as a first-semester C exercise to be
ridiculous.

-s

 

[blmblm]

On 2010-02-20, blmblm myrealbox.com <[email protected]> wrote:

[...] You've
made absurd generalizations based on my unnecessary (but not in fact
erroneous, in fact over-cautious) use of malloc.h about "carelessness"
in a case where an extra step (#include malloc.h) was an excess of
care.

How did you decide that the #include for malloc.h was necessary, or
prudent? On the platform(s) I know best, when I want to use a function
from the C library, I consult its man page, which tells me what to
#include (if anything), and for malloc, it tells me stdlib.h. (I'm
genuinely curious here, not sniping for sniping's sake -- I don't
think I've ever done C programming on a Microsoft platform and so
don't know what reference material is readily available.)

I googled "MSDN malloc" and got a first hit of
http://msdn.microsoft.com/en-us/library/6ewkz86d(VS.80).aspx

this tells you use *both* stdlib.h and malloc.h.

Are you sure? I find the wording a bit ambiguous -- seems to me
that it *might* mean "you can find a definition of malloc in both
of these headers, so use either one". But I haven't looked at
other information from the same source; perhaps "and" does mean
what you think it means!

And why did you include MSDN in your search terms? seems like that
would increase the odds of getting a platform-specific solution,
though maybe not.

I suppose that
justifies spinoza's "excess of care" claim. Whenever I've used MS
compilers I've never used malloc.h. For standard functions I usually
google the function name. Not foolproof but I can usually spot
anything bizzarely odd. I usually just want something I can copy-paste
the prototype out of.


google this newsgroup for the word "collegiate"- he uses that in an
odd sense as well

s/collegiate/collegial/ ??

 

[Nick Keighley]

[...] You've
made absurd generalizations based on my unnecessary (but not in fact
erroneous, in fact over-cautious) use of malloc.h about "carelessness"
in a case where an extra step (#include malloc.h) was an excess of
care.
How did you decide that the #include for malloc.h was necessary, or
prudent?  On the platform(s) I know best, when I want to use a function
from the C library, I consult its man page, which tells me what to
#include (if anything), and for malloc, it tells me stdlib.h.  (I'm
genuinely curious here, not sniping for sniping's sake -- I don't
think I've ever done C programming on a Microsoft platform and so
don't know what reference material is readily available.)

I googled "MSDN malloc" and got a first hit of
http://msdn.microsoft.com/en-us/library/6ewkz86d(VS.80).aspx

this tells you use *both* stdlib.h and malloc.h.

Are you sure?  I find the wording a bit ambiguous -- seems to me
that it *might* mean "you can find a definition of malloc in both
of these headers, so use either one".  But I haven't looked at
other information from the same source; perhaps "and" does mean
what you think it means!

And why did you include MSDN in your search terms?  seems like that
would increase the odds of getting a platform-specific solution,
though maybe not.

I wouldn't normally do this for a standard function, but you asked
what reference material was usually available on an MS platform. And
the answer would be "use the help" (which isn't installed where I am
at the moment) or "use MSDN". MS don't usually (to the best of
knowledge) provide platform indenpendent information. And to be fair
there is often platform specific stuff in man pages. MS are lot better
than they used to be but still a bit "but why would you want to
program anything else?".


<snip>

 

[Gus Gassmann]

On 2010-02-20, blmblm myrealbox.com <[email protected]> wrote:

[...] You've
made absurd generalizations based on my unnecessary (but not in fact
erroneous, in fact over-cautious) use of malloc.h about "carelessness"
in a case where an extra step (#include malloc.h) was an excess of
care.
How did you decide that the #include for malloc.h was necessary, or
prudent? On the platform(s) I know best, when I want to use a function
from the C library, I consult its man page, which tells me what to
#include (if anything), and for malloc, it tells me stdlib.h. (I'm
genuinely curious here, not sniping for sniping's sake -- I don't
think I've ever done C programming on a Microsoft platform and so
don't know what reference material is readily available.)

I googled "MSDN malloc" and got a first hit of
http://msdn.microsoft.com/en-us/library/6ewkz86d(VS.80).aspx

this tells you use *both* stdlib.h and malloc.h.

Are you sure? I find the wording a bit ambiguous -- seems to me
that it *might* mean "you can find a definition of malloc in both
of these headers, so use either one". But I haven't looked at
other information from the same source; perhaps "and" does mean
what you think it means!

No, the wording on that site is quite clear; according to MSDN you need
both headers. Also look at the code example they give a little bit below:

// crt_malloc.c
// This program allocates memory with
// malloc, then frees the memory with free.


#include <stdlib.h> // For _MAX_PATH definition
#include <stdio.h>
#include <malloc.h>

etc.

 

[spinoza1111]

I don't comprehend this.  How can it be an excess of care to do something
which makes a program fail to compile on some standard compilers, without
adding functionality or reliability on any compiler distributed since sometime
in the 80s?

It's called doing your job.

In any event, it rather supports my statement that I don't care about
reputation.  If the net result of these arguments is that people conclude
that I must be some sort of twit to have been published by the people who
published the Nilges book, well, then that's what happens.  I don't think
that's likely, though.  APress has published some really great books and
a few maybe not-so-great.  It's really hard to tell in advance which books
are going to work out, and having worked in writing and editing both in
the past, I can say that it's very hard to tell up front whether someone
is actually going to do a good job with a book.  Once you've got sunk costs,
it's often preferable to publish a slightly sub-standard book than to just
write them off.

Apress, in fact, doesn't know whether the book is "substandard" until
the sales figures come in, because they are in business to make money.
My book, at this late date in its lifetime (it was published in 2004)
is 566540 in sales rank and #42 in compilers, whereas your book, which
was published in 2008, is rather low this early, at about 350000.

The market makes the decision, not the opinions of clerks and jerks.
This is because readers can in fact find a book with "errors" (such as
Samuel Johnson's Dictionary, with its famous definition of "oats") so
clear in other regards that the errors are occasions for amusement or
in Herb's case, instruction.

You managed in fact at university to become neither a scientist nor a
humanist, probably because you were worried about your precious little
GPA. As a result, you're nothing more than a clerk whose opinions are
illformed on a striking range of subjects.

In any event, I still think the idea of trying to "establish chops in C" by
writing something I'd have viewed as a first-semester C exercise to be
ridiculous.  

How would you know? As you have said, you have never taken a single
computer science class. Nor have you been able to do the exercise. Nor
do you understand its theoretical issues including overlapping strings
or right to left.

Nor have you established ability in C in any other way. Quite the
opposite:

* You posted one line of code with a serious showstopper bug: I refer
to your "strlen" and its off by one bug

* You posted, for no reason I can discern, a nonsolution to the
problem of replacing %s by a value

Instead, you consistently try to "establish chops" by destroying the
reputations of people with more ability than you, using the psychotic
and barbarian logic that you can somehow get their ability as if by
magic if you destroy their good name.

 

[spinoza1111]

[...] You've
made absurd generalizations based on my unnecessary (but not in fact
erroneous, in fact over-cautious) use of malloc.h about "carelessness"
in a case where an extra step (#include malloc.h) was an excess of
care.

How did you decide that the #include for malloc.h was necessary, or
prudent?  On the platform(s) I know best, when I want to use a function
from the C library, I consult its man page, which tells me what to
#include (if anything), and for malloc, it tells me stdlib.h.  (I'm
genuinely curious here, not sniping for sniping's sake -- I don't
think I've ever done C programming on a Microsoft platform and so
don't know what reference material is readily available.)

I googled "MSDN malloc" and got a first hit ofhttp://msdn.microsoft.com/en-us/library/6ewkz86d(VS.80).aspx

this tells you use *both* stdlib.h and malloc.h. I suppose that
justifies spinoza's "excess of care" claim. Whenever I've used MS
compilers I've never used malloc.h. For standard functions I usually
google the function name. Not foolproof but I can usually spot
anything bizzarely odd. I usually just want something I can copy-paste
the prototype out of.

This is a usage of "colleague" that seems strange to me.  So you
regard everyone who has had something published by the people
who published your book as a colleague, even those you've never
met and know nothing about.  "Just sayin'", maybe.

google this newsgroup for the word "collegiate"- he uses that in an
odd sense as well

I talk like a fag and my shit's retarded in this Idiocracy, I'd wot.

 

[spinoza1111]

[ snip ]

You consistently hold yourself to a lower standard than you hold
others, and a gentleman holds himself to a higher standard. You've
made absurd generalizations based on my unnecessary (but not in fact
erroneous, in fact over-cautious) use of malloc.h about "carelessness"
in a case where an extra step (#include malloc.h) was an excess of
care.

How did you decide that the #include for malloc.h was necessary, or
prudent?  On the platform(s) I know best, when I want to use a function
from the C library, I consult its man page, which tells me what to
#include (if anything), and for malloc, it tells me stdlib.h.  (I'm
genuinely curious here, not sniping for sniping's sake -- I don't
think I've ever done C programming on a Microsoft platform and so
don't know what reference material is readily available.)

[ snip ]

Oh? It seems to me that you and Heathfield are all about "reputation",
especially when it comes to calling Apress colleagues "morons".

This is a usage of "colleague" that seems strange to me.  So you
regard everyone who has had something published by the people
who published your book as a colleague, even those you've never
met and know nothing about.  "Just sayin'", maybe.

Well, yes. In a true profession with social distinction and power,
members act collegially. In computing, because its members have zero
or negative social distinction and no power because of no access to
ownership of the tools of production, they are set against each other
as we see here.

However, the fact that Seebach and I are both Apress authors means
that there's a nonzero probability that we might meet at a conference,
and at this point, if he introduced himself, I'd walk away without
shaking his hand or speaking a word. He's damaged his relations with
others needlessly.

In fact, I am quite a paradox in a world of dulled affect. This is
because it's been noticed where I live that I am friendly and open,
but apt to take offense. This was man's traditional way, which still
obtains in the hills of Afghanistan (where kindness to strangers is
common, mixed with absolute refusal to let the stranger **** with the
tribe), but which doesn't obtain in the corporation, where the
normalized deviance is low-level hostility and self-protective irony
and sarcasm, expressive of anomie and alienation.

[ snip ]

 

[Seebs]

You think it's a C programmer's job to cause a program to fail to
compile? Interesting approach.

Well, ironically, one could argue that it IS my job to create
carefully-crafted programs which fail to compile.

But... and this is the tricky part... they have to be programs which OUGHT
to compile. So the <malloc.h> thing is useless.

I do find it telling that spinoza1111 has no actual explanation for why
a header which doesn't do anything except in cases where it breaks the program
ought to be included. "It's called doing your job" is a content-free
assertion; it's nothing but a reiteration of his claim that this ought to
be done, without any progress towards an explanation of why.

-s

 

[Nick Keighley]

Nick Keighley wrote:

Not at all like the gcc people, then?

We recommend, rather, that users take advantage of the extensions of
GNU C and disregard the limitations of other compilers. Aside from
certain supercomputers and obsolete small machines, there is less
and less reason ever to use any other C compiler other than for
bootstrapping GNU CC.
(Using and Porting GNU CC)

 

[Nick Keighley]

Precisely the quote I had in mind. Perhaps I should have used a bigger
smiley.

I was perfectly aware you being ironic. I just hadn't drunk my
telepathy tea so I didn't know exactly which quote you had in mind

 

[blmblm]

[...] You've
made absurd generalizations based on my unnecessary (but not in fact
erroneous, in fact over-cautious) use of malloc.h about "carelessness"
in a case where an extra step (#include malloc.h) was an excess of
care.
How did you decide that the #include for malloc.h was necessary, or
prudent? On the platform(s) I know best, when I want to use a function
from the C library, I consult its man page, which tells me what to
#include (if anything), and for malloc, it tells me stdlib.h. (I'm
genuinely curious here, not sniping for sniping's sake -- I don't
think I've ever done C programming on a Microsoft platform and so
don't know what reference material is readily available.)
I googled "MSDN malloc" and got a first hit of
http://msdn.microsoft.com/en-us/library/6ewkz86d(VS.80).aspx

this tells you use *both* stdlib.h and malloc.h.

Are you sure? I find the wording a bit ambiguous -- seems to me
that it *might* mean "you can find a definition of malloc in both
of these headers, so use either one". But I haven't looked at
other information from the same source; perhaps "and" does mean
what you think it means!

No, the wording on that site is quite clear; according to MSDN you need
both headers. Also look at the code example they give a little bit below:

The code example does resolve any ambiguity. I should have read
more carefully ....

// crt_malloc.c
// This program allocates memory with
// malloc, then frees the memory with free.


#include <stdlib.h> // For _MAX_PATH definition
#include <stdio.h>
#include <malloc.h>

etc.

And I agree, for the record, with your earlier comment about how
man pages also sometimes contain system-specific stuff, possibly
sometimes without warning you that it's not portable.

Does The Standard say anything about which headers .... A quick
check says that it does, and the one for malloc is stdlib.h?

 

[blmblm]

[ snip ]

I guess you're not planning to answer this question. Oh well.

[ snip ]

Oh? It seems to me that you and Heathfield are all about "reputation",
especially when it comes to calling Apress colleagues "morons".

This is a usage of "colleague" that seems strange to me. So you
regard everyone who has had something published by the people
who published your book as a colleague, even those you've never
met and know nothing about. "Just sayin'", maybe.

Well, yes. In a true profession with social distinction and power,
members act collegially. In computing, because its members have zero
or negative social distinction and no power because of no access to
ownership of the tools of production, they are set against each other
as we see here.

However, the fact that Seebach and I are both Apress authors means
that there's a nonzero probability that we might meet at a conference,
and at this point, if he introduced himself, I'd walk away without
shaking his hand or speaking a word. He's damaged his relations with
others needlessly.

I don't quite get how sharing a publisher makes a real-world
encounter significantly more likely than simply sharing an interest
in computing. But perhaps Apress sponsors events for authors, or
otherwise provides opportunities for them to interact.

[ snip ]

 

[Gus Gassmann]

[...] You've
made absurd generalizations based on my unnecessary (but not in fact
erroneous, in fact over-cautious) use of malloc.h about "carelessness"
in a case where an extra step (#include malloc.h) was an excess of
care.
How did you decide that the #include for malloc.h was necessary, or
prudent? On the platform(s) I know best, when I want to use a function
from the C library, I consult its man page, which tells me what to
#include (if anything), and for malloc, it tells me stdlib.h. (I'm
genuinely curious here, not sniping for sniping's sake -- I don't
think I've ever done C programming on a Microsoft platform and so
don't know what reference material is readily available.)
I googled "MSDN malloc" and got a first hit of
http://msdn.microsoft.com/en-us/library/6ewkz86d(VS.80).aspx

this tells you use *both* stdlib.h and malloc.h.
Are you sure? I find the wording a bit ambiguous -- seems to me
that it *might* mean "you can find a definition of malloc in both
of these headers, so use either one". But I haven't looked at
other information from the same source; perhaps "and" does mean
what you think it means!

No, the wording on that site is quite clear; according to MSDN you need
both headers. Also look at the code example they give a little bit below:

The code example does resolve any ambiguity. I should have read
more carefully ....

// crt_malloc.c
// This program allocates memory with
// malloc, then frees the memory with free.


#include <stdlib.h> // For _MAX_PATH definition
#include <stdio.h>
#include <malloc.h>

etc.

And I agree, for the record, with your earlier comment about how
man pages also sometimes contain system-specific stuff, possibly
sometimes without warning you that it's not portable.

Wasn't me who said that, actually...

 

[Nick Keighley]

[...] You've
made absurd generalizations based on my unnecessary (but not in fact
erroneous, in fact over-cautious) use of malloc.h about "carelessness"
in a case where an extra step (#include malloc.h) was an excess of
care.
How did you decide that the #include for malloc.h was necessary, or
prudent?  On the platform(s) I know best, when I want to use a function
from the C library, I consult its man page, which tells me what to
#include (if anything), and for malloc, it tells me stdlib.h.  (I'm
genuinely curious here, not sniping for sniping's sake -- I don't
think I've ever done C programming on a Microsoft platform and so
don't know what reference material is readily available.)
I googled "MSDN malloc" and got a first hit of
http://msdn.microsoft.com/en-us/library/6ewkz86d(VS.80).aspx

And I agree, for the record, with your earlier comment about how
man pages also sometimes contain system-specific stuff,

that was me actually

possibly
sometimes without warning you that it's not portable.

Does The Standard say anything about which headers ....  A quick
check says that it does, and the one for malloc is stdlib.h?

it says lots about headers... Yes the declaration for malloc() is "in"
stdlib.h. The scare quotes are because standard headers don't actually
have to be files (I suppose none of the source code *has* to be in
files!). The implementation could do something clever such hack the
appropriate definitions directly into its symbol table when it saw

#include <stdlib.h>

 

[Seebs]

Not entirely topical, but this is very odd. Everyone I've talked to about
this issue (which is a large set, including both socialists and capitalists,
and at least one person with a degree in economics), seems to feel that
programmers are unusual in that they are *guaranteed* ownership of the
means of production -- because fundamentally, programming is thought, and
computers are extremely cheap anyway. In short, the workers already control
the means of production in this field. You can't just hire someone else
for most real programming work -- the costs are huge, and for anyone
reasonably good, the cost of finding a competent replacement is excessive,
not to mention that it will take too long.

I don't quite get how sharing a publisher makes a real-world
encounter significantly more likely than simply sharing an interest
in computing. But perhaps Apress sponsors events for authors, or
otherwise provides opportunities for them to interact.

They occasionally ask about author participation in events.

I can live with a world in which one of the Great Usenet Kooks is unwilling
to talk to me.

-s

 

[blmblm]

[ snip ]

You managed in fact at university to become neither a scientist nor a
humanist, probably because you were worried about your precious little
GPA. As a result, you're nothing more than a clerk whose opinions are
illformed on a striking range of subjects.

How could you possibly know whether Seebs was concerned about his GPA?
*You* seem to attach some importance to grades, but nothing he has said
in this discussion suggests to me that he finds them a measure of
anything important. Or the reverse, indeed. Has he said anything
one way or another?

How would you know? As you have said, you have never taken a single
computer science class. Nor have you been able to do the exercise. Nor
do you understand its theoretical issues including overlapping strings
or right to left.

Just because a person has never enrolled in a first-semester CS
class doesn't mean he or she has no awareness of what might be
taught in one.

[ snip ]

 

[blmblm]

[ snip ]

that was me actually

So it was -- apologies to you and Gus. I'd have said that I try
to be careful about such things, but apparently, well, sometimes
mistakes are made.

it says lots about headers... Yes the declaration for malloc() is "in"
stdlib.h. The scare quotes are because standard headers don't actually
have to be files (I suppose none of the source code *has* to be in
files!). The implementation could do something clever such hack the
appropriate definitions directly into its symbol table when it saw

#include <stdlib.h>

I had just this sort of nitpick in mind when I wrote "the one for
malloc is stlib.h" rather than "malloc is in stdlib.h". ?

 

[blmblm]

[ snip ]

They occasionally ask about author participation in events.

I'm not sure what you mean here -- they ask whether you participate
in conferences?

[ snip ]

 

[Seebs]

I'm not sure what you mean here -- they ask whether you participate
in conferences?

They invite us to participate in stuff occasionally. Not especially often,
that I recall.

-s

 

[Richard Bos]

Not entirely topical, but this is very odd. Everyone I've talked to about
this issue (which is a large set, including both socialists and capitalists,
and at least one person with a degree in economics), seems to feel that
programmers are unusual in that they are *guaranteed* ownership of the
means of production -- because fundamentally, programming is thought, and
computers are extremely cheap anyway.

They're right about the situation, wrong about the exclusivity. This is
one of the ways in which programming is an art rather than a science.
You can't replace other artists - e.g., painters, but most appropriately
writers - either. Or, well, you can, if they're hacks; but then, monkey
programmers are interchangable as well.

Richard