C: The Complete Meta-Nonsense

[Richard Tobin]

Apparently (and I got this indirectly), to "moot" an issue is to bring
it up for discussion in UK English. Or at least sometimes is.

The American use, which is also common in Britain, is just an
extension of this. The idea is that if a point is moot, it's subject
to debate, rather than being capable of being definitively settled.
The negative connotations of this (irrelevant; unimportant; no one's
opinion more valuable than anyone else's) have become dominant in the
same way that those of "academic" have.

-- Richard

 

[John Kelly]

It doesn't do anything useful, and it is potentially misleading, in
that it appears to be a safety check but in fact is nothing of the
kind. I'd call that a bug. Obviously you wouldn't.

It's documentation that executes. I wonder why the infinitesimally
small execution penalty bothers anyone.

How is it misleading? Why would assert() be better?

 

[Ian Collins]

It's documentation that executes. I wonder why the infinitesimally
small execution penalty bothers anyone.

How is it misleading? Why would assert() be better?

It's the same as writing if (512 < 3), which isn't a lot of uses to
anyone, is it?

 

[John Kelly]

Yes. The documentation can be loosely translated as "the writer of
this code doesn't understand sizeof".

No, you don't understand the intent of the author. I understand sizeof
just fine.

It wouldn't. Complete absence would be better.

No. With ts[512] the sizeof comparison will always be false. But with
ts[2] the error will be triggered. It's open source. You can't promise
me no one will ever change the code to use a buffer too small.

It's a specification check that documents the North pipe error protocol
and buffer size requirement. Read the explanation under "Define ideas."

 

[John Kelly]

It's the same as writing if (512 < 3), which isn't a lot of uses to
anyone, is it?

No, it's not. See my reply to RH.

 

[Ian Collins]

Yes. The documentation can be loosely translated as "the writer of
this code doesn't understand sizeof".

No, you don't understand the intent of the author. I understand sizeof
just fine.

It wouldn't. Complete absence would be better.

No. With ts[512] the sizeof comparison will always be false. But with
ts[2] the error will be triggered. It's open source. You can't promise
me no one will ever change the code to use a buffer too small.

It's a specification check that documents the North pipe error protocol
and buffer size requirement. Read the explanation under "Define ideas."

In that case, use a compile time constant and check, rather than magic
numbers.

#define SIZ 512

#if SIZ < 512
# error "bugger"
#endif

What platform was you code targeted at? It appears to have several
undefined variables (opterr for one).

 

[John Kelly]

In that case, use a compile time constant and check, rather than magic
numbers.

#define SIZ 512

#if SIZ < 512
# error "bugger"
#endif
Why?


What platform was you code targeted at? It appears to have several
undefined variables (opterr for one).

Compiles on Linux and NetBSD 5.0.1. Did you use the Makefile? What
platform and OS?

 

[Ian Collins]

Why?

Clear documentation that executes (at compile time). Or are you asking
why not to use magic numbers?

Compiles on Linux and NetBSD 5.0.1. Did you use the Makefile? What
platform and OS?

OpenSolaris, no Makefile, but same options.

 

[Seebs]

It's documentation that executes. I wonder why the infinitesimally
small execution penalty bothers anyone.

I don't think anyone cares about the performance.

How is it misleading? Why would assert() be better?

Either you believe that the test's result could conceivably change at
runtime, or it is misleading.

-s

 

[Seebs]

The American use, which is also common in Britain, is just an
extension of this. The idea is that if a point is moot, it's subject
to debate, rather than being capable of being definitively settled.
The negative connotations of this (irrelevant; unimportant; no one's
opinion more valuable than anyone else's) have become dominant in the
same way that those of "academic" have.

Around here, if I say a point is "moot", I am asserting that it's completely
irrelevant and not worth discussing. So, yeah, the negative connotations have
pretty much won. I would never have imagined that it implied that the issue
was open to debate, only that there was no point in talking about it.

Classic example from Bloom County. Kids are doing show and tell. One
announces that he's proven that a giant asteroid will destroy all life
on earth within four weeks. The next says that his hamster is pregnant, and
concludes "a moot point at best."

-s

 

[John Kelly]

Clear documentation that executes (at compile time). Or are you asking
why not to use magic numbers?

Just inviting your point of view.

OpenSolaris, no Makefile, but same options.

Don't know about opterr on Solaris. But I read Solaris does not have
flock() semantics like Linux or BSD. If that's true it can't work on
Solaris without rethinking the use of flock(), and I have no incentive
to move in that direction.

 

[John Kelly]

I don't think anyone cares about the performance.

Either you believe that the test's result could conceivably change at
runtime, or it is misleading.

I'll talk to you if you promise not to have more tantrums.

I suppose I could make it a compile time test. But I'm busy. Somebody
send me a patch.

 

[Seebs]

I'll talk to you if you promise not to have more tantrums.

I have yet to see any tantrums.

I suppose I could make it a compile time test. But I'm busy. Somebody
send me a patch.

Why?

Again, there's better programs out there that do this already. It's also
not something I've particularly needed very often; I only know that programs
to do this exist because I was debugging some system startup scripts once.
Total times I've needed a program to do this: 0.

-s

 

[Nick]

Why?

Well if I'm playing round with code I'd much rather get a compile time
than a run-time error if I've changed a constant out of range.

For me, and I suspect anyone else changing your code, just a comment
saying "SIZ must always be in the range nnn to mmm" right by the #define
would be fine. You can't build compile, let alone execute, tests for
any changes people might make that would break the code. Imagine trying
to protect against someone renaming one of your functions!

Anyone who changes a constant beyond the range documented in the source
is either irredeemably stupid (in which case they'll just remove your
check and continue anyway) or knows what they are doing and are making
major changes (in which case they'll just remove your check and continue
anyway).

 

[John Kelly]

But it's no easier for other people than for you. You obviously care
about the program. Obviously nobody else does. So who do you think is
going to maintain it for you?

Like Seebs, you say the same thing again and again. If I can't learn
anything from you, I will ignore you. You can keep flaming me, and I
can keep posting my link to dh.

There exist people who don't follow you, Seebs, or any other regulars
here. Imagine that.

This may go on until one of us tires out from old age.

 

[Kenny McCormack]

Like Seebs, you say the same thing again and again. If I can't learn
anything from you, I will ignore you. You can keep flaming me, and I
can keep posting my link to dh.

Yes, the sheer mind-numbing repetitiveness of most of the regs here is
truly something to be seen to be believed.

There exist people who don't follow you, Seebs, or any other regulars
here. Imagine that.

Agreed. But they certainly do have their little coteries, don't they?

This may go on until one of us tires out from old age.

This is really the funny thing. I don't imagine that I will be posting
to clc in my dotage, because clearly, I've got better things to do (as
do you). But I can just see Seebs, Dicky, and Kiki posting here, 20,
30, 50 years from now. And on the same old subjects - prototyping
main(), (not) casting the return value from malloc, and why i=i++ is
wrong. On and on. On and on.

 

[John Kelly]

This is really the funny thing. I don't imagine that I will be posting
to clc in my dotage, because clearly, I've got better things to do (as
do you). But I can just see Seebs, Dicky, and Kiki posting here, 20,
30, 50 years from now. And on the same old subjects - prototyping
main(), (not) casting the return value from malloc, and why i=i++ is
wrong. On and on. On and on.

