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

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

comp.lang.c@googlegroups.com

Today's topics:

* Is allocating large objects on the stack a good practice? - 2 messages, 2
authors
http://groups.google.com/group/comp.lang.c/t/ce22843b03b7665b?hl=en
* posting to comp.lang.c - 3 messages, 3 authors
http://groups.google.com/group/comp.lang.c/t/65d5493aa70b6031?hl=en
* Container library (continued) - 4 messages, 3 authors
http://groups.google.com/group/comp.lang.c/t/3763649cc890efcc?hl=en
* Has thought been given given to a cleaned up C? Possibly called C+. - 7
messages, 5 authors
http://groups.google.com/group/comp.lang.c/t/5954dc70a43f9f8e?hl=en
* ☂☂☂ 2010 Cheap price wholesale LV handbag and purse at WEBSITE: http://www.
rijing-trade.com 【paypal payment】 - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/c4cfa0f1b12bfbda?hl=en
* Idiotic programming style edicts - 4 messages, 3 authors
http://groups.google.com/group/comp.lang.c/t/99bc3aa427fc7518?hl=en
* Casting jmp_buf to void * - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/a9e559468513ce12?hl=en
* Letter sent to Apress with concerns about Peter Seebach's online behavior -
1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/482b38643777da3c?hl=en
* Efficency and the standard library - 2 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/ad9fea19f2f7dd61?hl=en

==============================================================================
TOPIC: Is allocating large objects on the stack a good practice?
http://groups.google.com/group/comp.lang.c/t/ce22843b03b7665b?hl=en
==============================================================================

== 1 of 2 ==
Date: Wed, Mar 17 2010 7:19 am
From: Nobody

On Tue, 16 Mar 2010 21:57:42 +0800, Michael Tsang wrote:

> Will it cause any trouble. I know that, writing code that does not leak is
> VERY difficult in C. (In C++, the objects allocates memory only in the
> constructor and deallocates memory only in the destructor so the problem is
> not so serious). Stack allocations (especially C99 VLAs) free the
> programmers ever from mallocking memory manually so it seems to be a good
> idea. Also, I like setting the stack size to unlimited to prevent stack
> overflow ever from happening. Is all these a good idea?

It's possible to write C code which doesn't leak. And in the cases where
you could use a stack-based array (i.e. where you only need the memory
for the duration of the function), it isn't very difficult to avoid leaks.

Where avoiding leaks is hard is where you return pointers to dynamically
allocated memory and then have to keep track of whether or not it's being
used. But you can't use a stack-based array in that situation anyhow.

The main reason to use the stack is performance: fixed-sized arrays are
allocated for free along with the rest of the stack frame, while alloca()
(or a C99 VLA) may end up as a single instruction.

If you're doing e.g. simple processing on small-ish strings, allocating a
buffer with malloc() may take more time than the actual algorithm. OTOH,
if the array is large or the processing is complex, the time taken by
malloc() and free() is likely to be negligible.

== 2 of 2 ==
Date: Wed, Mar 17 2010 8:21 am
From: lacos@ludens.elte.hu (Ersek, Laszlo)

In article <d7633dca-629f-4d1f-bff6-b769e46a8a1a@z11g2000yqz.googlegroups.com>, Nick Keighley <nick_keighley_nospam@hotmail.com> writes:
> On 16 Mar, 15:31, la...@ludens.elte.hu (Ersek, Laszlo) wrote:
>
>> Additionally,
>> res_construct() can participate in an even-higher level _init() routine.
>
> isn't _init() in a reserved namespace? Or close to one anyway.

None that I would know of. (I meant XXX_init(), for some resource type
called "struct XXX" -- I didn't mean "_init" verbatim, without any
non-empty prefix. Sorry for being vague.)

lacos

==============================================================================
TOPIC: posting to comp.lang.c
http://groups.google.com/group/comp.lang.c/t/65d5493aa70b6031?hl=en
==============================================================================

== 1 of 3 ==
Date: Wed, Mar 17 2010 7:33 am
From: Colonel Harlan Sanders

On Wed, 17 Mar 2010 07:17:09 -0700 (PDT), Pete <ptkrisada@gmail.com>
wrote:

>I'm using FreeBSD not MS Windows. I can install slrn from FreeBSD
>ports. :-)

That would have been useful to know earlier.

I can recommend tin as a Unix text mode news client.

== 2 of 3 ==
Date: Wed, Mar 17 2010 7:59 am
From: Andrew Poelstra

On 2010-03-17, Pete <ptkrisada@gmail.com> wrote:
>
> Normally, I work with Unix console without GUI.
> I occasionally use opera only when I need GUI.
> Anyway, I would probably use opera as your suggestion. :-)
>

If you've got a Unix console, use slrn. It's far nicer than
any GUI appliance you might find.

--
Andrew Poelstra
http://www.wpsoftware.net/andrew

== 3 of 3 ==
Date: Wed, Mar 17 2010 8:40 am
From: Seebs

On 2010-03-17, ptkrisada@gmail.com <ptkrisada@gmail.com> wrote:
> Thank you very much for your response.
> But http://groups.google.com/support/bin/answer.py?hl=en&answer=46242
> says ...

Stuff that is true only for actual google groups, not for the Usenet
newsgroups they present as though they were google groups.

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

==============================================================================
TOPIC: Container library (continued)
http://groups.google.com/group/comp.lang.c/t/3763649cc890efcc?hl=en
==============================================================================

== 1 of 4 ==
Date: Wed, Mar 17 2010 7:50 am
From: Andrew Poelstra

On 2010-03-17, jacob navia <jacob@nospam.org> wrote:
> Andrew Poelstra a écrit :
>>
>> The reason I don't like the first option is that is restricts extensibility.
>> If I used your libraries, but decided I didn't like your hash table (IME
>> hash tables have the most to gain by /not/ being generalized) I would be in
>> the position of handing one allocator to my hash table, and one allocator
>> to all N of your classes.
>>
>
> Mmm this is a good point. I did not think about that.
>
> Obviously, the solution is (if we retain a single global object) that each class contains a pointer
> to a specific allocator for the class. If that pointer is NULL (default situation), we use the
> global object. If it is not NULL, it is assumed that it points to a similar table of functions
> (malloc/free/realloc) that the user has set up for this class.
>
> Within this schema, it is still easy to change the global behavior of all objects, but subclasssing
> with a custom allocator is still easy and is NOT affected by any changes in the global behavior.
>
> Thanks for your contribution.
> jacob

