Pedants

[jacob navia]

Dear pedantic user

What is a pedant?

According to dictionary.com you are:

1. a person who makes an excessive or inappropriate display of learning.
2. a person who overemphasizes rules or minor details.
3. a person who adheres rigidly to book knowledge without regard to
common sense.

I am very glad that this flag, done for people like you
works as expected.

My compiler system is not for pedants, so you can stop using it
and get a compiler that suits your pedantic needs. Many pedants
here (this group has a lot of them) will point you to their
favorite software.

 

[jacob navia]

Dear pedantic user

What is a pedant?

According to dictionary.com you are:

1. a person who makes an excessive or inappropriate display of learning.
2. a person who overemphasizes rules or minor details.
3. a person who adheres rigidly to book knowledge without regard to
common sense.

I am very glad that this flag, done for people like you
works as expected.

My compiler system is not for pedants, so you can stop using it
and get a compiler that suits your pedantic needs. Many pedants
here (this group has a lot of them) will point you to their
favorite software.

This message should have been sent to the
"Is pedantic a bad flag"
thread...

But anyway, forget it, it is not worth the effort

 

[vippstar]

This message should have been sent to the
"Is pedantic a bad flag"
thread...

But anyway, forget it, it is not worth the effort

I think the person who made the thread is on purpose making threads
about bugs with little importance in your compiler system.
But it would be wiser to ignore the bait and just fix the bugs.

 

[jacob navia]

Excellent. Very amusing.

However, we need to point out that the pedantic beast is not the
probrammer, but the compiler. That poor compiler is stolidly
insisting that the code it compiles be written to match the demands
of the C standard. This has the side-effect of ensuring that the
code actually performs as desired. In most cases this matches the
conscious desires of the programmer.

Yes yes Mr PEDANT.

Obviously it suffices to conform to ISO C and your
program will "perform as desired". Of course.


3. a person who adheres rigidly to book knowledge without regard
to common sense.

 

[jacob navia]

jacob navia said:


Note that dictionary.com is non-normative.

In comp.lang.c, the word "pedant" tends to be used to describe someone who
cares about getting it right, by someone who doesn't.

In that sense, you are using it correctly.

<snip>

1. a person who makes an excessive or inappropriate display of learning.
2. a person who overemphasizes rules or minor details.

 

[Richard]

1. a person who makes an excessive or inappropriate display of learning.
2. a person who overemphasizes rules or minor details.

Also note that Heathfield has not defined "right" here. For many "right"
is something that works well on their target platform. "Right" can even
include cross platform ISO goodness but may not be "perfect" either -
but a timely and economic solution to the problem in hand.

No.

"Pedants" in this group are the anal retentives who are more interested
in showing off their own standard knowledge than actually helping people
get up to speed in good, (sometimes) portable C. This group is
c.l.c. Not ISO C. Not C89. Just "c". And if others want to help others
with "general" C issues then good luck to them.

 

[Ben Bacarisse]

Dear pedantic user

Dear Jacob

What is a pedant?

What is the -pedantic flag? As far as I can see you don't document
the use of it. As such, you can hardly have faced an easier bug to
fix -- just report "bad flag" and ignore it. Of course, if you
intended it to do something then you have a bigger problem.

Rather than getting hot under the collar about it, I think the users
of your compiler would be better served by a simple statement of
intent: accepting the flag is either a simple bug (which you can fix
in about a minute) or you do intend to offer some sort of more
rigorous checking mode and you plan to get it working soon. Would it
not have been simpler just to say which is the case?

 

[Joachim Schmitz]

Dear Jacob


What is the -pedantic flag? As far as I can see you don't document
the use of it. As such, you can hardly have faced an easier bug to
fix -- just report "bad flag" and ignore it. Of course, if you
intended it to do something then you have a bigger problem.