If only they would stick to answering questions, and overcome their
jealous hate. But that seems not likely.

 

[Nick]

Yes, the sheer mind-numbing repetitiveness of most of the regs here is
truly something to be seen to be believed.


Agreed. But they certainly do have their little coteries, don't they?


This is really the funny thing. I don't imagine that I will be posting
to clc in my dotage, because clearly, I've got better things to do (as
do you). But I can just see Seebs, Dicky, and Kiki posting here, 20,
30, 50 years from now. And on the same old subjects - prototyping
main(), (not) casting the return value from malloc, and why i=i++ is
wrong. On and on. On and on.

I've only been posting here for a week, and I don't think I've seen you
say /anything/ about C. In fact, I don't think you've written anything
that isn't an attack on a handful of people you've got some sort of bee
in your bonnet about.

Whatever you might say (and it seems to be a hell of a lot) about people
like - say - Seebs, when I came here with C (remember C?) question he
came back with a really useful explanation of what I wanted help on, and
a suggestion of an even more useful way to do what I wanted to, if I
chose to take it up.

Yes, people can get a bit pernickety - and clearly people have let the
constant sniping at them get to them. But if people keep /asking/ about
i=i++ (as someone has done in the last couple of days) what are they
meant to do but answer?

As I say, I'm a genuine newcomer here, and I can see who is adding value
and who is a source of pure noise. And I'm afraid you're on the right
hand side of that division at the moment.

 

[John Kelly]

Whatever you might say (and it seems to be a hell of a lot) about people
like - say - Seebs, when I came here with C (remember C?) question he
came back with a really useful explanation of what I wanted help on, and
a suggestion of an even more useful way to do what I wanted to, if I
chose to take it up.

As I say, I'm a genuine newcomer here, and I can see who is adding value
and who is a source of pure noise.

PS and RH are friendly to newcomers, but they're also control freaks.
Kenny sometimes provides moral support to those who dare disagree with
them. That's a service too.

 

[Nick]

PS and RH are friendly to newcomers, but they're also control freaks.
Kenny sometimes provides moral support to those who dare disagree with
them. That's a service too.

So nothing about C then?