parsing commands and parameters

[Dave Thompson]

Michael Wojcik wrote:

[snip 115 lines quoted without comment]

Learn to trim your posts, please.

Some news clients do not deliver the full conversation, hence why I did
not trim anything.

Aside: Any decent client, or(!) google, should deliver all the
articles its server has in a thread, which I think is usually more
accurately characterized as a discussion rather than a conversation.
Where articles go missing is generally on (or arguably between)
_servers_. And on today's Internet that is rare enough that I think
the time wasted by 99.99% of readers who have to skip through the
duplicative material outweighs the .01% who missed the previous
article, _and_ are interested in it, and have to go find it. And even
then they can't easily be sure you have duplicated it completely so
have to find it anyway.

Restored from Wojcik, this time too eagerly snipped:

Whatever for? You're going to overwrite those bytes in a moment
anyway. And if you must clear it, what's wrong with just assigning
{0} to it when you define it? And if you must use memset, why are
you passing in the length as a magic number?

memset() as used in my example is always a good idea. Yes you can

I'm not sure I agree with that. A properly designed IMO algorithm
usually "knows" (keeps track) of how much of a string or more
generally array it uses, and won't access elements/parts it hasn't
set, and hence doesn't need them pre-set. In some cases, especially
while debugging, it may be helpful to pre-set to some obvious wrong
value, like all '*', so if you see that you know to look for a bug. I
have almost never found it helpful to set zeros. But if you want to:

accomplish the same during initilization, however you do not know what
might be in the buffer after the first location. malloc() returns you a

Assuming you mean the official sense of initialization and thus a
declared (not dynamic) item, and also Wojcik meant initialization and
not assignment which is impossible, wrong.
char recipient [512] = {0};
initializes ALL 512 bytes to zero: the first to the value you specify
which is zero, and the rest to zeros regardless of what you specify.
Only if you give no initializer at all, for an auto=local variable, is
it 'dirty'; for a static-duration variable it defaults to all zeros.
This is standard. It may not be clear to inexperienced readers, so you
could reasonably add a comment to that effect.

pointer to memory containing the space you requested. In many cases
(especially on a busy system) this memory is dirty.

For malloc'ed space, yes, you need memset -- or calloc -- to zero all.
(Or write your own equivalent code -- but why bother.) Note that
either does all-bits-zero, which on rare systems may not be value zero
for floating-point or null for pointers, although usually they are.

- David.Thompson1 at worldnet.att.net

 

[Walter Roberson]

Where articles go missing is generally on (or arguably between)
_servers_. And on today's Internet that is rare enough that I think
the time wasted by 99.99% of readers who have to skip through the
duplicative material outweighs the .01% who missed the previous
article, _and_ are interested in it, and have to go find it. And even
then they can't easily be sure you have duplicated it completely so
have to find it anyway.

Unfortunately lost messages are still a fact of life in Usenet.
In my city, both the local DSL provider and the local broadband
cable provider have poor news servers; the DSL provider claims
otherwise but messages in the local newsgroups -often- go missing.
And the cable provider apparently basically says "We don't care.
If newsgroups are important to you, use google or subscribe
to supernews."

The missing local messages seem the result of a poor propagation
map -- there are some people whose messages rarely show up.

In practice, the trimmed quoting that people do on the local
newsgroups is often enough to understand what is going on without
needing to go back to the original messages.

So... trimmed quoting works... and Usenet reliability is less than
four nines; indeed for some flow patterns, dropped messages are
more common than successful ones.

 

[Mark McIntyre]

Aside: Any decent client, or(!) google, should deliver all the
articles its server has in a thread,

The important word is "has".
My ISP's news server drops many articles, which is why I subscribe to
a paid-for service. This drops less, but not zero .

And on today's Internet that is rare enough

Wrong, oh how horribly wrong !! If your server drops only 0.01%,
you're a lucky man.

that I think
the time wasted by 99.99% of readers who have to skip through the
duplicative material outweighs the .01% who missed the previous
article,

You should consider that people do not always come in at the start of
a thread. Some threads run for days. People take holidays. Server
retention isn't indefinite.

 

[CBFalconer]

.... snip ...


You should consider that people do not always come in at the
start of a thread. Some threads run for days. People take
holidays. Server retention isn't indefinite.

And I hope many servers trap and discard at least a portion of the
spam. This process is bound to result in some mistakes. So the
adage of making each article stand by itself, by means of quotes
and whatnot, is even more important.