Re: Reading a string of unknown size

Richard Heathfield wrote:
websnarf@xxxxxxxxx said:
Richard Heathfield wrote:
websnarf@xxxxxxxxx said:
<snip>
Superfluous structure that
your compiler is going to strip out of the object code anyways has no
negative impact on correctness or performance.

If it's superfluous (your word, not mine, but I agree that it is
appropriate here), you might as well leave it out.

You mean like you should never comment your code because comments are
superfluous?

I don't agree that comments are superfluous. *You* said the structure was
superfluous, and "superfluous" means "redundant, unnecessary" (look in a
dictionary if you don't believe me).

Huh? I don't have a problem with the definition. Comments describe
what the code is doing (redundant, since the source itself does that)
and are ignored by the compiler (unnecessary). So what is your
problem? (Note that this does not imply that Comments are a bad
thing.)

(Certainly, their value is at best subjective.)
Sometimes redundancy is useful -- this is the lesson of structured
programming.

If it's useful, how can it be redundant?

Well let's just pause and think about this for a second.

Most CPU caches have parity bits, or ECC which are *REDUNDANT* to the
raw data its already carrying. So the question is, how can parity bits
or ECC be useful? Perhaps we need a research project to figure that
out. You'll find the same thing on hard disks and CD Roms.

TCP/IP uses a ones completement checksum on its packets. This checksum
is obviously derivable from the rest of the data its delivering.

There are well known algorithms, in fact called "Cyclic Redundancy
Check". Interesting that people would waste time developing these
algorithms if they weren't useful. Do you think these algorithms
belong in the same category as bogosort or the brainf---- computer
language?

In C or Pascal, you usually have a { or begin that matches the start of
a program block. Without any loss of correct grammar parsing, you
could obviously just drop those. So they should be considered
redundant.

When you teach a grade school student to spell, or some rules of
arithmetic or whatever, you commonly do so through the process of
repetition. This act is of course redundant, since you aren't doing
anything one time you didn't do an earlier time. So is it useful for
students to repeat exercises like this even though it is redundant?

Messing up a void *
pointer will cause truly arbitrary action. The two are not comparable
by outcome.

Have you ever tried *not* messing up a void * pointer? I have. It works
just fine.

Sure. Self-modifying code works fine too.

<snip>

But taking a step back, it occurrs to me that "it works fine" is
a fairly low standard for writing code.

Taking a step forward again, "it works fine" is a fabulous *baseline* for
writing code.

Bare minimum requirements are fabulous?

[...] For example, fopen works fine, and I use it quite happily,
without worrying that my code is somehow of a low standard just because it
uses something that works fine.

But obfuscated code works fine too.

[...] Using void pointers correctly does not
imply fragile code.

Well that's not exactly what I was saying. It becomes a place were an
error can *hide*. Fragile code is usually much better because it
breaks at the drop of a hat, and so you can isolate and debug it
easily, or with moderate testing.

With a void * pointer, you can allocate the wrong thing to it. If you
inadvertantly underallocate and you have good heap debugging facilities
then maybe you can get away with a short debug session. But if you
*over* allocate and this causes you to run out of memory -- now what
are you going to do? The bug may have happened many *days* earlier
during a long run of something.

[...] Using void pointers incorrectly is a losing strategy.
But so is using casts incorrectly. So is using fopen incorrectly. So is
using *anything* incorrectly.

So you live in such a dichometric universe that you can't see anything
other than black and white? Either something is wrong or it isn't, and
you are not even concerned at all with the path you take in getting
from wrong to right?

On the counter point, have you ever tried to debug a messed up type
coercion hidden by a void *?

Yes - in fact I've almost certainly done so right here in comp.lang.c. And
I've debugged screwed-up macro calls, too. So?

The real problem with it is that you
don't even realize that's what's gone wrong until you get deeply into
debugging in. And the debugger will typically be far less helpful than
you wished.

"Think first, compute later" is always a good plan.

No, that's not a plan at all. Its a mantra, and an unachievable ideal.
People do not think with perfection, so this will inevitably lead to
manifestions of thoughtless code. How about a more serious plan: "Use
your tools to assist you in ferreting out bugs before they happen to
the greatest degree possible".

[...] I generally don't bother
too much with debuggers nowadays. They are occasional ports in a storm,
that's all.

So you don't deal with large amounts of other people's code?

[...] It can hide the non-inclusion of it's prototype,

On *SOME* older generation compilers. No modern compiler fails to
give a warning about this regardless of the cast.

So if anyone comes up with a counter-example, you can simply claim
that it's not a "modern" compiler. ("True Scotsman" argument.)

For development?

Sure. Just because an implementation doesn't give one particular
diagnostic message that Paul Hsieh thinks it should, that doesn't mean
it's a Bad Compiler.

Right ... but we're several posts into this, and you couldn't even come
up with one?

Why bother?

Indeed.

[...] The diagnostic message is not required by the Standard, so it
makes no sense to me to insist to compiler-writers that they provide it.

Right. Unfortunately, I never been able to successfully compile
anything using the standard. I usually use a compiler.

[...] So trying to make C type safe is a bit like
trying to make Ook! object-oriented.

Interesting observation. If you intersect C and C++ what are you left
with?

Either poor C, poor C++, or syntax errors.

There's some intellectual honesty for you. Incidentally, the answer is
a syntactical subset of C (but functionally equivalent to C itself).

Using the
non-casting style of malloc usage doesn't change the above scenario in
any relevant way.

I agree entirely, but my point was only that your macro doesn't magically
introduce type safety into a language that I prefer to think of as "type
aware". To some people, type safety is a straitjacket.

Well to some people type safety is free automated assistance.

I have no problem with free automated assistance, but free automated
dictation is another matter. Whether a pointer of type <foo> is meaningful
when interpreted as if it were a pointer of type <bar> is something that
I'll judge for myself.

So why have any type safety at all?

Ironically, the correct solution is to use a C++
compiler which would spit errors at you for the last line.

Ironically, by introducing C++ into this argument you just explained why
your suggestions about C should be treated with a pinch of salt.

Do I smell a fundamentalist ideology?

No, you smell comp.lang.c, which is about C, not C++. If you want to discuss
C++, there's a whole nother newsgroup for that.

When did I say I wanted to discuss C++? When did I imply this? What
is leading you to this ridiculous statement? You can't read complete
sentences, that you didn't even snip out. That's a blindness very
common to fundamentalism.

[...] And if you want to discuss
programming in general, there's a newsgroup for that, too.

I'm not taking direction from you or anyone about where I post.

p = malloc(n * sizeof *p); does not need to be told the type, so you
can't get the type wrong.

but mismatching the variable and
the thing you are taking sizeof is not error-prone?

There is no such mismatch in the canonical form.

I don't know what you are talking about. You cut and paste, you change
the target variable and miss the sizeof variable.

Oh, okay, I see what you mean.

It took this many posts?

[...] I thought you were talking about types, not
objects. The reason I didn't "get it" immediately is probably because I
find it quicker to type p = malloc(n * sizeof *p); than to invoke a copy
operation, a move operation, a paste operation, and two edits. Copy-paste
is expensive compared to typing when the amount to be copied is low, and
silly when the amount to be copied is high (because you're missing an
opportunity for re-factoring).

Enter the bizzaro world of Richard Heathfield's editting mind. You
usually end up doing this when you copy entire routines that are
similar in nature, but need to rework the insides of it a bit to match
different signatures and types. C doesn't have templates you know.

Ok, you've just
introduced a silent error, that's many hours of debugging waiting to
happen.

Perhaps I need more practice. I generally don't manage to make debugging
last more than a few minutes.

Yeah, it only takes you days to understand what is meant by a
copy-paste error. You'll excuse me if I am skeptical of your claim.

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

.

Relevant Pages

  • Re: Reading a string of unknown size
    ... Have you ever tried *not* messing up a void * pointer? ... No modern compiler fails to ... that's many hours of debugging waiting to ...
    (comp.lang.c)
  • Re: Reading a string of unknown size
    ... how can it be redundant? ... And the debugger will typically be far less helpful than ... Well to some people type safety is free automated assistance. ... compiler which would spit errors at you for the last line. ...
    (comp.lang.c)
  • Re: Clause "with and use"
    ... I say it's redundant because it doesn't make sense to have "use" ... that implies you're already past ... If the compiler sees "use x", but x is not yet "in scope", ... package will be referred to, so it's for the compiler too. ...
    (comp.lang.ada)
  • Re: Reading a string of unknown size
    ... In other words they are a redundant and unnecessary reexpression of the ... Fragile code is usually much better because it ... rather to manifestations of code written by a less than perfect thinker. ... compiler which would spit errors at you for the last line. ...
    (comp.lang.c)
  • Re: Redundant match clauses (Re: Which programming language is better to start)
    ... > compiler to find *all* redundant match clauses. ... > previous clause (see page 28 in The Definition of Standard ML ...
    (comp.lang.functional)
Loading