I like this (and Nick suggested it as well downthread). Malcolm
suggested having separate constructors for people who want their
own memory management. The regular constructor would just use
malloc().

--
Andrew Poelstra
http://www.wpsoftware.net/andrew

== 2 of 4 ==
Date: Wed, Mar 17 2010 8:36 am
From: Seebs

On 2010-03-17, jacob navia <jacob@nospam.org> wrote:
> You misunderstand. I am not trying to invent a new way of doing
>those things. I am trying to invent a generalized standard way
>of doing that in C. This has never been done before for C.

It's been done repeatedly, except for the "standard" part.

I honestly don't think that generalizing to "container" is going to be
useful in C. In a language that doesn't have meaningful inheritance,
it's very unusual for this kind of approach to get widespread adoption.
I think you'd do better to make a list library and a hash library,
for instance.

== 3 of 4 ==
Date: Wed, Mar 17 2010 9:33 am
From: jacob navia

Seebs a �crit :
> On 2010-03-17, jacob navia <jacob@nospam.org> wrote:
>> You misunderstand. I am not trying to invent a new way of doing
>> those things. I am trying to invent a generalized standard way
>> of doing that in C. This has never been done before for C.
>
> It's been done repeatedly, except for the "standard" part.
>
> I honestly don't think that generalizing to "container" is going to be
> useful in C. In a language that doesn't have meaningful inheritance,
> it's very unusual for this kind of approach to get widespread adoption.

I do not know of any other attempt in C.

Inheritance is not necessary at all. The code works without it.

== 4 of 4 ==
Date: Wed, Mar 17 2010 9:50 am
From: Seebs

On 2010-03-17, jacob navia <jacob@spamsink.net> wrote:
> Seebs a �crit :
>> I honestly don't think that generalizing to "container" is going to be
>> useful in C. In a language that doesn't have meaningful inheritance,
>> it's very unusual for this kind of approach to get widespread adoption.

> I do not know of any other attempt in C.

I don't know of another generalization to container in C. I know of
many lists and vectors and the like.

> Inheritance is not necessary at all. The code works without it.

But without inheritance, "container" is not a useful level of abstraction.

The thing that makes "container" useful is that it provides for commonality
between "list" and "hash". But that's only useful when list and hash are
the types you actually work with, but because of inheritance, you can treat
them both as containers.

Without inheritance, either you have to call things "container" regardless
of which they are, and thus have access to an API that only makes sense for
a list when you're using a hash, and an API that only makes sense for a hash
when you're using a list, or you lose the ability to write a function which
just takes a "container".

I have often used list libraries. I'd use hash libraries if I needed a hash.
In neither case would I use a "container" library in C -- it's the wrong
level of abstraction for C, so far as I can tell. I've never in any language
wanted "a container". In OO languages, it's useful that the specific things
I request are also generically "containers". In C, it's not useful, because
I can't do anything with it.

==============================================================================
TOPIC: Has thought been given given to a cleaned up C? Possibly called C+.
http://groups.google.com/group/comp.lang.c/t/5954dc70a43f9f8e?hl=en
==============================================================================

== 1 of 7 ==
Date: Wed, Mar 17 2010 8:08 am
From: "bartc"

"Eric Sosman" <esosman@ieee-dot-org.invalid> wrote in message
news:hnouav$9ie$1@news.eternal-september.org...
> On 3/16/2010 6:22 PM, Bartc wrote:
>>
>> Even considering only systems using CR, CR/LF, or LF, C's text mode can
>> go
>> wrong:

>I have used a real live system
> (I believe the O/S in question is still in use and still supported
> today) on which puts("Hello") produced
>
> '\005' '\000' 'H' 'e' 'l' 'l' 'o' '\000'
>
> If you moved those eight bytes verbatim to a Unix or Windows
> system and tried to read them with a text stream, you'd get junk
> at best.

Which is my point.

> If you read them with a binary stream, you'd get the
> eight bytes -- but then it would be *your* problem to know the
> text-file conventions of the foreign system.

At least now the opportunity is there to fix the file.