Rather than getting hot under the collar about it, I think the users
of your compiler would be better served by a simple statement of
intent: accepting the flag is either a simple bug (which you can fix
in about a minute) or you do intend to offer some sort of more
rigorous checking mode and you plan to get it working soon. Would it
not have been simpler just to say which is the case?

Some simple rules when dealing with Jacob:

1. Don't attack Jacob, he takes it as personal offense
2. Don't criticize Jajob, he takes it as an attack, see 1.
3. Don't criticise any software Jacob developed, he takes it as personal
criticism, see 2.
4. Don't report bugs in software Jacob developed, he takes it as criticism,
see, 3.

In any case he'll feel personnally offended by any of the above mentioned
things. On top of that:

5. Better don't reply to anything Jacob writes, if there is the slightest
possibility that it might be interpreted in 2 ways, one of which may
possible offending, he'll for sure pick that interpretation and go balistic.
6. If you did reply to Jacob, don't fell offended, when he goes balistic and
calls you a liar for no good reason, this is his normal behavoir, just
ignore it, it's better for your health
7. Never ever expect Jacob ot appologize for any offense he did to you, so
far it never ever happened. Saves you from a disappointement, and is better
for your health.

This should really be added to the CLC FAQ.

Sad, but apparently true...

Bye, Jojo

 

[Joachim Schmitz]

Some simple rules when dealing with critics:

1. If they're criticising your C code, listen to them, make sure
they're right, and - if they are - fix the code.

Guess you meant "make sure _whether_ they are right", otherwise you may need
to introduce bugs just to make them being right

2. Don't forget to thank them for educating them.

guess you meant: "educating _you_"

3. If you can't stand your code being criticised, don't write any.

guess you mean: "don't _publish_ any"

Jacob Navia is not immune to criticism just because he doesn't know
how to handle it properly. One day, he will learn that criticism is
good and useful.

hope dies last, doesn't it?

Bye, Jojo

 

[Richard]

Guess you meant "make sure _whether_ they are right", otherwise you may need
to introduce bugs just to make them being right

guess you meant: "educating _you_"

guess you mean: "don't _publish_ any"

hope dies last, doesn't it?

Bye, Jojo

Smashing job there of being a pedant over Heathfield's pompous pedantry,
advice giving and general lording it.

 

[Walter Roberson]

Dear pedantic user

What is a pedant?

According to dictionary.com you are:

1. a person who makes an excessive or inappropriate display of learning.
2. a person who overemphasizes rules or minor details.
3. a person who adheres rigidly to book knowledge without regard to
common sense.

I am very glad that this flag, done for people like you
works as expected.

"They like me. They really like me!"

 

[santosh]

CBFalconer wrote:

Yes yes Mr PEDANT.

[ ... ]

Why not answer to the post that started all this jacob? If not to "new
to c" (another anonymous "win-lcc troll" I suppose, though they could
be genuine), then at least to the group at large, many of whose lurkers
might well be using win-lcc. Are the "error" messages claimed by the OP
correct? Is this a bug or feature of win-lcc? Does it accept
the '-pedantic' flag? If not, why does it not print a "Unknown command
option" diagnostic?

 

[Joachim Schmitz]

Joachim Schmitz said:


I presume you meant "be right", rather than "being right".

Tribute to english not being my native language

I did, yes. Thanks.


No, I meant "don't write any". Because if you write some code, you'll
want to write some more (programming is very more-ish), and then
you'll write even more, and sooner or later you'll get to the point
where you think you're pretty good, and then some day you'll want to
show someone your stuff. And then they'll criticise it. And that
would be just awful, right?

However: the criticism starts only when you publish

As Doctor Johnson said of a second marriage, "it is the triumph of
hope over experience".

Great , guess I'll steal and use that sooner or later...

Bye, Jojo

 

[Richard]

However Jacob publishes only his binaries. I can't actually remember
seeing any C source by him. He's not one of those people who, like me,
are constantly providing little snippetts.

Which leads us to a philosophical point. Can we tell the quality of
code purely from the binaries?

Yes.

Does it work and do the job it says it does?

Simple really.

 

[santosh]

However Jacob publishes only his binaries. I can't actually remember
seeing any C source by him. He's not one of those people who, like me,
are constantly providing little snippetts.

However I recall him posting various minor snippets of code
occasionally, mainly from his standard library. In the past he used to
post code more often than he does these days.

Which leads us to a philosophical point. Can we tell the quality of
code purely from the binaries?

We must first define what we mean by "quality of code", and this is not
a simple job, as the difference between the source of various versions
of functionally identical programs is largely a subjective matter,
IMHO.

If the binary happens to do correctly all that it is specified to do
under reasonable conditions, then we can say that the binary
is "working", but we still can't say anything much about the source
from examining the machine code. We can attempt a decompilation, but
the resulting source is hardly likely to be better than travesty of the
original source.

Still examining the binary versions of program under a debugger and
under various "stress" conditions, and taking comparative measurements
can enable is to state many objective statements about the machine
code. If the machine code for both the binaries was derived from the
same compiler under the same switches, then differences can be safely
attributed to the source from which it was compiled.

 

[Richard]

However I recall him posting various minor snippets of code
occasionally, mainly from his standard library. In the past he used to
post code more often than he does these days.


We must first define what we mean by "quality of code", and this is not
a simple job, as the difference between the source of various versions
of functionally identical programs is largely a subjective matter,
IMHO.

If the binary happens to do correctly all that it is specified to do
under reasonable conditions, then we can say that the binary
is "working", but we still can't say anything much about the source
from examining the machine code. We can attempt a decompilation, but
the resulting source is hardly likely to be better than travesty of the
original source.

Why do you insist on waffling on about the obvious Santosh? Clearly we
can not look at the source if only the binary is there.

Still examining the binary versions of program under a debugger and
under various "stress" conditions, and taking comparative measurements

What comparative measurements? Comparative against what?

can enable is to state many objective statements about the machine
code. If the machine code for both the binaries was derived from the
same compiler under the same switches, then differences can be safely
attributed to the source from which it was compiled.

So, in less words "if it works its good". The binary testing will tell
you next to nothing about type safety assuming the numbers in the tests
fall into compatible ranges for example.

I would be interested to see what you think you are comparing against here.

 

[Serve Lau]

Why do you insist on waffling on about the obvious Santosh? Clearly we
can not look at the source if only the binary is there.


What comparative measurements? Comparative against what?


So, in less words "if it works its good". The binary testing will tell
you next to nothing about type safety assuming the numbers in the tests
fall into compatible ranges for example.

Take the case of the -pedantic flag not working with math.h. It doesnt say
anything about the quality of the code, it only says something about the
size of compiler system software and the lack of automated testing.

 

[Bartc]

Malcolm McLean skrev:

From a security point of view, using a closed source compiler which hasn't
gone through external code review, is a potential security risk -- as
there can be a trojan horse injected in the compiled programs.

So you have some compiler source, which you then presumably have to compile
with another binary, which must also be open source...

So where do you start? It seems that at some point you need to use a trusted
binary.

 

[santosh]

So you have some compiler source, which you then presumably have to
compile with another binary, which must also be open source...

So where do you start? It seems that at some point you need to use a
trusted binary.

No need. The BIOS could be open source and the hardware specs could also
be open source. This way nothing inside the computer is beyond
understanding, but this is not commonly the case. An average PC
contains tons of closed source firmware, which *could* do subversive
things, even if the OS and applications were to be open source.

Also even if a program is open source, to be absolutely sure, you need
to check the complete source for the program and compile it yourself.
Otherwise there is no guarantee that a binary of an "open source"
program that you download and use does not contain components in
additions to it's published source base.

 

[Tony Quinn]

So you have some compiler source, which you then presumably have to compile
with another binary, which must also be open source...

So where do you start? It seems that at some point you need to use a trusted
binary.

Have you read this?

http://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thompson.pdf