> (See the newline?
> No? Too bad: It's there, sort of. See the two NUL's? Yes? Too
> bad: They're not there, sort of.)

I'd need a bigger sample to work out what's happening.

> This whole thing has been explained to you several times, and
> you're still grasping the wrong end of the stick. C's distinction
> between text and binary streams doesn't *create* incompatibilities,
> it gives you a fighting chance to *solve* incompatibilities that
> arise outside C's sphere of influence.

OK, but I think I'll carry on using binary mode, even when using printf()
(was it you who gave me that fix to set stdout to binary? It's still working
fine, thanks.)

(I don't need text mode: I tend to do simple text file i/o a line at a time,
so newline is something to be added at the end of output, and something to
be discarded on input. So I don't even need to know what a newline is except
inside these routines.

And when reading text files entirely into memory, I read as binary, and my
code can cope with any of the common cr,lf or cr,lf terminations (when it
even matters). I'm not even sure I can do this in text mode, because the
file size reported is wrong, for a start.

BTW how do you do random access in text mode?)

--
Bartc

== 2 of 7 ==
Date: Wed, Mar 17 2010 8:37 am
From: Ben Bacarisse

"bartc" <bartc@freeuk.com> writes:
<snip>
> (I don't need text mode: I tend to do simple text file i/o a line at a time,
> so newline is something to be added at the end of output, and something to
> be discarded on input. So I don't even need to know what a newline is except
> inside these routines.

No one is suggesting you must use text streams, but you were
suggesting that they were broken in some way. I think everyone agrees
that the world would be a better place if the distinction between text
and binary mode were not needed, but that is not the world we live in.

> And when reading text files entirely into memory, I read as binary, and my
> code can cope with any of the common cr,lf or cr,lf terminations (when it
> even matters). I'm not even sure I can do this in text mode, because the
> file size reported is wrong, for a start.

How can you tell the difference between a \r that is (or is part of) a
line ending and one that is there in its own right? You have, in
effect, invented your own text mode (built on top of binary streams)
with its own rules about what gets added and what gets stripped out.

> BTW how do you do random access in text mode?)

It depends on what you mean. The answer might be fsetpos and
fgetpos.

--
Ben.

== 3 of 7 ==
Date: Wed, Mar 17 2010 9:15 am
From: Jasen Betts

On 2010-03-16, Andrew Poelstra <apoelstra@localhost.localdomain> wrote:
> On 2010-03-16, Jasen Betts <jasen@xnet.co.nz> wrote:
>>
>> strncpy is not stupid, it's just often misused, fgets is also often
>> misused, should that be aboloshed too.
>>
>
> How is fgets misused?

if you don't check for '\n' at the end of the input, and handle long
lines apropriately...

--- news://freenews.netfront.net/ - complaints: news@netfront.net ---
--
comp.lang.c.moderated - moderation address: clcm@plethora.net -- you must
have an appropriate newsgroups line in your header for your mail to be seen,
or the newsgroup name in square brackets in the subject line. Sorry.

== 4 of 7 ==
Date: Wed, Mar 17 2010 9:16 am
From: James Kuyper

Andrew Poelstra wrote:
> On 2010-03-16, Jasen Betts <jasen@xnet.co.nz> wrote:
>> strncpy is not stupid, it's just often misused, fgets is also often
>> misused, should that be aboloshed too.
>>
>
> How is fgets misused?

I think his point is that ANY function can be misused, by giving it the
wrong arguments, or by writing code around the function call that is
based upon a mistaken concept of how it works, or by using it when you
actually should be using some other function, and that strncpy() has
nothing wrong with it that doesn't fall into one of those categories.

Sure, you can pass a pointer to strncpy() that points at a buffer that
is actually smaller than the length that you pass to strncpy(), but you
can do the same thing with fgets(). You can also pass strncpy() a
pointer to an input source that is insufficiently long, and not
null-terminated, but it's equally true that you can pass an invalid
stream pointer to fgets().

With strncpy(), whether or not it creates a null-terminated string (NTS)
depends upon whether or not it fills the buffer before reading a '\0',
and if you need an NTS you either need to use a different function, or
add code to make sure that it is null terminated. On those rare
occasions when I use strncpy(), despite needing a null-terminated
string, I'll pass it a length 1 byte shorter than the actual length of
the buffer, and make sure that the last character in the buffer is '\0'.

Now, fgets() always null terminates the buffer it fills, but it has a
similar problem: whether or not there's a newline at the end of the
string depends upon whether or not it fills the buffer before reading in
a '\n'; how you should deal with that depends upon whether or not you
want it to have a '\n' at the end. You also have to keep in mind that if
the '\n' is missing, the next "line" that you read in from that stream
will actually be the rest of the same line.
--
comp.lang.c.moderated - moderation address: clcm@plethora.net -- you must
have an appropriate newsgroups line in your header for your mail to be seen,
or the newsgroup name in square brackets in the subject line. Sorry.

== 5 of 7 ==
Date: Wed, Mar 17 2010 9:17 am
From: James Kuyper

Seebs wrote:
...
> In general, strncpy() should never be used unless you're working with
> early UNIX inodes.

Or have some other reason why you need to null-fill an array.

There's a situation that comes up frequently in the programs I'm
responsible for, for which strncpy() seems like exactly the right fit.
Let me describe the relevant constraints:

The program is writing into a fixed-length field in a file; it's not
within my authority to change that fact, nor would I be inclined to so
so if I did have that authority. The source it is writing from is a
string (usually a unix path) that will normally be shorter than that
length, but has, for practical purposes, no upper limit on it's length -
no acceptably small fixed sized could be specified that would be
guaranteed to be long enough. If the source string is too long to fit,
it's not an error serious enough to justify refusing to create the file.
However, getting as much as possible of the source string into the
output file is more important than ensuring that it's null terminated.

Finally, though there's no specific requirement concerning this, I've
found it's easier to perform a binary comparison of two files created by
different runs of the program if the parts of the fixed-length field
after the null termination have fixed contents that will compare equal
in the two files. Those fixed contents don't have to be '\0', but since
strncpy() provides null-filling as part of the package, I don't see any
point is filling them with anything other than '\0'.

What function would you recommend I use to prepare the output buffer for
fwrite(), other than strncpy()?
--
comp.lang.c.moderated - moderation address: clcm@plethora.net -- you must
have an appropriate newsgroups line in your header for your mail to be seen,
or the newsgroup name in square brackets in the subject line. Sorry.

== 6 of 7 ==
Date: Wed, Mar 17 2010 9:17 am
From: James Kuyper

Nick Keighley wrote:
> On 15 Mar, 20:33, Keith Thompson <ks...@mib.org> wrote:
>> Richard Delorme <abu...@nospam.fr> writes:
...
>>> generic containers. To make the language simpler, or cleaner, why not
>>> rather remove things from it.
>> Any such change will break existing code.
>
> well, yes but this is a cleanup and simplification

And the fact that it will break existing code is why simplification of
an existing language by removal of features is generally not a practical
option.

>>> - void can be removed from the language. So instead of declaring
>>> void f(void);
>>> we can simply write :
>>> f();
>> "f();" already has a meaning in C90; it declares f as a function
>> returning int and taking an unspecified but fixed number and type
>> of parameters. �
>
> and what do you need that for? Backward compatibility with K&R C? C++
> seem to manage to drop void in these circumstances without a problem.

C++ was a new language, and backwards compatibility is less of an issue
for a brand new language than it is for a new version of a
well-established language. Despite that fact, Stroustrup compromised his
design somewhat, in many different ways, for the sake of minimizing
backwards incompatibility with C. This just wasn't one of the cases
where he was willing to compromise.

>> C99 dropped implicit int, but "f();" would still
>> be ambiguous at block scope; is it a function declaration or a
>> function call?
>
> without a return type it's a call.

So, with your proposed change to the language, it would not be possible
to declare a void function at block scope?
--
comp.lang.c.moderated - moderation address: clcm@plethora.net -- you must
have an appropriate newsgroups line in your header for your mail to be seen,
or the newsgroup name in square brackets in the subject line. Sorry.

== 7 of 7 ==
Date: Wed, Mar 17 2010 9:18 am
From: Dag-Erling Smørgrav

Richard Delorme <abulmo@nospam.fr> writes:
> - void can be removed from the language. So instead of declaring
> void f(void);
> we can simply write :
> f();
> The generic pointer type (void *), could then be replaced by (char*)
> without much harm.

Vade retro, satana!

> - auto can be removed from the language.

I'd love to see it reused to mean "the type of the expression which you
assign to the variable", except "auto foo = bar" would be legal in both
old-C and new-C but have different semantics.

> - register can be removed from the language.

ACK

> - restrict can be removed. It is mostly here to facilitate some
> optimizations by the compiler by preventing aliases. I think this is
> not the duty of the programmer to facilitate optimization, but rather
> the burden of the compiler.

It allows the programmer to provide information to the compiler which
the compiler can not obtain in any other way.

> Obviously the standard library could be improved, at least by removing
> dangerous function like gets() or stupid functions like strncpy and
> making all functions thread safe. It might also be made simpler by
> removing useless type like size_t.

Why is size_t useless?

DES
--
Dag-Erling Smørgrav - des@des.no
--
comp.lang.c.moderated - moderation address: clcm@plethora.net -- you must
have an appropriate newsgroups line in your header for your mail to be seen,
or the newsgroup name in square brackets in the subject line. Sorry.

==============================================================================
TOPIC: ☂☂☂ 2010 Cheap price wholesale LV handbag and purse at WEBSITE: http://
www.rijing-trade.com 【paypal payment】
http://groups.google.com/group/comp.lang.c/t/c4cfa0f1b12bfbda?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Mar 17 2010 8:11 am
From: "www.fjrjtrade.com"

Cheap wholesale handbag

Cheap wholesale purse

Cheap wholesale LV handbag

cheap wholesale LV purse

Cheap wholesale AAA True Leather handbag and purse

Cheap wholesale AAA True Leather LV handbag

Cheap wholesale AAA True Leather LV purse

http://www.rijing-trade.com

==============================================================================
TOPIC: Idiotic programming style edicts
http://groups.google.com/group/comp.lang.c/t/99bc3aa427fc7518?hl=en
==============================================================================

== 1 of 4 ==
Date: Wed, Mar 17 2010 8:14 am
From: Keith Thompson

Nick Keighley <nick_keighley_nospam@hotmail.com> writes:
[...]
>> In article <IU.D20100316.T165150.P1185...@J.de.Boyne.Pollard.localhost>,
>> Jonathan de Boyne Pollard <J.deBoynePollard-newsgro...@NTLWorld.COM> wrote:
>
>> >>> If an obscure technique is being employed, then a comment to that
>> >>> effect is a helpful pointer but I have seen _REALLY USEFUL_ comments
>> >>> along the following lines ...
>>
>> >>> x := X + 1 ; increment x
>>
[...]
>
> it plainly isn't C. Perhaps in whatever-it-is-written-in cares about
> case.
>
> What *is* it written in?
[...]

I don't recognize the language, but it was originally posted only
to alt.folklore.computers. Somebody decided to add a cross-post
to comp.programming and comp.lang.c and didn't bother to mention it.

--
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 4 ==
Date: Wed, Mar 17 2010 8:20 am
From: "jackassplus@gmail.com"

> > What *is* it written in?
>
> [...]
>
> I don't recognize the language, but it was originally posted only
> to alt.folklore.computers. Somebody decided to add a cross-post
> to comp.programming and comp.lang.c and didn't bother to mention it.
>

pascal uses := as an assignment operator

== 3 of 4 ==
Date: Wed, Mar 17 2010 8:33 am
From: Keith Thompson

"jackassplus@gmail.com" <jackassplus@gmail.com> writes:
>> > What *is* it written in?
>>
>> [...]
>>
>> I don't recognize the language, but it was originally posted only
>> to alt.folklore.computers. Somebody decided to add a cross-post
>> to comp.programming and comp.lang.c and didn't bother to mention it.
>
> pascal uses := as an assignment operator

But it doesn't use ; to introduce a comment.

Of course, the code could have been incorrect.

== 4 of 4 ==
Date: Wed, Mar 17 2010 9:22 am
From: "Magnum"

"Keith Thompson" <kst-u@mib.org> wrote in message
news:lniq8vdktp.fsf@nuthaus.mib.org...
> "jackassplus@gmail.com" <jackassplus@gmail.com> writes:
>>> > What *is* it written in?
>>>
>>> [...]
>>>
>>> I don't recognize the language, but it was originally posted only
>>> to alt.folklore.computers. Somebody decided to add a cross-post
>>> to comp.programming and comp.lang.c and didn't bother to mention it.
>>
>> pascal uses := as an assignment operator
>
> But it doesn't use ; to introduce a comment.
>
> Of course, the code could have been incorrect.

or it could have been notional code in no particular language as the
context was the illustration of pointless commenting, and the X instead
of x just being a typo?

==============================================================================
TOPIC: Casting jmp_buf to void *
http://groups.google.com/group/comp.lang.c/t/a9e559468513ce12?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Mar 17 2010 8:20 am
From: Ben Bacarisse

Nobody <nobody@nowhere.com> writes:

> On Thu, 11 Mar 2010 18:45:29 +0000, Ben Bacarisse wrote:
>
>>> Instead, I'd have to write
>>>
>>> jmp_buf env;
>>> ctx->user_data = &env;
>>
>> This is pretty much the same as the above. The main trouble is going
>> to be the lifetime of 'env'. All will be well provided 'env' still
>> exists when the point to it is used, but if the function containing
>> 'env' might return before the pointer is used, you'll have to use
>> malloc to allocate storage for the jmp_buf.
>
> Using malloc() isn't going to help. Once you leave the function in which
> setjmp() was called, trying to longjmp() back to that point isn't likely
> to work. So you may as well use an automatic variable.

Good point. I was blindly giving general advice without thinking
about the particulars of the case.

--
Ben.

==============================================================================
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: Wed, Mar 17 2010 9:30 am
From: spinoza1111

On Mar 17, 2:13 am, John Bode <jfbode1...@gmail.com> wrote:
> On Mar 16, 11:59 am,spinoza1111<spinoza1...@yahoo.com> wrote:
>
>
>
>
>
> > On Mar 16, 10:28 pm, John Bode <jfbode1...@gmail.com> wrote:
>
> > > On Mar 14, 12:38 am,spinoza1111<spinoza1...@yahoo.com> wrote:
>
> > > [snippage]
>
> > > > No, he pissed me off by criticizing Schildt without standing and
> > > > didn't apologize.
>
> > > "Without standing"?
>
> > > The errors that Seebach points out are real; some are nit-picky, some
> > > are serious. Schildt's example code has real bugs. He offers
> > > explanations that are, to put it kindly, at variance with the language
> > > definition.
>
> > At the time the first edition was written, there were multiple
> > versions of C, because it was an adolescent prank and not a
> > programming language.
>
> So, in order to defend Schildt, you're going to attack Ritchie's
> abilities as a language designer? Is that your plan? Schildt didn't
> describe the language incorrectly, it was Ritchie who designed the
> language incorrectly?

Yes. Since you probably weren't a programmer in 1970, you probably
don't realize how little was actually known about language design back
then. C is a mishmash of ideas from the American Fortran tradition and
the European Algol tradition.

For example, the for statement is poorly designed since its variables
are repeatedly evaluated, rather than other for statements in other
languages in which a limiting value is forced to be constant for the
duration of the for loop (by copying it into a register in early
Fortran). This means that the function of C's while statement is
duplicated in the for loop, "enabling" programmers to change the limit
value in the loop, which makes inspection of code for loop termination
more difficult, and not orthogonal.

Aliasing was unneeded since low level code can be written in a
suitable macro assembler. It was adolescent and foolish for Pike et
al. to think that the world needed to write bootstrap and kernel code
in a high level language, especially since conditional macro assembly
could and did make code highly portable for wide families of machines.

IBM did not need to write the VM operating system in C and it would
have been foolish to do so. Nonetheless, VM ran on a wide range of
360, 370 and subsequent mainframes because it was shipped using a
conditional macro assembler to handle machine differences and customer
needs (I was a systems programmer at Standard Oil until disgusted by
the good old boy culture).

>
> I remember the bad old days before C89, but the kinds of errors
> Schildt made weren't due to the fact that implementations varied.
> Code like
>
> Page 53:
> /* Write 6 integers to a disk file. */
> void put_rec(int rec[6], FILE *fp)
> {
> int len;
>
> len = fwrite(rec, sizeof rec, 1, fp);
> if (len != 1) printf("write error");
> }
>
> wasn't going to work correctly *anywhere*.

As is the case with many book examples, including, by their own
admission, code in Seebs' and Heathfield's books. When publishers
start forcing authors that integrate testable code with text, this
won't happen, but since computer book warranties are the same as
software warranties, indemnifying the publisher in both cases, there
is simply no economic motivation to do this.

In my experience, it is difficult to get nontechnical editors to
understand how to format code. Once the computer author pastes code
into his Word manuscript, errors can creep in and in a book project
there is only a finite amount of time to fix all errors.

Which perhaps is as it should be, since part of connecting with and
using a computer book is testing its code examples.

It is true that the IBM and Microsoft computing communities, in which
I spent most of my professional career, there was a larger problem
with bugs: OS/360, like each release of Windows, shipped with
thousands of bugs in each new release. I wasn't happy with this.

However, the unix community never solved the problem either, and had
fewer bugs only because it shipped far less software than IBM or
Microsoft. The problem was only partly solved by the curious invention
of virtual, sliced and diced slave labor, called open source, which is
based on the theft of intellectual production and its transformation
by greedheads into holy private property.

The result of this "digital Maoism"? The destruction of the middle
class that in 1990 could expect to get paid for programming.

>
> > Seebach and Richard Heathfield have BOTH admitted that their own books
> > contain numerous errors. Therefore, where do they get the right to
> > target Schildt and his family (by making a foul word of his patronym)?
>
> An error is an error, regardless of who points it out. Everybody
> makes mistakes. The problem with C:TCR is that it had *so many*

According to Seebach in CTCN, there were twenty errors. His claim
elsewhere in the document that there were hundreds more was logically
contradictory. Since the list contained twenty errors we can only
conclude that Seebs was lying about "hundreds" more even as Roy Cohn
and Senator Joseph McCarthy deliberately lied in the 1950s that there
were "thousands" of Communists in the US government.

Furthermore, it is not an error to use the "stack" in describing how C
runtime works. Many of the errors actually reported were based on
shibboleth (where a "shibboleth" was how a tribe of Israel pronounced
"ear of corn" and used to identify friend from foe).

> errors in one volume coupled with its wide popularity. It had a
> negative affect on the educations of a *lot* of programmers. It's

This claim is unsupported and false. The fact is that incompetent
programmers don't read books either good or bad, and the programmers
of Asia, who are in my direct experience more competent than American
programmers, passionately read books, "good" and "bad" and improve
thereby.

This is because it is a lower middle class myth (based on the wars of
religion in Europe between 1519 and 1648, and similar wars elsewhere)
that there exist "bad" books, such as the "wrong" translation of
Scripture, or a "bad" Qu'ran. Intelligent, well educated people never
think this way. They read Mein Kampf and the ravings of the Marquis de
Sade without damaging their psyches.

In fact, "no bad books" is essential to the theoretical foundations of
freedom of speech found, among other places, in JS Mills' Essay on
Liberty. Mill points out that we can never be certain that a book is
worthless, and if it is, like Mein Kampf or Atlas Shrugged, it still
needs to be preserved for the same reason there is no death penalty in
the European Union: we can learn about murder from a mass murderer in
order to prevent murder, and we can expose foolishness in Ayn Rand to
teach real philosophy.

Sure, there are bad books, like Atlas Shrugged. So don't buy them, and
recommend other books to your friends. Don't use the false authority
of the internet to destroy a man's reputation, and in such a way that
psychos and bullies follow your lead, and amplify your campaign into a
Lynch mob of would-be murderers such as hounded Java author Kathy
Sierra.

I'm not saying Schildt is as bad as Ayn Rand, of course. My considered
opinion is that he is a bit Microsoft centric in such a way that he
didn't consider the needs of embedded programmers for a higher level
of portability. However, in my own experience as a computer author,
the corporation publishing your book exercises a great deal of control
over what you write, and the marketers at McGraw Hill appear to have
decided that the mass market consisted primarily of Microsoft
programmers, who didn't have to worry about what main returns.

I was handed, in my first computer science class, Sherman's
"Programming and Coding for Digital Computers". It used the IBM 7094,
an old scientific mainframe, with a fixed word length and a one
address instruction architecture with general registers. However, the
only computer available to us was radically different: it was the IBM
1401, an old business mainframe, with a variable word length, a two
address instruction architecture, and three index registers as an
extra cost feature.

Nonetheless, I learned a lot by seeing that Sherman's core concepts,
most significantly the idea that "any computer can, given enough time
and memory, simulate any other computer". The differences revealed the
Turing egalitarianism of all computers.

> taken the better part of 20 years and 3 more editions to get it to
> where it's (apparently) passable. That's not a good record to stand
> on.

Sort of like Windows, right? You underestimate user (programmer)
intelligence, and, as we'll see, you apply different standards to
yourself in a way that proves the Schildt canard to be motivated by
envy and malice, in the same way some anti-Microsoft bullshit is
motivated.

>
> And I don't think either Seebach or Heathfield coined the term
> "Bullschildt" (earliest references I see in the archives are from
> Chris Engebretson and Jens Schweikhardt); I wouldn't be surprised if
> there were multiple independent sources for it. I'm not sure I didn't
> hear the term from one of my professors in '88 or '89.

The "independent" sources all cited CTCN which is, as far as I can
determine, the root of a tree or graph of citations which all trace
back to CTCN. Furthermore, "Bullschildt" has appeared in previous
copies of CTCN which is under Seebach's control. He seems to be
changing it. He needs to erase it.

>
> > Seebach has no standing since he doesn't appear to be a real
> > programmer.
>
> He can read the language standard. He can compare what the language
> standard says with what Schildt says. He can point out where they
> differ. He can look at the snippet posted above and based on the text
> of the standard reason that it's not going to behave as described.

At the time, not all, nor perhaps even a majority, of C compilers were
conformant. If your code doesn't work on the machine you've been
assigned, the standard is meaningless.
>
> That's all the standing he (or anyone else) needs. And FWIW, I *am* a
> "real programmer" (as in, I have a CS degree, I'm a professional
> software developer, it's what I've been doing for 20 years now in a

This doesn't mean that Seebach is anything of these things.

> variety of fields), and while I'll be the first to admit that I'm more
> hack than hacker, I *am* qualified to judge Schildt's book on merit.

Many programmers, in my experience, are in fact deficient in judgement
on real affairs.

>
> From the perspective of someone who *is* a professional programmer and
> *does* know the C language pretty well, Seebach's criticisms of
> Schildt's book are valid.
>
> > His code examples here have mostly been buggy, and have
> > been of the script kiddie's "let's get this done and worry about bugs
> > later" variety.
>
> God knows I don't put the same kind of effort into writing examples
> here that I put into writing code at work; I don't expect that of
> anyone else. There shouldn't be *obvious* bugs, but I'm not going to
> spend hours and hours getting that snippet *just* right.

Oh? But this undercuts your claims about Schildt, since internet
publication is publication, same as Schildt, and there are two reasons
for using the same amount of diligence in publishing code here:

* Newbies will trust your online snippets and if Schildt must not
mislead newbies, YOU must not mislead newbies

* Regulars will mock you if they find a bug, damaging your reputation
should your manager or a prospective employer examine your published
code

Furthermore, here, you aren't "under the gun" at a publisher, to meet
a deadline, when you post code here. You can take time to review your
code, or, alternatively, release early versions explicitly stating (as
I stated in rel 0 of my replace()) that you invite debugging feedback.

I conclude that like Seebach, who constantly seems to be apologizing
for his errors and expecting us to forgive him, you have too much
unexamined malice to show collegiality and charity.

>
> > Whereas Schildt has genuine programming experience,
> > enough to know that if a specific C compiler permits a variant return
> > from main that it DOESN'T MATTER unless the code is ported, and enough
> > to have a grownup's perspective on what it takes to get a job done.
>
> IIRC, he never mentioned portability wrt main's return type; not
> surprising, since the book assumed that all the world was DOS. The
> VMS C compiler didn't seem to care much either, but that doesn't make
> the statement any less wrong. The C runtime owns the interface to
> main, not the programmer. main should return whatever the runtime
> environment expects it to return.

Why? In a business where programmers constantly criticize their
colleagues for not meeting unreasonable and money-motivated management
targets set with no negotiation with programmers, and with no
consideration of the interests of consumers or labor, we don't need
silly rules.

Rules are not fungible. Just because your code is "standard" doesn't
mean it works, is efficient, or does what the user wants.

Rules for good style aren't silly in all cases, nor is the need for
some such rule. Unfortunately, most programmers have silly ideas about
"good style" because unlike real authorities on programming style,
like Kernighan and Dijkstra, most programmers have neither enough
education nor verbal skill to go around shooting their goddamn mouths
off about "good" style, much less backstab their coworkers and
colleagues. As it happens, the only good style is constituted by a
skill that, in developed countries like the USA and UK, is in rapid
decline. This is the ability to write a grammatical English sentence
above a low upper bound of complexity.

The only other "good style" is a tight, mathematical style which makes
the C code look like a mathematical proof, and for the same reasons
that most programmers have low skills in their natural language
(English, of course, in the US and UK), they have no mathematical
talent or education. In fact, I found Willem's style accessible, and
it is highly mathematical.

All else is folklore, shibboleth, and myth.

>
> > He also has considerable more academic qualifications than Seebach:
> > Schildt has a BS and MS in computer science: Seebach has taken no
> > courses at all in computer science.
>
> A degree in CS is not a degree in programming; one can be a skilled
> programmer without having taken a single hour of CS classes. And, to

Yes, but we have confirmed that Peter Seebach is not a skilled
programmer:

* A one line strlen with an off by one bug

* A program that was supposed to find and replace %s and which
replaced percent, anything

* The incorrect design of that program, which used strchr instead of
strstr to find %s, which is a string and not a character.

* Refusal to participate in reviewing my replace() solution which
along with Willems was the first, and perhaps the only, code to meet
my challenge of not using string.h, accompanied by libel

Furthermore, it appears that Seebach is completely unmotivated to take
CS classes despite the fact that his company probably has tuition
support. It's clear to me from his adolescent behavior that he'd go
into a CS class "loaded for bear", prepared to disrupt the class with
his "knowledge".

This incuriosity, combined with a bullying streak, was characteristic
of George Bush (whom Peter is on record as supporting) and it is a
growing problem in programming as well as UK and US politics, which
are taking on a Fascist streak.

In the UK, yobs recently kicked an old retarded man to death: this is
what is happening here.

In the USA, stylistic criticisms of Kathy Sierra's lighthearted and
beautiful books on Java were noted by misogynist, hate-filled,
unemployable former programmers and she was threatened with rape and
murder: this is what is happening here.

In China, a kid who was said to be "addicted" to the Internet was
kicked to death in an "Internet recovery camp" by thugs: this is what
is happening here.

There's something happening here
What it is ain't exactly clear
There's a man with a gun over there
Telling me I got to beware
I think it's time we stop, children, what's that sound
Everybody look what's going down (Buffalo Springfield)

> flog the equine carcass again, some more, most of us in this newsgroup
> who share Seebach's criticisms of C:TCR *do* have CS degrees and *do*
> write code professionally.

You're not immune from shibboleth and fashion, and the reason you saw
these criticisms in the C FAQ was that they were sourced in a chain of
citation that leads back to CTCN. You've been misled, as are Tea
Baggers, by the mere appearance of a large volume of evidence that is
created merely by the ease of hyperlinking and copying on the Web.

The Schildt canard is like the Obama birth canard: reference by
aliterate MORONS to the Web, and citations which cite each other in a
closed loop.
>
> > > The first edition of C:TCR was *crap*. It contained an unacceptable
> > > number of mistakes for a technical reference. I had a copy that I
> > > eventually tossed in frustration after finding obvious bugs like
>
> > > fclose(fp);
> > > fwrite(fp, ...);
>
> > > throughout the example code.
>
> > Bugs in published code are endemic.
>
> True; however, there were *so many* bugs in the C:TCR example code
> that it was practically useless.

The free market seems to have decided otherwise, as it decided in the
case of Windows. And there are only twenty in CTCN. And, one of those
is based on Seebach's ignorance of heaps and stacks. He was ignorant
of heaps and stacks because he's never taken a computer science class.

>
>
>
>
>
> > I spoke to Brian Kernighan about
> > this matter in 1986 when I was working at Princeton. Unfortunately, in
> > my experience with Apress, computer books are assembled using
> > Microsoft Word and PDF, not Tex and literate programming, Donald
> > Knuth's solution, and this is NOT because of moral failings or
> > incompetence on the part of computer authors, but because of the
> > publisher's rush to market.
>
> > Indeed, some companies, like Sams, are out of control in this respect,
> > forcing authors to work 16 hours a day for free and suing them when
> > they complain.
>
> > Both Peter and Richard "C Unleashed" Heathfield have confessed to
> > having bugs in their publications. When I beat this admission out of
> > them, they turned around and charged Schildt with not publishing
> > errata, which I think was a lie. It is moot because as all parties to
> > this debate admit, Schildt's book (unlike Peter's or Richard's) was
> > successful and warranted new editions in which the important errors
> > have been fixed.
>
> > > We're not attacking Schildt as a person; for all I know he's a decent
> > > guy. But T:TCR 1st ed. was *deeply* flawed, and it's in the best
> > > interest of everyone (Schildt included) to point out the mistakes so
> > > that they can be corrected in future editions. My understanding is
> > > that the current edition is halfway decent, although I'm not going to
> > > spend the money to find out. No author, technical or otherwise,
> > > should be immune from criticism, and the qualifications of the critic
> > > *do not matter* if the criticism is valid.
>
> > A document issued in a temper tantrum (because McGraw Hill wouldn't
> > give Seebach tons of money) with the claim that there were "hundreds"
> > of bugs in Schildt and a contradictory list of twenty "known" bugs is
> > not "criticism". At best, it was childish. At worst, it was Seebach's
> > attempt to make a name for himself as a programmer without any
> > academic credentials.
>
> So now who's engaging in defamation?

Unfortunately, in verbal self defense, I have been forced to research
the origins of CTCN and I have discovered that its author was
unqualified then and now. To prove libel, you have to "defame" using
the truth.

>
> [snipping the rest; the spirit is willing, but the flesh needs lunch]

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

== 1 of 2 ==
Date: Wed, Mar 17 2010 9:38 am
From: spinoza1111

On Mar 7, 2:52 am, blm...@myrealbox.com <blm...@myrealbox.com> wrote:
> In article <slrnhog6hj.l5f.usenet-nos...@guild.seebs.net>,
>
> Seebs <usenet-nos...@seebs.net> wrote:
> > On 2010-02-26, blmblm myrealbox.com <blm...@myrealbox.com> wrote:
> > > In article <8865e7a2-6b21-4e80-9ba6-eaf563a46...@g28g2000prb.googlegroups.com>,
> > >spinoza1111 <spinoza1...@yahoo.com> wrote:
>
> [ snip ]
>
> > >> I clearly deserve A+ if you ask me. I regard Willem's work as A+ and
> > >> although his style is radically different from mine, as a decent
> > >> programmer I do NOT use shibboleth as doth Peter Seebach. I dove right
> > >> into his code and read it, discovering his recursive insight...which I
> > >> helped him bring to fruition.
>
> > > By providing a testing framework and finding one bug, right?
>
> > I guess.
>
> > I still have no clue what his complaint about my version is. It works, and
> > so far as I know, it passed every test but the 0-length needle on the first
> > try, and a trivial one-line patch fixed that. It hasn't needed several hours
> > of debugging to work perfectly for all known input data, just five minutes to
> > handle a pathological boundary condition.
>
> I should probably not presume to speak for Mr. Nilges, but my guess
> is that his objection to your code is that it uses functions from
> string.h. I won't try to summarize/restate what it is he objects to
> about those functions, since I'm not sure I understand it myself.
> <shrug>

Not with a bang but a whimper, or a shrug, huh?

As it happened, and as you should know, I decided to respond to
Peter's errors (not searching for %s and using strchr and not strstr)
to show programming at a much higher level than script kiddiedom.
Since Nul terminated strings are a mistake, I decided to show how
optional string.h is. This created an interesting challenge for the
real coders here, and a lot of mockery from our local attention
disordered script kiddie.

But obviously, you're entirely too dainty to serve this ng by helping
to eradicate people who come in here to advance their low sense of
self worth by destroying others in a zero-sum game. Like Obama allows
Israel to piss on his face, in my view.
>
> --
> B. L. Massingill
> ObDisclaimer: I don't speak for my employers; they return the favor.

== 2 of 2 ==
Date: Wed, Mar 17 2010 9:42 am
From: spinoza1111

On Mar 1, 12:43 pm, spinoza1111 <spinoza1...@yahoo.com> wrote:
> On Feb 28, 11:13 pm,spinoza1111<spinoza1...@yahoo.com> wrote:
>
>
>
>
>
> > On Feb 27, 11:58 pm,spinoza1111<spinoza1...@yahoo.com> wrote:
>
> > > On Feb 27, 1:52 am, blm...@myrealbox.com <blm...@myrealbox.com> wrote:
>
> > > > In article <0e861416-2f69-455d-a61e-e9878eeab...@y7g2000prc.googlegroups.com>,
>
> > > >spinoza1111 <spinoza1...@yahoo.com> wrote:
> > > > > On Feb 25, 10:12 pm, Walter Banks <wal...@bytecraft.com> wrote:
> > > > > > spinoza1111wrote:
>
> > > > [ snip ]
>
> > > > > > Results are in the middle of the pack not the stuff of a A+.
>
> > > > > > w..
>
> > > > > Oh gee, this was Walter. If anything I said (including my poem)
> > > > > implies that my opinion of blm is lower, I withdraw it. I already had
> > > > > a low opinion of Walter.
>
> > > > Which poem was that .... (I have to say that I usually skip your
> > > > verse.)
>
> > > Of course you do, dear Ms Massingill,
> > > Of course you do, for we live in an age of songs of the doomed
> > > Tuneless dirges are all you hear
> > > The music of language, what you fear.
>
> > This was poorly written and unnecessarily offensive on my part, as
> > opposed when it is necessary to be offensive to the truly offensive. I
> > apologize for this.
>
> > > It was where I replied to Walter's saying I'm in the middle of the
> > > pack. Got my goat, since I wouldn't be in the middle of any pack that
> > > would have me. I am either way ahead or light years behind any pack
> > > here.
>
> > > > --
> > > > B. L. Massingill
> > > > ObDisclaimer: I don't speak for my employers; they return the favor.
>
> However, it's plain that I'm a piker when it comes to being offensive.
> See Heathfield's post in the thread Edward Nilges' Lie.
>
> Because he cannot code properly and doesn't know computer science, and
> is an uncultivated boor who works as a temp, he thinks it's cute to
> forge letters said to be from me, a violation of the law.
>
> Julienne and blm, you are enablers, because you don't complain to him
> about his behavior: like many women in this type of situation, you're
> a little dazzled by the thug and his transgressions; perhaps an
> atavistic part of you is not a little excited by blood, metaphorical
> or otherwise. I am using this newsgroup as intended and even Seebach
> has conceded that these threads have been useful and productive. I
> start them, whereas Heathfield and Seebach endeavor to destroy them
> because they're not qualified to participate on a level with people
> like Navia and Willem, let alone me (100% bug rate in strlen, absurd
> linked list, heap a DOS term, is not a programmer per se, etc).
>
> Julienne, blm, and Malcolm, I shall not participate until you find it
> in yourselves to complain to Heathfield and Seebach in the thread
> Edward Nilges' lie where Heathfield posts a letter he says is from my
> lawyer: this was a criminal act. I will not read or post to these
> newsgroup, and you people can return to your regularly scheduled
> programming.
>
> You may email me at spinoza1...@yahoo.com. But what I would most
> appreciate is copies of your post or emails to Seebach and Heathfield,
> asking them to desist. This type of behavior is the norm in groups of
> fair and decent people.
>
> Otherwise, I am wasting my time here.
>
> Malcolm, Julienne, blm: unless I hear from you by Monday March 8,
> under advice of my counsel, genuine letters are going this week to
> Seebach's employer and my publisher (who is also Seebach's publisher)
> concerning his behavior. In addition, a letter is going to SAMS
> concerning Heathfield.

At this time, a letter has gone to Apress. For the same reason I take
the time to document code neatly and in a literate fashion, I shall
choose the rate at which the process proceeds. As for returning,
that's just a decision. What is sick and bizarre here is Heathfield's
pattern. It appears to me he's being paid for posting.

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

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

Wednesday, March 17, 2010

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

0 Comments:

Post a Comment

About Me

Previous Posts