Pedants
jacob navia
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
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32
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
vipp...@gmail.com
> jacob navia wrote:
> > 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
about bugs with little importance in your compiler system.
But it would be wiser to ignore the bait and just fix the bugs.
Tor Rustad
> 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.
I find it odd that a C compiler maintainer, care more for his HTML, than
his C code.
http://www.cs.virginia.edu/~lcc-win32/ validate to HTML 4.01 Strict!:
Congratulations
The document located at <http://www.cs.virginia.edu/~lcc-win32/> was
checked and found to be valid HTML 4.01 Strict. This means that the
resource in question identified itself as "HTML 4.01 Strict" and that we
successfully performed a formal validation using an SGML or XML Parser
(depending on the markup language used).
"valid" Icon(s) on your Web page
To show your readers that you have taken the care to create an
interoperable Web page, you may display this icon on any page that
validates. Here is the HTML you could use to add this icon to your Web
page:
--
Tor <bwz...@wvtqvm.vw | tr i-za-h a-z>
Richard Heathfield
> 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.
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>
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
CBFalconer
>
> 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.
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.
--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.
** Posted from http://www.teranews.com **
jacob navia
> jacob navia wrote:
>> 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.
>
> 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:
>
>> 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.
>
> 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
> Richard Heathfield wrote:
>> jacob navia said:
>>
>>> 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.
>>
>> 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.
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?
--
Ben.
Joachim Schmitz
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
Richard Heathfield
<snip>
> 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.
<etc snipped>
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.
2. Don't forget to thank them for educating them.
3. If you can't stand your code being criticised, don't write 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. Until then, his rants and raves will no doubt continue, but so
what?
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.
to introduce bugs just to make them being right 8-)
> 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
Smashing job there of being a pedant over Heathfield's pompous pedantry,
advice giving and general lording it.
Richard Heathfield
> Richard Heathfield wrote:
>> 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 8-)
I presume you meant "be right", rather than "being right". :-)
>> 2. Don't forget to thank them for educating them.
> guess you meant: "educating _you_"
I did, yes. Thanks.
>
>> 3. If you can't stand your code being criticised, don't write any.
> guess you mean: "don't _publish_ any"
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?
>> 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?
As Doctor Johnson said of a second marriage, "it is the triumph of hope
over experience".
santosh
> CBFalconer wrote:
<snip>
> 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?
Walter Roberson
>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!"
--
"There's no term to the work of a scientist." -- Walter Reisch
Joachim Schmitz
> Joachim Schmitz said:
>
>> Richard Heathfield wrote:
>>> 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 8-)
>
> I presume you meant "be right", rather than "being right". :-)
>>> 2. Don't forget to thank them for educating them.
>> guess you meant: "educating _you_"
>
> I did, yes. Thanks.
>
>>
>>> 3. If you can't stand your code being criticised, don't write any.
>> guess you mean: "don't _publish_ any"
>
> 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
>>> 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?
>
> As Doctor Johnson said of a second marriage, "it is the triumph of
> hope over experience".
Great 8-), guess I'll steal and use that sooner or later...
Bye, Jojo
Malcolm McLean
> Richard Heathfield wrote:
>> Joachim Schmitz said:
>>
>>
>> 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
>
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?
--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm
Richard
Yes.
Does it work and do the job it says it does?
Simple really.
santosh
> "Joachim Schmitz" <nospa...@schmitz-digital.de> wrote in message n
>> Richard Heathfield wrote:
>>> Joachim Schmitz said:
>>>
>>>
>>> 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
>>
> 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
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.
Tor Rustad
> Which leads us to a philosophical point. Can we tell the quality of code
> purely from the binaries?
Yup, black box testing can detect quite a number of defects. For C
compilers, Perennial & Plum Hall has validation test suits, mandatory
for UNIX 03 certification.
A C compiler, is like a batch program... I find lots of programs harder
to test than "batch" like programs. :)
Code review, in particular when done here, is also an interesting
experience, not to be recommended for certain category of "professionals".
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.
Serve Lau
"Richard" <rgr...@gmail.com> schreef in bericht
news:g3j9k7$f69$5...@registered.motzarella.org...
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
"Tor Rustad" <tor_r...@hotmail.com> wrote in message
news:08qdneqrndh...@telenor.com...
> Malcolm McLean skrev:
>
>> Which leads us to a philosophical point. Can we tell the quality of code
>> purely from the binaries?
> 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.
--
bartc
santosh
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.
Tor Rustad
Thompson has a classic paper on the subject, I would rank his compiler
hack among the top 10 of all time.
We simply trust major organizations to have sufficient QA to detect
injection of trojans. I believe there was a case some years ago, when
someone had injected a backdoor in the GNU GCC sources, which was
detected by the public.
Lots of people argue compilers should be banned from production systems,
but I can't agree with this. Test systems has less trust, and if someone
is able to modify the compiler there, and it is used to build production
programs, the attacker/insider can be able to get access to higher
privilege level, without being authorized for it.
Tony Quinn
<b...@freeuk.com> writes
Have you read this?
http://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thompson.pdf
--
If one person has delusions, we call them psychotic. If, however, 1.5 billion
people have delusions we must apparently call them a religious group, and
respect their delusionary state.
santosh
Take the case of two binary programs that are specified to do exactly
the same task and with identical interfaces. Further assume that both
were compiled by the same compiler program and with identical compiler
options (except for things like source file naming of course). We shall
also execute both the programs under as similar a condition as
possible.
Now if program A takes twice as long to perform some task as program B,
what does that suggest to us about their respective sources? If we
disassemble two functionally identical routines in both the programs
and we observe the following pseudo-assembler for program A:
LOAD r0, [BP + 8]
LOAD r1, 0
loop:
PUSH [r0 + r1]
CMP [SP], 0
JE ret
CALL _putchar
ADD SP, 1
INC r1
JUMP loop
ret:
ADD SP, 1
RET
and the following for program B:
PUSH stdout
PUSH [BP + 8]
CALL _fputs
ADD SP, 8
RET
What can you conclude about the source for the respective programs?
There are many other similar comparative measurements and examinations
of the binaries that can be done to suggest the possible nature of the
original source code, provided the conditions of translation and
execution were and are "similar enough."
CBFalconer
>
... snip ...
>
> 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?
Well, his principal item is labelled as a 'C compiler', which has a
fairly strict published standard, casually known as the C99
standard. This gives us an easily applied criterion - simply
report all failures to comply with that C standard.
santosh
> Malcolm McLean wrote:
>>
> ... snip ...
>>
>> 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?
>
> Well, his principal item is labelled as a 'C compiler', which has a
> fairly strict published standard, casually known as the C99
> standard. This gives us an easily applied criterion - simply
> report all failures to comply with that C standard.
Bugs in the binary tell us about possible bugs in the source, which is
one indication of the "quality" of the source code, but beyond that one
needs to examine the disassembly of the program and examine it's
machine code and performance against a functionally identical,
identically compiled, "control" program, to say more about
the "quality" of the source code.
Malcolm McLean
> Now if program A takes twice as long to perform some task as program B,
> what does that suggest to us about their respective sources?
>
So what exactly does it suggest?
Bob Nelson
> [..] 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.
And since is it ``just c'', so it must be -- ``just C'', which by definition
is the C language as standardized by ISO/IEC. Any other variant is not
``just C'' but is platform-specific and not at all ``general C''.
I personally take an even more purist approach of what should be acceptable
in this newsgroup than what's now tolerated by even some of the so-called
``regulars'' of the current era. My preference (and realize it's only that)
would be to not qualify a response to an off-topic post with such wording
as:
``That's not REALLY a question about standard C.''
I would modify it as follows:
``That's not AT ALL a question about C.''
The intent is to emphasize that C is, without otherwise being modified, that
which is defined by ISO/IEC.
I find this well-known image appropriate when I see a posting about clearing
the screen, writing to the Windows registry, reading directories and other
such off-topic atrocities here in c.l.c:
santosh
> "santosh" <santo...@gmail.com> wrote in message
>>
>> Now if program A takes twice as long to perform some task as program
>> B, what does that suggest to us about their respective sources?
>>
> Often there is a tension between efficient and well-structured
> programming.
>
> So what exactly does it suggest?
I see your point. Efficiency (both speed and resources consumed) is one
aspect of "quality of code". With quite a bit of assumptions, you can
also make other statements about the source code from inspecting the
disassembly. See my reply to Richard Riley. But the complexity of the
compiler makes it virtually impossible to say anything more than a few
bare observations about the source.
Ian Collins
8. Even when proved wrong by example, we will never admit to being
wrong. See 1.
--
Ian Collins.
jacob navia
> The intent is to emphasize that C is, without otherwise being modified, that
> which is defined by ISO/IEC.
>
> I find this well-known image appropriate when I see a posting about clearing
> the screen, writing to the Windows registry, reading directories and other
> such off-topic atrocities here in c.l.c:
>
Yeah sure.
C is ISO C. Posix doesn't exist. Windows doesn't exist, the
Mac doesn't exist.
Network programming? Off topic.
GUI programming? Off topic.
There isn't a single interesting software written in ISO C.
But you and your friends have succeeded in destroying this group.
Who posts here?
Students too lazy to do their homework.
Regulars speaking about their favorite subject:
int main (void);
All people with an interest in language development, software
development are gone. You won. All people with a real interest
in developing the language are gone.
C is seen as a dead language that only students learning to program
or die hards, outmoded, old programmers use.
Any discussion about language development is killed. C++ is the
way, C is dead, go away. Let's go on forever insisting in
void main(void);
THAT is important.
ISO C is the best of all worlds. Long live gets() asctime() and other
ABOMINATIONS!!!
Compared to that PILE OF SHIT the registry hacks are NOTHING my
friend.
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32
jacob navia
> I see your point. Efficiency (both speed and resources consumed) is one
> aspect of "quality of code".
Lcc-win is the smallest compiler system in the C world.
It is around 5 times faster than gcc in compilation
time, and in execution time it is approx 75-85% of the
speed of the gcc generated code.
This are facts. Easily measurable by anyone.
Richard Heathfield
> santosh wrote:
>> I see your point. Efficiency (both speed and resources consumed) is one
>> aspect of "quality of code".
>
> Lcc-win is the smallest compiler system in the C world.
> It is around 5 times faster than gcc in compilation
> time, and in execution time it is approx 75-85% of the
> speed of the gcc generated code.
>
> This are facts. Easily measurable by anyone.
If the program doesn't have to work properly, I can easily write a compiler
system that is a thousand times smaller than yours and a thousand times
faster. There is more to quality than speed and size.
jacob navia
> jacob navia said:
>
>> santosh wrote:
>>> I see your point. Efficiency (both speed and resources consumed) is one
>>> aspect of "quality of code".
>> Lcc-win is the smallest compiler system in the C world.
>> It is around 5 times faster than gcc in compilation
>> time, and in execution time it is approx 75-85% of the
>> speed of the gcc generated code.
>>
>> This are facts. Easily measurable by anyone.
>
> If the program doesn't have to work properly, I can easily write a compiler
> system that is a thousand times smaller than yours and a thousand times
> faster. There is more to quality than speed and size.
>
If you have nothing to say. Please do not say it here.
The "pedantic" flag is no longer supported, and if you invoke
lcc -pedantic pedantic.c
you get:
"Pedants are no longer supported!"
and the program exits!
:-)
Obviously the fact that lcc-win is much faster than gcc
or other compilers doesn't count. What counts is if it
supports c89 or maybe another more obsolete version of the language.
Bartc
"Richard Heathfield" <r...@see.sig.invalid> wrote in message
news:Y_qdnVevW4HH68DV...@bt.com...
> jacob navia said:
>
>> santosh wrote:
>>> I see your point. Efficiency (both speed and resources consumed) is one
>>> aspect of "quality of code".
>>
>> Lcc-win is the smallest compiler system in the C world.
>> It is around 5 times faster than gcc in compilation
>> time, and in execution time it is approx 75-85% of the
>> speed of the gcc generated code.
>>
>> This are facts. Easily measurable by anyone.
>
> If the program doesn't have to work properly, I can easily write a
> compiler
> system that is a thousand times smaller than yours and a thousand times
> faster. There is more to quality than speed and size.
I think you're being too hard on this compiler (which I happen to use in
preference to half-a-dozen others).
You seem to be saying that a product has to be 100% perfect or it's not
worth bothering with. Surely many other compilers at some point must have
been less than 100%, but if people simply walked away from them, they would
never have progressed.
This particular problem, using -pedantic switch on math.h in lccwin: if you
look at gcc's math.h (3.4.5 or 4.3.1):
#if __GNUC__ >= 3
#pragma GCC system_header
#endif
It sort of looks like gcc had to do use some hackery in order to compile
system headers without generating errors or warnings. It also looks like gcc
versions before 3.0 may have had similar problems to lcc-win...
--
Bartc
Richard Heathfield
> Bob Nelson wrote:
>> The intent is to emphasize that C is, without otherwise being modified,
>> that which is defined by ISO/IEC.
>>
>> I find this well-known image appropriate when I see a posting about
>> clearing the screen, writing to the Windows registry, reading
>> directories and other such off-topic atrocities here in c.l.c:
>
> Yeah sure.
Careful of that sarcasm. You're no good at it.
>
> C is ISO C. Posix doesn't exist. Windows doesn't exist, the
> Mac doesn't exist.
C exists, and has a newsgroup called comp.lang.c (among others).
POSIX exists, and has a newsgroup called comp.unix.programmer (among
others, no doubt).
Windows exists, and has a newsgroup called
comp.os.ms-windows.programmer.win32 (among others).
The Mac exists, and has a newsgroup called comp.sys.mac.programmer (among
others).
The fact that something isn't topical here doesn't mean it doesn't exist.
> Network programming? Off topic.
Right, but don't forget that it's on topic in groups that deal with
platform-specific issues.
> GUI programming? Off topic.
Right, but don't forget that it's on topic in groups that deal with
platform-specific issues.
> There isn't a single interesting software written in ISO C.
By the same reasoning, there is no milk in my refrigerator (because you've
never seen my fridge and therefore never seen any milk there, it can't
exist). Likewise, there is no such thing as the United States (because
I've never seen it), and of course there's no such thing as the Earth's
core (because nobody has ever seen it), which means we'll all be dead just
as soon as gravity remembers.
> But you and your friends have succeeded in destroying this group.
The destructive influence has been from those who don't understand what C
is and don't understand the compartmentalisation of Usenet into different
subject areas.
> Who posts here?
>
> Students too lazy to do their homework.
> Regulars speaking about their favorite subject: int main (void);
You forgot:
Compiler-writers too stupid to do their own thinking.
> All people with an interest in language development, software
> development are gone.
No, they're still around - but they understand about subject
compartmentalisation. They discuss language development in language
development groups, software development in software development groups,
and C in C groups.
> You won. All people with a real interest
> in developing the language are gone.
...to comp.std.c, where language development issues are discussed. The
comp.lang.c group is not /for/ discussing language development. It's for
discussing the C language that actually exists.
> C is seen as a dead language that only students learning to program
> or die hards, outmoded, old programmers use.
By you perhaps, but not by everyone. You don't get to choose how other
people view C.
> Any discussion about language development is killed. C++ is the
> way, C is dead, go away.
"Please discuss this somewhere where it is topical" and "C++ is the way, C
is dead, go away" are very different statements. Your associating them
demonstrates more about your muddy thinking than it does about topicality,
C++, C, or politeness.
> Let's go on forever insisting in
>
> void main(void);
No, let's not, because it's incorrect.
> THAT is important.
It's important to get stuff right, and that includes the easy stuff as well
as the hard stuff.
> ISO C is the best of all worlds.
You should stop trying to be sarcastic. You're no good at it.
ISO C is a compromise, a way of making it possible to write once and run on
many disparate systems. Compromises are rarely the best of all possible
worlds. But until you can get all the computer manufacturers to agree on a
single architecture that they will always use from now on forever, we're
going to need a compromise if we want our stuff to run on lots of
different machines. So that's why ISO C is useful.
If you don't need your code to run on lots of different machines, you can
afford to be a bit more relaxed. But to pretend that those other machines
aren't out there and aren't important is just silly.
> Long live gets() asctime() and other ABOMINATIONS!!!
Stick to slapstick. From you, it's funnier.
> Compared to that PILE OF SHIT the registry hacks are NOTHING my
> friend.
When you introduce scatological terms into the discussion, I can only
assume it's because you have nothing more intelligent to say.
If you think comp.lang.c is a total loss, why post here? I'm not saying you
shouldn't post here - that's your decision, not mine - but you don't seem
terribly happy here. Since your favourite topic of conversation is
lcc-win32, why not post in a group dedicated to that topic? That should
cheer you up no end.
Tor Rustad
> Bartc wrote:
>
>> "Tor Rustad" <tor_r...@hotmail.com> wrote in message
>> news:08qdneqrndh...@telenor.com...
>>> Malcolm McLean skrev:
>>>
>>>> Which leads us to a philosophical point. Can we tell the quality of
>>>> code purely from the binaries?
>>> 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.
>
> No need. The BIOS could be open source and the hardware specs could also
> be open source.
Well, in theory there might be no need, but in practice we don't (just)
analyze the binaries, but perform internal and external code audits of
sources. It is far easier to detect backdoors prior to compilation.
This is needed for trust-wordy systems.
Reviews are getting more important, and a number of OS'es has EAL 4
certifications these days, including SLES 10, RH 5, and soon Microsoft
have a number of such certificates too.
http://en.wikipedia.org/wiki/Evaluation_Assurance_Level
Nevertheless, software engineering has yet a long way to go, when it
comes to quality, good thing we ain't making tall buildings... :)
> 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.
Well, there are a number of OS'es, which are open source, they don't
exactly have "tons" of binary blobs originating from closed 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.
If the source is public, then code review can be done by many. Anyway,
by taking a peek at the source, it is normally not that hard to see how
well designed a program is.
The track record on number of bugs, also indicate what quality level a
program has. For example, that OpenBSD and the Linux kernel are high
quality, shows IMO on their track record.
> 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.
That is not correct santosh, if the binaries was build on a trusted
system, the binaries could be digitally signed there too, and then
verified prior to installation on the target machine.
However, as long as the target machine lack any kind of HW verification
method, a Trojan horse or root kit, can invalidate this verification.
Richard Heathfield
> Richard Heathfield wrote:
>> jacob navia said:
>>
>>> santosh wrote:
>>>> I see your point. Efficiency (both speed and resources consumed) is
>>>> one aspect of "quality of code".
>>> Lcc-win is the smallest compiler system in the C world.
>>> It is around 5 times faster than gcc in compilation
>>> time, and in execution time it is approx 75-85% of the
>>> speed of the gcc generated code.
>>>
>>> This are facts. Easily measurable by anyone.
>>
>> If the program doesn't have to work properly, I can easily write a
>> compiler system that is a thousand times smaller than yours and a
>> thousand times faster. There is more to quality than speed and size.
>>
>
> If you have nothing to say. Please do not say it here.
Just because you don't understand me, that doesn't mean I have nothing to
say.
> The "pedantic" flag is no longer supported, and if you invoke
>
> lcc -pedantic pedantic.c
>
> you get:
>
> "Pedants are no longer supported!"
That's an implementation issue, and as such should be discussed in a
newsgroup where that implementation is topical, such as comp.compilers.lcc
> and the program exits!
Fine, but hardly topical here.
> :-)
>
> Obviously the fact that lcc-win is much faster than gcc
> or other compilers doesn't count.
Not in comp.lang.c, no, where we discuss the language, not implementations
thereof. If you want to race compilers, please do it in a newsgroup where
it's topical.
But for the record, no, if the compiler *doesn't work*, it doesn't matter
how fast it is - same as with any program.
> What counts is if it
> supports c89 or maybe another more obsolete version of the language.
No, what counts is that it is an implementation, and therefore needs to be
discussed in a group where it is topical, rather than here, where we
discuss the language itself, not implementations thereof. I do not expect
you to understand this because, on the many previous occasions that I have
explained it to you, you have demonstrated yourself to be incapable of
grasping the point. Nevertheless, I hope others will understand it and
take note.
But the bottom line is that a C compiler has to translate C programs
correctly. If it can't do that, it isn't really a C compiler. And you
don't get to decide what C is, any more than I do.
Richard Heathfield
>
> "Richard Heathfield" <r...@see.sig.invalid> wrote in message
> news:Y_qdnVevW4HH68DV...@bt.com...
>> jacob navia said:
>>
>>> santosh wrote:
>>>> I see your point. Efficiency (both speed and resources consumed) is
>>>> one aspect of "quality of code".
>>>
>>> Lcc-win is the smallest compiler system in the C world.
>>> It is around 5 times faster than gcc in compilation
>>> time, and in execution time it is approx 75-85% of the
>>> speed of the gcc generated code.
>>>
>>> This are facts. Easily measurable by anyone.
>>
>> If the program doesn't have to work properly, I can easily write a
>> compiler
>> system that is a thousand times smaller than yours and a thousand times
>> faster. There is more to quality than speed and size.
>
> I think you're being too hard on this compiler (which I happen to use in
> preference to half-a-dozen others).
>
> You seem to be saying that a product has to be 100% perfect or it's not
> worth bothering with.
No, I'm not saying that at all. If you think that, you need to read what
I've said more carefully.
I also think you need to take note of the fact that, when santosh raised
the point of "quality of code", Mr Navia immediately responded with
statements about *performance*, whereas the point of this thread, if there
is one, is correctness, not performance.
Anyway, to answer your point: if this -pedantic thing were the only issue
with lcc-win32, that would make it an absolutely outstanding compiler. But
it isn't. We have seen many issues with lcc-win32 raised over the last few
months, and we have witnessed the reaction of the author to each new
revelation. "Thanks, I'll try to fix that"? No. "Thanks, I have no time to
fix that right now, but I'll add it to the bug list"? No. "I am under
attack"? You got it.
If I were using lcc-win32 (which I'm not, btw), I'd be very, very worried
that the principal (or possibly the only) maintainer of lcc-win32 is
someone with such a bizarre attitude to bug reports.
> This particular problem, using -pedantic switch on math.h in lccwin: if
> you look at gcc's math.h (3.4.5 or 4.3.1):
>
> #if __GNUC__ >= 3
> #pragma GCC system_header
> #endif
>
> It sort of looks like gcc had to do use some hackery in order to compile
> system headers without generating errors or warnings. It also looks like
> gcc versions before 3.0 may have had similar problems to lcc-win...
I'm using 2.95.3 and -pedantic works just fine.
Tor Rustad
> "Richard Heathfield" <r...@see.sig.invalid> wrote in message
[...]
>> If the program doesn't have to work properly, I can easily write a
>> compiler
>> system that is a thousand times smaller than yours and a thousand times
>> faster. There is more to quality than speed and size.
>
> I think you're being too hard on this compiler (which I happen to use in
> preference to half-a-dozen others).
No, Richard Heathfield is not too hard, if a compiler can't be trusted,
it shouldn't be used for anything serious.
First step is doing the job right, adding new features, will increase
the complexity, make testing harder and most likely increase the number
of defects.
How fast a C compiler runs, say very little about the correctness of the
translation.
Bob Nelson
> Bob Nelson wrote:
>
>> The intent is to emphasize that C is, without otherwise being modified,
>> that which is defined by ISO/IEC.
>>
>> I find this well-known image appropriate when I see a posting about
>> clearing the screen, writing to the Windows registry, reading directories
>> and other such off-topic atrocities here in c.l.c:
>
> Yeah sure.
>
> C is ISO C. Posix doesn't exist. Windows doesn't exist, the
> Mac doesn't exist.
An examination of WG14/N1256 ``Committee Draft -- September 7, 2007''
ISO/IEC 9899:TC3, finds there is no mention (that I could find) of the
word ``computer'' in the document.
Therefore, although POSIX, Windows and the Mac do exist, they are not within
the scope of discussing the C language. The international standard deals
only with the behavior of an abstract machine.
Postings confined to matters involving translation unit(s) in ISO C are a
rich source of interesting material for this newsgroup. Subjects involving
POSIX, Windows and the Mac have appropriate venues elsewhere. The name of
the newsgroup says it all: comp.lang.c. This is a forum for the language C.
Mr. Navia: I know that you and Mr. Heathfield have, on more than one
occasion, had differences. You may take some small solace in knowing that I
believe that I may disagree with Mr. Heathfield concerning C99.
The standard for the C language is no longer C90 but is C99. Therefore, in
my opinion, any discussion in this newsgroup concerning C90 is only of
historic interest (much like that of K&R C or dmr's earlier
implementations). While topical, they do not deal with current C as defined
by the international standard.
Thus the following little snippet, presuming a hosted implementation, of a
translation unit *is* C -- period (modulo a botch of my part when pasting
this):
#include <string.h>
#include <stdio.h>
int main(void)
{
char s[strlen("42") + 1]; // variable length array, standard conforming
strcpy(s, "42");
for(int i = 0; i < 2; ++i)
puts(s);
// the C language returns 0 upon reaching } [5.1.2.2.3]
}
Perhaps giving credence to arguments about the [lack of?] utilitarian value
of c.l.c., I don't care one iota about how widely used, popular or how many
implementations there are of C99 translators. Since C99 == C, that's
sufficient for me. Anything else is merely a QOI matter of little concern
when the focus is solely on the C language.
But to end this posting amicably, I admit to being a unapologetic purist and
probably an unrepentant pedant. If this draws the ire of both Mr. Navia and
Mr. Heathfield, then perhaps we have achieved peace in our time. :-)
Richard Heathfield
<lots of good stuff (or should I say 'other good stuff'?) snipped>
> Postings confined to matters involving translation unit(s) in ISO C are a
> rich source of interesting material for this newsgroup. Subjects
> involving POSIX, Windows and the Mac have appropriate venues elsewhere.
> The name of the newsgroup says it all: comp.lang.c. This is a forum for
> the language C.
Right.
>
> Mr. Navia: I know that you and Mr. Heathfield have, on more than one
> occasion, had differences. You may take some small solace in knowing that
> I believe that I may disagree with Mr. Heathfield concerning C99.
It's possible.
> The standard for the C language is no longer C90 but is C99.
C99 is the de jure standard, but it won't become the de facto standard
until it is at least comparatively widely implemented (by which I mean
that it must be implemented on at least /almost/ as many mainstream
architectures as C90.
> Therefore,
> in my opinion, any discussion in this newsgroup concerning C90 is only of
> historic interest (much like that of K&R C or dmr's earlier
> implementations). While topical, they do not deal with current C as
> defined by the international standard.
I agree that C90 is topical, of course, and I agree that it doesn't deal
with "C as defined by the [current] international standard" - but it's of
more than historic interest until such time as C99 becomes the de facto
standard.
> Thus the following little snippet, presuming a hosted implementation, of
> a translation unit *is* C -- period (modulo a botch of my part when
> pasting this):
<snip>
Yes, C99 is C! Believe it or not, I do agree with that.
<snip>
> Perhaps giving credence to arguments about the [lack of?] utilitarian
> value of c.l.c., I don't care one iota about how widely used, popular or
> how many implementations there are of C99 translators.
That is perhaps the difference between us. I like a language I can actually
use. But your point is valid and well-made.
<snip>
> But to end this posting amicably, I admit to being a unapologetic purist
> and probably an unrepentant pedant. If this draws the ire of both Mr.
> Navia and Mr. Heathfield, then perhaps we have achieved peace in our
> time. :-)
It seems that peace in our time may have to wait a little. :-)
Bob Nelson
> Bob Nelson said:
>
> [...]
>
>> The standard for the C language is no longer C90 but is C99.
>
> C99 is the de jure standard, but it won't become the de facto standard
> until it is at least comparatively widely implemented (by which I mean
> that it must be implemented on at least /almost/ as many mainstream
> architectures as C90.
My daily commute on Stemmons Freeway in Carrollton, TX [USA] exposes me to
the reality of de jure vs. de facto standards. The city's traffic police
accept only the de jure standard with a pedantically (-Wall -Wextra)
enforced speed limit not to exceed 60.000000 MPH. Greater than that yields
some form of overflow and subsequent UB.
>> [...]
>>
>> Perhaps giving credence to arguments about the [lack of?] utilitarian
>> value of c.l.c., I don't care one iota about how widely used, popular or
>> how many implementations there are of C99 translators.
>
> That is perhaps the difference between us. I like a language I can
> actually use. But your point is valid and well-made.
Much appreciated, Richard. I was actually prepared for a response more along
the lines of ``Get thee to a monastery!''. :-)
I'll bow out for a while and get back to tweaking the ``abstract machine''
on the other side of my desk.
Ben Bacarisse
> "Malcolm McLean" <regn...@btinternet.com> writes:
<snip>
>> 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.
That you think this is simple suggests (as I have thought before)
that we think about software in totally different ways.
A compiler is quite complex, but given a year (maybe even 6 months) of
careful study of the source code, test cases and debugging runs I
could probably get reasonably confident that a purported C compiler
did or did not do what it was supposed to do.
If the software has lots of bugs, then one can find them by random
testing, but given a very good (but still possibly faulty) compiler, I
don't think I could gain the same degree of confidence from a year's
testing. There is a real philosophical issue here: the static
comprehension of a program's text is easier than the enumeration of
its behaviour.
Even knowing what a program is supposed to do is far from simple. It
is particularly problematic in this case: I don't think there is any
statement of what the compiler (lcc-win32) should do, so how can one
even start? There are some basics one might assume, but then what? I
have asked for clarification and got none. I think Jacob prefers the
specification of what lcc-win32 does to be left vague. This makes it
very hard to know if it "does the job it says it does".
Case in point, is lcc-win32's treatment of:
#include <stdio.h>
void f(int n, int a[n][n])
{
printf("%d\n", a[2][2]);
}
int main(void)
{
int A[3][3] = {{1,2,3},{4,5,6},{7,8,9}};
f(3, A);
}
"doing the job is says it does"? You get a diagnostic: "Warning
vla-b2.c: 11 assignment of pointer to array 3 of int to pointer to
array 4 of int" and the resulting binary prints "4198554". Where does
one go to find out what the above program should do under the compiler
in question? A C90 compiler is permitted to do almost anything it
likes with this code and a C99 one should print "9", I think, but we
don't know what sort of non-C99 lcc-win32 is.
I don't think it is fair to call anything like this a bug since there
is no claim to conformance.
--
Ben.
Keith Thompson
[snip]
> The "pedantic" flag is no longer supported,
Then why the HELL didn't you just say that in response to the original
question? Sheesh.
--
Keith Thompson (The_Other_Keith) ks...@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"
Chris Thomasson
"jacob navia" <ja...@nospam.com> wrote in message
news:g3ik4r$q0s$1...@aioe.org...
> Dear pedantic user
>
> What is a pedant?
[...]
I like to make sure things work correctly and honestly within a given set of
rules.
santosh
<snip>
[regarding win-lcc]
> The "pedantic" flag is no longer supported, and if you invoke
You should have removed mention of the flag in win-lcc's usage message
as soon as you stopped support for the flag.
Version 3.8 of win-lcc compiled on March 2008 accepts the pedantic flag
without any mention that it is not supported.
> lcc -pedantic pedantic.c
>
> you get:
>
> "Pedants are no longer supported!"
So I updated my win-lcc installation to the latest binaries and sure
enough, I get this silly message of yours. IMHO, you should remove this
message and replace it with the default one ("Warning N Ignoring
unknown option '-pedantic') to maintain professionalism.
> and the program exits!
Which it shouldn't do, at least in this case. IMHO it should print a
message that it is ignoring the said option and continue translation.
> :-)
IMHO, you are affecting the professional image of your product by such
reactionary tactics.
> Obviously the fact that lcc-win is much faster than gcc
> or other compilers doesn't count.
With machines these days, compiler speed is not as important as it's
other abilities. Compiler correctness is especially critical, since it
has the potential to make or break other programs.
<snip>
Antoninus Twink
> jacob navia said:
> If you think comp.lang.c is a total loss, why post here?
You don't get it, do you Heathfield? You aren't the absolute monarch of
clc anywhere except in your own mind. Those of us who won't bow the knee
to your topicality tyrrany aren't just going to give up on clc, because
it has the potential to be such a useful resource for real-world C
programmers.
You and your cronies and lackies can shout and scream, you can try to
bore us to death with "off topic, not portable, don't top post, blah
blah blah" day after day, you can bully and harangue us... but clc IS
NOT your personal fiefdom, and you can't stop us discussing C here.
We're not going to roll over and die.
As it happens, I think there are signs that the tide is slowly turning.
As the months pass, there are more and more people who dare to stick
their heads above the parapet and provide "off topic" answers to
questions. The atmosphere is slowly improving for newbies (at least now
most newbies' posts get at least one friendly answer, even if they also
get half a dozen flames)... The Roman Empire fell, and Heathfield's
empire won't last forever either.
Antoninus Twink
> Some simple rules when dealing with Jacob:
>
> 1. Don't attack Jacob, he takes it as personal offense
On the contrary, Jacob responds politely to polite questions. Witness
his patience in the recent "Eddie" thread (another Heathfield
sock-puppet?).
You can hardly blame him for being a bit sensitive when Heathfield is
conducting a sustained campaign of character assassination against him
that any decent person would be ashamed to have any part of (I wonder if
he'd be so obnoxious IRL - they often say that people can be monsters
across the internet because they're talking to words not people). And
not just Heathfield, but a whole gang of them who egg each other on into
posting more and more unpleasant things about Jacob - Mackintyre, "Old
Wolf", "Mr Teapot", more names than I can remember...
Antoninus Twink
> Not in comp.lang.c, no, where we discuss the language, not implementations
> thereof. If you want to race compilers, please do it in a newsgroup where
> it's topical.
Is your memory so short that you don't remember this thread, only six
weeks ago:
http://groups.google.com/group/comp.lang.c/browse_frm/thread/82aa53ec428697ee#
In it you yourself "race" not even two C compilers, but a C compiler vs.
a C++ compiler vs. a Java compiler.
But of course there's no hypocrisy here. Of course it's not one rule for
you and another for Jacob. Of course not.
Jens Thoms Toerring
You seem to be a hopeless case. This group is about C, not every-
thing that was ever written in some dialect resembling C. And
it's not for system specific extensions, there are other groups
that are dedicated to those topics for a reason. Redirecting
people to those groups isn't unfriendly but the only reasonable
thing to do. Your kind of "friendliness" is lik giving a child
the cleaner fluid to drink just because it asked for and might
throws a tantrum instead of telling it not to drink it and ex-
plaining why.
I for one came originally to comp.lang.c after having gotten
bitten badly by not being able to distinguish what's C and
what are system specific extensions. I learned here what the
difference is and how to spot such probems since people took
the time to explain it clearly and in detail (if necessary
even being a bit pedantic - but non-pedantic programmers tend
to be bad programmers and we already have too many of those).
With your "we discuss everything here that ever was written
in anything that somehow resembles C" approach you try to
kill exactly what makes clc worth reading. If you would get
away with it it would become another completely useless place
where it's impossible to get relevant informations and where
the people that actually know their stuff leave in disgust.
There are already much too many newsgroups that suffered this
fate since nobody tried to maintain topicality.
But whom I am telling this. Someone who seems to write at least
20 to 30 poests a day (with a record at over 50 a day over a
months period) for sure wont have time for thinking. Consider
yourself finally plonked together with the other two assholes.
Three quartes of what you write is whining and of the rest a
big part is wrong or misleading. Perhaps you should start to
learn a bit more about C before you try to prescribe what is
to be discussed here.
--
\ Jens Thoms Toerring ___ j...@toerring.de
\__________________________ http://toerring.de
Kenny McCormack
My personal view is that it is not really hypocrisy when there is no
actual assumption of equality. The CLC regs have, collectively stated
(explicitly) that they are not bound by the same topicality rules that
they enforce on others (non-regs). You can do the Google on this; it
will not be hard to find explicit statements to this effect.
Think of this as being like the way cops drive - in non-emergency
situations. We all know they drive like lunatics - because they can -
and no one is going to even think of it as "hypocritical" when they
issue tickets to people for doing the same things they routinely do.
It goes with the job, as they say.
Keith Thompson
> Antoninus Twink <nos...@nospam.invalid> wrote:
[the usual]
> You seem to be a hopeless case.
Of *course* he's a hopeless case. AT is a troll, nothing more,
nothing less. Responding to him only encourages him to continue
trolling.
Joachim Schmitz
> On 21 Jun 2008 at 14:04, Joachim Schmitz wrote:
>> Some simple rules when dealing with Jacob:
>>
>> 1. Don't attack Jacob, he takes it as personal offense
> [snip pages of nonsense like this]
>
> On the contrary, Jacob responds politely to polite questions. Witness
> his patience in the recent "Eddie" thread (another Heathfield
> sock-puppet?).
RH isn't using win-lcc (he says, and I have no reason to not believe that),
so none of the bug reports came from him.
> You can hardly blame him for being a bit sensitive when Heathfield is
> conducting a sustained campaign of character assassination against him
> that any decent person would be ashamed to have any part of (I wonder
> if he'd be so obnoxious IRL - they often say that people can be
> monsters across the internet because they're talking to words not
> people). And not just Heathfield, but a whole gang of them who egg
> each other on into posting more and more unpleasant things about
> Jacob - Mackintyre, "Old Wolf", "Mr Teapot", more names than I can
> remember...
Bye, Jojo
Antoninus Twink
> Antoninus Twink wrote:
>> On the contrary, Jacob responds politely to polite questions. Witness
>> his patience in the recent "Eddie" thread (another Heathfield
>> sock-puppet?).
> Show polite reples of Jacob to bug reports, start with just one!
Besides the thread mentioned in my quotes, here are a couple from this
year:
http://groups.google.com/group/comp.compilers.lcc/browse_frm/thread/191a54fa4ec2701e
http://groups.google.com/group/comp.compilers.lcc/browse_frm/thread/df047137e694c128
> RH isn't using win-lcc (he says, and I have no reason to not believe that),
> so none of the bug reports came from him.
Yes, it's a matter of speculation and there's no firm evidence. But you
have to agree it's a bit suspicious that, while Heathfield is waging his
nasty guerilla war against Jacob, there's a continual drip-drip of
aggressive anti-lccwin posters who start threads then disappear once the
shit is flying.
jacob navia
> Show polite reples of Jacob to bug reports, start with just one!
>
> RH isn't using win-lcc (he says, and I have no reason to not believe that),
> so none of the bug reports came from him.
>
Those aren't bug reports. The regulars insisted in their stupid
pedantic stuff and I added a flag to please them.
Instead of filing a bug report, they laugh at me with their
"new to c" posts:
What happens? Am I doing something wrong?
Then Heathfield starts saying that my compiler is useless, etc.
What have you done for the community Mr Schmitz?
Is there any program from you *I* can laugh at?
No. Not even that. Nothing. Like your friend Heathfield.
Antoninus Twink
> This group is about C, not every- thing that was ever written in some
> dialect resembling C.
So say you. If you want a group where you can enforce topicality, set up
a moderated group - comp.lang.c.heathfields-whims or whatever. Each
poster to this group can decide for himself what he wants to post and
within what bounds of topicality.
> With your "we discuss everything here that ever was written in
> anything that somehow resembles C" approach you try to kill exactly
> what makes clc worth reading. If you would get away with it it would
> become another completely useless place where it's impossible to get
> relevant informations and where the people that actually know their
> stuff leave in disgust.
I don't accept this analysis. I think it's more likely that experts stop
by clc, get turned off by the stupid bickering and pedantry, and take
their knowledge elsewhere. I can't see how it would be a bad thing for
the atmosphere to become more open and frank.
> But whom I am telling this. Someone who seems to write at least 20 to
> 30 poests a day (with a record at over 50 a day over a months period)
> for sure wont have time for thinking.
You're out by an order of magnitude.
By far the most prolific posters to this group are Heathfield, Thomson
and CBF. One of these is machine-like, and the other two do indeed have
a habit of firing on all cylinders without thinking properly, or indeed
reading the question at all.
> Consider yourself finally plonked together with the other two
> assholes.
Capital idea. See, it's not so hard, is it? Plonk me, plonk any threads
that you consider "off topic, not portable, blah blah", and then you
won't have to get het up about things, and you can go along happily
reading posts about the abstract machine, and the rest of us can enjoy
the posts about the real world too. Everyone's problems are solved.
I wish you could convince the other regulars of the merits of such a
live-and-let-live approach: they can't resist turning every "off topic"
thread into a flame war.
Richard Heathfield
> Joachim Schmitz wrote:
>> Show polite reples of Jacob to bug reports, start with just one!
>>
>> RH isn't using win-lcc (he says, and I have no reason to not believe
>> that), so none of the bug reports came from him.
Correct. None of them did.
> Those aren't bug reports. The regulars insisted in their stupid
> pedantic stuff and I added a flag to please them.
You would do better to spend the time removing bugs from your compiler.
> Instead of filing a bug report, they laugh at me with their
> "new to c" posts:
If you don't like people to laugh at you, stop behaving in such a laughable
way. Grow up a little. Bugs are inevitable. It's how we respond to them
that matters.
> What happens? Am I doing something wrong?
Yes. You are too quick to react with inappropriate hostility when people
disagree with you.
> Then Heathfield starts saying that my compiler is useless, etc.
Only to people who need a C compiler. For people who need lcc-win32,
lcc-win32 is exactly what they need, and no doubt there are such people.
If you disagree with my suggestion that lcc-win32 is not a C compiler, to
what C standard do you claim conformance? K&R C? C90? C99?
> What have you done for the community Mr Schmitz?
He helps people out here with answers as good as he can give, and when he
gets it wrong and is corrected, he learns from that, so that his future
answers will be better still.
> Is there any program from you *I* can laugh at?
It's not your *program* that people laugh at.
> No. Not even that. Nothing. Like your friend Heathfield.
I've never even met the guy.
santosh
> jacob navia said:
<snip>
>> Then Heathfield starts saying that my compiler is useless, etc.
>
> Only to people who need a C compiler. For people who need lcc-win32,
> lcc-win32 is exactly what they need, and no doubt there are such
> people.
>
> If you disagree with my suggestion that lcc-win32 is not a C compiler,
> to what C standard do you claim conformance? K&R C? C90? C99?
So by your own logic Turbo C version 2.1 (distributed for free by
Borland in recent years and seemingly quite popular with beginners) is
not a C compiler?
:-)
<snip>
santosh
> Joachim Schmitz wrote:
>> Show polite reples of Jacob to bug reports, start with just one!
>>
>> RH isn't using win-lcc (he says, and I have no reason to not believe
>> that), so none of the bug reports came from him.
>>
>
> Those aren't bug reports. The regulars insisted in their stupid
> pedantic stuff and I added a flag to please them.
Oh, you added "pedantic" please the "regulars" of clc? Strange. When was
this? And what does "pedantic" do that "ansic" will not do? Does it
behave (or I guess, used to behave) similarly to gcc's pedantic flag?
> Instead of filing a bug report, they laugh at me with their
> "new to c" posts:
There is a possibility that these anonymous posters of win-lcc problems
do have a malicious motive. If they do, you however are feeding right
from their hand by getting so worked up about their posts. Regardless
of their intent you should only address the content of their posts. If
there is a genuine bug then the best response, IMHO, is to say you will
look into it at the earliest.
> What happens? Am I doing something wrong?
Yes, you are IMHO, tarnishing your own reputation. Remember
these "anonymous" posters can say anything precisely because of their
anonymity, but you would be well advised to overlook their possible
motive and only address the technical content of their posts.
<snip>
Richard Heathfield
Right. Turbo C 2.01, strictly speaking, is not a C compiler, because it
doesn't conform to C90. Mind you, it was released in the late 1980s. Since
then, Borland have released later versions which have fewer (no?)
conformance issues. I'm not judging lcc-win32 on the basis of how it stood
20 years ago (if it even existed then), but on the basis of how it stands
(or at least appears to stand, to go by comments made in this group) now,
and on the attitude of its principal (or perhaps only) maintainer towards
bug reports. An implementor who embraces, and is striving towards,
conformance is to be preferred over one who appears to consider
conformance to be an unnecessary evil.
santosh
And BTW, correct me if I'm wrong but "K&R C" isn't exactly a standard
right?
Richard Heathfield
<snip>
> And BTW, correct me if I'm wrong but "K&R C" isn't exactly a standard
> right?
Tricky one. It's not a standard in the ISO or ANSI sense, of course. But it
could reasonably be argued that an implementation of the language
described in K&R1 is a "K&R-conforming" implementation. Furthermore, K&R C
(as so described) is topical in clc, for historical reasons. It's slightly
inaccurate, then, but nevertheless convenient to describe it as a standard
when one has a reasonable expectation that a significant proportion of
those who read that description are bright/experienced/knowledgeable
enough to recognise it as an expedient shorthand rather than as a literal
claim.
Erwin Lindemann
> jacob navia <ja...@nospam.com> writes:
>
>> 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.
Not wanting to pour more oil into this, but the '-pedantic' option was
advertised in September 2006 in a thread called 'New -pedantic option
for lcc-win32', cross-posted to comp.lang.c and comp.compilers.lcc .
It's also mentioned in 'readme.txt'.
From the announcement:
| This flag will make
|
| _stdcall
|
| no longer a recognized part of the language.
|
| Anonymous structures will not be accepted either.
If I remember correctly, it broke compilation of <math.h>, and one or
two other standard headers relying on '_stdcall' being a keyword,
right then.
But: from reading the announcement, for some reason I was always under
the impression this option was never really intended to be used. Plus,
it appears to have a different meaning now.
Thanks
--
Erwin Lindemann
Ben Bacarisse
> Ben Bacarisse wrote:
<snip>
>> What is the -pedantic flag? As far as I can see you don't document
>> the use of it.
>
> Not wanting to pour more oil into this, but the '-pedantic' option was
> advertised in September 2006 in a thread called 'New -pedantic option
> for lcc-win32', cross-posted to comp.lang.c and comp.compilers.lcc .
> It's also mentioned in 'readme.txt'.
Ah. I missed that. To check (before I posted) I looked in the help
file, not the readme. I note that the readme just mentions it -- it
does not say what it does.
> From the announcement:
<snip description>
OK, it was once intended to have a use but things have moved on now
since it no longer supported with that meaning.
That seems a shame. I find strict checking by a compiler quite useful
but Jacob is entitled to move lcc-win32 in whatever direction he
thinks best.
--
Ben.
CBFalconer
> CBFalconer wrote:
>> Malcolm McLean wrote:
>>>
>> ... snip ...
>>>
>>> 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?
>>
>> a fairly strict published standard, casually known as the C99
>> standard. This gives us an easily applied criterion - simply
>> report all failures to comply with that C standard.
>
> Bugs in the binary tell us about possible bugs in the source,
> which is one indication of the "quality" of the source code, but
> beyond that one needs to examine the disassembly of the program
> and examine it's machine code and performance against a
> functionally identical, identically compiled, "control" program,
> to say more about the "quality" of the source code.
Jacobs source is NOT open-source, so you don't have source access.
The only action available is to execute the object code, or
possibly disassemble it. The latter is doomed.
--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.
** Posted from http://www.teranews.com **
CBFalconer
> Bob Nelson wrote:
>
>> The intent is to emphasize that C is, without otherwise being
>> modified, that which is defined by ISO/IEC.
>>
>> I find this well-known image appropriate when I see a posting
>> about clearing the screen, writing to the Windows registry,
>> reading directories and other such off-topic atrocities here in
>> c.l.c:
>
> Yeah sure.
>
> C is ISO C. Posix doesn't exist. Windows doesn't exist, the
> Mac doesn't exist.
>
> Network programming? Off topic. GUI programming? Off topic.
Now you've got the idea. At last.
... Further inconsistent garbage snipped ...
CBFalconer
> Malcolm McLean skrev:
>
>> Which leads us to a philosophical point. Can we tell the quality
>> of code purely from the binaries?
>
> C compilers, Perennial & Plum Hall has validation test suits,
> mandatory for UNIX 03 certification.
The problem is that, as far as I know, that (or any other trusted)
validation suite is not generally available as open-source.
Serve Lau
"Erwin Lindemann" <elin...@wupp.invalid> schreef in bericht
news:s8b3j5-...@wupp.invalid...
> If I remember correctly, it broke compilation of <math.h>, and one or
> two other standard headers relying on '_stdcall' being a keyword,
> right then.
ye why not do the same as gcc jacob? Add a pragma to lcc so the compiler
knows its compiling a system header and you ignore the pedantic flag then.
Joachim Schmitz
> Joachim Schmitz wrote:
>> Show polite reples of Jacob to bug reports, start with just one!
corrected here.
>> RH isn't using win-lcc (he says, and I have no reason to not believe
>> that), so none of the bug reports came from him.
>>
>
> Those aren't bug reports. The regulars insisted in their stupid
> pedantic stuff and I added a flag to please them.
Aha, so you added it? So you added a bug, as it doesn't work but craps out
on perfectly legal C code.
> Instead of filing a bug report, they laugh at me with their
> "new to c" posts:
I don't laugh at you nor your programs, I do laugh at your behavoir though.
If the post of 'new to c' annoys you, just ignore it. Or, much better, just
reply with admitting an oversight and that this -pedantic switch is no
longer supported and has just been forgotten to be taken out your code.
> What happens? Am I doing something wrong?
Yes. Attitute, behavoir
> Then Heathfield starts saying that my compiler is useless, etc.
He didn't. He just claims it not to be a C-Compiler as it doesn't take
perfeclty valid
> What have you done for the community Mr Schmitz?
>
> Is there any program from you *I* can laugh at?
I do post here occasionally with attempts to help people. I do make mistakes
in doing so sometimes. I'm not unfailable and never claimed to be. So just
for example I quite frequently forget that things that work in POSIX are not
guaranteed to work in ISO C.
Regardless there's no reason to laugh at me or my post, just tell me where
I'm wrong and why.
> No. Not even that. Nothing. Like your friend Heathfield.
I don't know him, so how could he be my friend? I just sometimes (and not
always, had my fights with him too) happen to agree with him (actually more
after than I don't).
Bye, Jojo
Richard
> jacob navia said:
>
>> Richard Heathfield wrote:
>>> jacob navia said:
>>>
>>>> santosh wrote:
>>>>> I see your point. Efficiency (both speed and resources consumed) is
>>>>> one aspect of "quality of code".
>>>> Lcc-win is the smallest compiler system in the C world.
>>>> It is around 5 times faster than gcc in compilation
>>>> time, and in execution time it is approx 75-85% of the
>>>> speed of the gcc generated code.
>>>>
>>>> This are facts. Easily measurable by anyone.
>>>
>>> If the program doesn't have to work properly, I can easily write a
>>> compiler system that is a thousand times smaller than yours and a
>>> thousand times faster. There is more to quality than speed and size.
>>>
>>
>> If you have nothing to say. Please do not say it here.
>
> Just because you don't understand me, that doesn't mean I have nothing to
> say.
>
>> The "pedantic" flag is no longer supported, and if you invoke
>>
>> lcc -pedantic pedantic.c
>>
>> you get:
>>
>> "Pedants are no longer supported!"
>
> That's an implementation issue, and as such should be discussed in a
> newsgroup where that implementation is topical, such as comp.compilers.lcc
>
>> and the program exits!
>
> Fine, but hardly topical here.
>
>> :-)
>>
>> Obviously the fact that lcc-win is much faster than gcc
>> or other compilers doesn't count.
>
> Not in comp.lang.c, no, where we discuss the language, not implementations
> thereof. If you want to race compilers, please do it in a newsgroup where
> it's topical.
>
> But for the record, no, if the compiler *doesn't work*, it doesn't matter
> how fast it is - same as with any program.
>
>> What counts is if it
>> supports c89 or maybe another more obsolete version of the language.
>
> No, what counts is that it is an implementation, and therefore needs to be
> discussed in a group where it is topical, rather than here, where we
> discuss the language itself, not implementations thereof. I do not
> expect
No "we" do not. YOU do. So please stay out of threads were we discuss
more real C issues.
Kenny McCormack
>Richard Heathfield wrote:
>> jacob navia said:
>>
>>>
>>> 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.
>>
>> 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.
Note that if we started calling Heathfield an "asshole" (as some of us
have been doing, at least privately, for years), it wouldn't be long
until he (Heathfield) would post the following:
Note that dictionary.com is non-normative.
In comp.lang.c, the word "asshole" tends to be used to describe someone who
cares about getting it right, by someone who doesn't.
The point being that, if you care to, _any_ insult can be "turned around".
Ralf Damaschke
> jacob navia wrote:
>> Joachim Schmitz wrote:
>>> Show polite reples of Jacob to bug reports, start with just one!
> BTW: AT meanwhile showed 2 examples of reasonable answer of your, so I
> stand corrected here.
<http://groups.google.com/group/comp.compilers.lcc/browse_frm/thread/191a54fa4ec2701e>
<http://groups.google.com/group/comp.compilers.lcc/browse_frm/thread/df047137e694c128>
I disagree. The OPs only were posted to comp.compilers.lcc. That does not
qualify as "here".
Ralf
jacob navia
Because "here" there weren't any bug reports.
1) All "bugs" posted here were ironic stuff to show how bad
my compiler is. For instance somebody posted a "bug report"
when he defined a dprintf function. It is not intrinsically
bad, and the correction is easy, but the general tone is:
"I am a new user and I can't understand"
Then, Heathfield and co will jump in as if they weren't
involved:
"Of course, that is a horrible compiler", etc.
2) No problems whatsoever with *real* problems, bad code
generation, etc. The only "problems" are cosmetic.
PEDANTS like those bugs, they make an implicit assertion
about "book knowledge" as cited in dictionary.com when
consulting the definition of "pedant".
3) Use of undocumented flags (like -ansic89) that they gather
by looking into the executable of linux or whatever. Then,
Heathfield springs in and writes:
"That compiler doesn't conform to *any* standard"
Since most gcc headers will not compile with other
compilers I could post HUNDREDS of those bugs here,
just to show that gcc is "bad". Obviously I will not
do that, I am not a pedant.
This group is lacking most of a real discussion about issues
in software development. Any such discussions will be killed by this
people with their "off topic" stuff. Here, only THEY can discuss
anything that goes beyond
int main (void);
or printf directives, or students homework.
I have tried to initiate such discussions, to show code for a
general container library for instance.
There wasn't a SINGLE comment about my code.
In that code I showed a software for developing general containers
with the example of a resizable array.
Nothing.
NONE of the people that now tell (in this same group)
"Jacob never posts source code"
This is a denigration campaign. And you have seen that, and apparently
you did not notice.
Joachim Schmitz
much more carefull now (or just ignore them)
Bye, Jojo
Joachim Schmitz
> On 22 Jun 2008 at 20:23, Joachim Schmitz wrote:
>> Antoninus Twink wrote:
>>> On the contrary, Jacob responds politely to polite questions.
>>> Witness his patience in the recent "Eddie" thread (another
>>> Heathfield sock-puppet?).
>> Show polite reples of Jacob to bug reports, start with just one!
>
> Besides the thread mentioned in my quotes, here are a couple from this
> year:
> http://groups.google.com/group/comp.compilers.lcc/browse_frm/thread/191a54fa4ec2701e
> http://groups.google.com/group/comp.compilers.lcc/browse_frm/thread/df047137e694c128
As I've just been made aware of you're cheating! These ain't posts to
comp.lang.c.
Bye, Jojo
vipp...@gmail.com
> Ralf Damaschke wrote:
> > Joachim Schmitz wrote:
>
> >> jacob navia wrote:
> >>> Joachim Schmitz wrote:
> >>>> Show polite reples of Jacob to bug reports, start with just one!
> >> BTW: AT meanwhile showed 2 examples of reasonable answer of your, so I
> >> stand corrected here.
>
> > <http://groups.google.com/group/comp.compilers.lcc/browse_frm/thread/d...>
>
> > I disagree. The OPs only were posted to comp.compilers.lcc. That does not
> > qualify as "here".
>
> > Ralf
>
> Because "here" there weren't any bug reports.
>
> 1) All "bugs" posted here were ironic stuff to show how bad
> my compiler is. For instance somebody posted a "bug report"
> when he defined a dprintf function. It is not intrinsically
> bad, and the correction is easy, but the general tone is:
> "I am a new user and I can't understand"
> Then, Heathfield and co will jump in as if they weren't
> involved:
> "Of course, that is a horrible compiler", etc.
> 2) No problems whatsoever with *real* problems, bad code
> generation, etc. The only "problems" are cosmetic.
purpose.
You seem to be suggesting that these bug reports are being done by mr
Heathfield himself, which I believe to be false.
I think it's just a troll finding all these "bugs" because the troll
knows you will get pissed about it, you will make a fuss about it and
a lot of noise will be generated.
> 3) Use of undocumented flags (like -ansic89) that they gather
> by looking into the executable of linux or whatever. Then,
> Heathfield springs in and writes:
> "That compiler doesn't conform to *any* standard"
> Since most gcc headers will not compile with other
> compilers I could post HUNDREDS of those bugs here,
> just to show that gcc is "bad". Obviously I will not
> do that, I am not a pedant.
implementations headers need not to be compilable by other
implementations AFAIK. In fact the standard headers need not to be
real files, so they don't need to be shared among compilers/
implementations.
> This group is lacking most of a real discussion about issues
> in software development. Any such discussions will be killed by this
> people with their "off topic" stuff. Here, only THEY can discuss
> anything that goes beyond
If group A has subject A, you talk ONLY about A. If you want to talk
about B, you go to group B. Is it *that* hard to understand?
Every morning you wake up, look at my post, read these lines. Repeat
until you've understood why 'software development issues' are off-
topic.
> int main (void);
>
> or printf directives, or students homework.
without being off-topic.
> I have tried to initiate such discussions, to show code for a
> general container library for instance.
>
> There wasn't a SINGLE comment about my code.
specific article on usenet.
<snip>
> This is a denigration campaign. And you have seen that, and apparently
> you did not notice.
Richard Heathfield
> On Jun 23, 10:36 pm, jacob navia <ja...@nospam.com> wrote:
<snip>
>> [...] The only "problems" are cosmetic.
> The problems are real. It does seem like the bug reports are done on
> purpose.
> You seem to be suggesting that these bug reports are being done by mr
> Heathfield himself, which I believe to be false.
You're right - it's false. I have never used lcc-win32 in the past, and I
don't plan to use it in the future, so I'm unlikely to encounter any bugs
in it, so I'm in no position to report them. I am, however, in a position
to comment on bug reports posted here.
> I think it's just a troll finding all these "bugs" because the troll
> knows you will get pissed about it, you will make a fuss about it and
> a lot of noise will be generated.
I think you're right, and Mr Navia's best response would be to refuse to
rise to the bait, but instead to fix the bugs. A compiler with no bugs
leaves the trolls nowhere to go.
<snip>
Antoninus Twink
So rather than admit that you've slandered Jacob, you prefer to change
the problem specification. I've worked for people like you before.
Here's what you said:
>>> Show polite reples of Jacob to bug reports, start with just one!
No mention of /where/ you want to see Jacob having been polite. But in
any case, I already provided an example of Jacob's patience under
extreme duress in clc (the "Eddie" thread), and there are many others -
if you care then do your own damn research instead of moving the
goalposts.
Antoninus Twink
> That's a lie, here you can discuss ANSI/ISO C and perhaps C's history
> without being off-topic.
Wow, that's really magnanimous of you! But guess what? You don't own
this group, and its participants can discuss *whatever the hell they
personally judge to be appropriate in it*, with or without your
condescending say-so.
I've heard it all now - a program in standard C is off-topic simply by
dint of the fact that it was posted by Jacob Navia. You need to get your
head examined.
>> This is a denigration campaign. And you have seen that, and apparently
>> you did not notice.
> You're paranoid and trolls like that.
There's no paranoia here - he's just drawing the conclusion that any
reasonable person would from Heathfield's behavior over many months.
Eric Sosman
> [...]
> 1) All "bugs" posted here were ironic stuff to show how bad
> my compiler is. For instance somebody posted a "bug report"
> when he defined a dprintf function. It is not intrinsically
> bad, and the correction is easy, but the general tone is:
> "I am a new user and I can't understand"
> Then, Heathfield and co will jump in as if they weren't
> involved:
> "Of course, that is a horrible compiler", etc.
Are you referring to the "Where is the error in this code?"
thread started by Erwin Lindemann on 22 Jan 2008? If so, note
that Richard Heathfield did not post to that thread at all, not
even once. Nor did any poster use the word "horrible," not even
once.
If you're referring to some other dprintf thread -- Google
finds several going back more than a decade -- please specify
which you're talking about.
> 2) No problems whatsoever with *real* problems, bad code
> generation, etc. The only "problems" are cosmetic.
>
> PEDANTS like those bugs, they make an implicit assertion
> about "book knowledge" as cited in dictionary.com when
> consulting the definition of "pedant".
Are you referring to the compiler's mis-handling of "long
int long" and the like? I think it's more than a "cosmetic"
problem when the compiler fails to recognize a valid type,
even if it's written oddly, and more than "pedantry" to say
it's a bug that needs a fix.
The proper response to a bug report is "Thank you," with
the "dammit" never rising above sotto voce.
> [...]
> I have tried to initiate such discussions, to show code for a
> general container library for instance.
>
> There wasn't a SINGLE comment about my code.
I don't recall seeing it, but I've seen a lot of things I
don't recall. Perhaps I saw it and thought "Good job, Jacob;
nothing I can add."
> "Jacob never posts source code"
A search for that phrase on groups.google.com turns up
Your search - "Jacob never posts source code" - did
not match any documents.
Obviously this is a Googleglitch of some kind, since it doesn't
even find the message I'm responding to! (Oddly, it *does*
find that message for the search ``Jacob "source code"'' --
go figure.) Since Google fails us, could you let us know
whom you're quoting?
Antoninus Twink
> jacob navia wrote:
>> [...]
>> I have tried to initiate such discussions, to show code for a
>> general container library for instance.
>>
>> There wasn't a SINGLE comment about my code.
>
> I don't recall seeing it, but I've seen a lot of things I
> don't recall. Perhaps I saw it and thought "Good job, Jacob;
> nothing I can add."
Call my a cynic, but I find it hard to imagine you have a positive
thought about something written by Jacob.
This may be what Jacob is referring to:
http://groups.google.com/group/comp.lang.c/browse_frm/thread/6e5fdc8dd450d69e/ee859343d91c5e8e
Saying there were no comment is a /slight/ exaggeration, but the silence
from the "regulars" is deafening.
>> "Jacob never posts source code"
>
> A search for that phrase on groups.google.com turns up
>
> Your search - "Jacob never posts source code" - did
> not match any documents.
I know it's been a long two days, but try stretching your memory back to
earlier in this very thread:
http://groups.google.com/group/comp.lang.c/msg/3cf5e4b855819f29
jacob navia
Thanks.
I remembered that it took me quite a lot of effort to adapt the code,
add comments, etc etc. It is a general string collection container.
Not A SINGLE ANSWER from any "regulars". Not a single word.
The only answers were from Charlie Gordon and Roland Pilbinger.
Heathfield, Sossman, etc, lept silent.
THEN
"jacob doesn't post source code"
And then
"Jacob is paranoic"
vipp...@gmail.com
> Antoninus Twink wrote:
> > On 23 Jun 2008 at 21:06, Eric Sosman wrote:
> >> jacob navia wrote:
> >>> [...]
> >>> I have tried to initiate such discussions, to show code for a
> >>> general container library for instance.
>
> >>> There wasn't a SINGLE comment about my code.
> >> I don't recall seeing it, but I've seen a lot of things I
> >> don't recall. Perhaps I saw it and thought "Good job, Jacob;
> >> nothing I can add."
>
> > Call my a cynic, but I find it hard to imagine you have a positive
> > thought about something written by Jacob.
>
> > This may be what Jacob is referring to:
>
> > Saying there were no comment is a /slight/ exaggeration, but the silence
> > from the "regulars" is deafening.
>
> >>> "Jacob never posts source code"
> >> A search for that phrase on groups.google.com turns up
>
> >> Your search - "Jacob never posts source code" - did
> >> not match any documents.
>
> > I know it's been a long two days, but try stretching your memory back to
> > earlier in this very thread:
> >http://groups.google.com/group/comp.lang.c/msg/3cf5e4b855819f29
>
> Thanks.
<snip>
Richard
And you are? Please take your net nannying and play with it
offline. Thank you.
Keith Thompson
[...]
> Because "here" there weren't any bug reports.
>
> 1) All "bugs" posted here were ironic stuff to show how bad
> my compiler is. For instance somebody posted a "bug report"
> when he defined a dprintf function. It is not intrinsically
> bad, and the correction is easy, but the general tone is:
> "I am a new user and I can't understand"
Perhaps the intent was "ironic", or whatever. Since I can't read the
poster's mind, I can't be sure. But regardless of the poster's
intent, it was (if I recall correctly) a genuine bug.
In my opinion, your best response would have been to ignore the tone,
acknowledge the error, and indicate your intent to fix it.
But since (a) lcc-win32 has had a tendency to declare non-standard
identifiers in standard headers, and (b) you have a history of
reacting badly when this is pointed out, a troll who wants to start a
flame war can easily do so. And you take the bait.
> Then, Heathfield and co will jump in as if they weren't
> involved:
What do you mean by "as if" they weren't involved? If you're
insinuating that the poster was a sock puppet, please provide some
evidence to back up your accusation.
> "Of course, that is a horrible compiler", etc.
Whom are you quoting?
> 2) No problems whatsoever with *real* problems, bad code
> generation, etc. The only "problems" are cosmetic.
>
> PEDANTS like those bugs, they make an implicit assertion
> about "book knowledge" as cited in dictionary.com when
> consulting the definition of "pedant".
I don't know what you're talking about here. Can you provide an
example?
> 3) Use of undocumented flags (like -ansic89) that they gather
> by looking into the executable of linux or whatever.
Yes, somebody complained, for whatever reason, about the behavior of
lcc-win32 with "-ansic89". Most of us had no way of knowing that that
was an undocumented flag. If you had said so at the beginning of that
discussion, there would have been nothing to discuss.
> Then,
> Heathfield springs in and writes:
> "That compiler doesn't conform to *any* standard"
Is he mistaken? If so, to what standard does it conform? If not,
what's the problem?
> Since most gcc headers will not compile with other
> compilers I could post HUNDREDS of those bugs here,
> just to show that gcc is "bad". Obviously I will not
> do that, I am not a pedant.
Nobody else would do that either, because it would be absurd. There's
no reason to assume that gcc-specific headers will compile with any
other compiler.
If some gcc-specific header didn't compile with gcc, or if some
lcc-specific header didn't compile with lcc, that would be a bug. In
either case, comp.lang.c might be an appropriate place to ask whether
it's a bug or not.
> This group is lacking most of a real discussion about issues
> in software development. Any such discussions will be killed by this
> people with their "off topic" stuff. Here, only THEY can discuss
> anything that goes beyond
>
> int main (void);
>
> or printf directives, or students homework.
Please don't exaggerate; it doens't help your case. ISO C is a big
topic, going well beyond "int main(void)" and printf directives.
> I have tried to initiate such discussions, to show code for a
> general container library for instance.
>
> There wasn't a SINGLE comment about my code.
>
> In that code I showed a software for developing general containers
> with the example of a resizable array.
>
> Nothing.
I'm afraid I don't remember that posting. Can you provide a URL or
Message-ID?
> NONE of the people that now tell (in this same group)
>
> "Jacob never posts source code"
Whom are you quoting?
> This is a denigration campaign. And you have seen that, and apparently
> you did not notice.
--
Keith Thompson (The_Other_Keith) ks...@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"
Eric Sosman
> Antoninus Twink wrote:
>> On 23 Jun 2008 at 21:06, Eric Sosman wrote:
>>> jacob navia wrote:
>>>>
>>>> There wasn't a SINGLE comment about my code.
>>> I don't recall seeing it, but I've seen a lot of things I
>>> don't recall. Perhaps I saw it and thought "Good job, Jacob;
>>> nothing I can add."
>> This may be what Jacob is referring to:
>> http://groups.google.com/group/comp.lang.c/browse_frm/thread/6e5fdc8dd450d69e/ee859343d91c5e8e
>>
>> Saying there were no comment is a /slight/ exaggeration, but the silence
>> from the "regulars" is deafening.
>>
>>>> "Jacob never posts source code"
>>> A search for that phrase on groups.google.com turns up
>>>
>>> Your search - "Jacob never posts source code" - did
>>> not match any documents.
>>
>> I know it's been a long two days, but try stretching your memory back to
>> earlier in this very thread:
>> http://groups.google.com/group/comp.lang.c/msg/3cf5e4b855819f29
>
>
> Thanks.
>
> I remembered that it took me quite a lot of effort to adapt the code,
> add comments, etc etc. It is a general string collection container.
>
>
> Not A SINGLE ANSWER from any "regulars". Not a single word.
> The only answers were from Charlie Gordon and Roland Pilbinger.
>
> Heathfield, Sossman, etc, lept silent.
I still don't recall seeing the code the first time around,
but with the Google reference I now think I know why I didn't
see it. At the time, you were posting a series of essays that
I found bad for my blood pressure, introducing each new topic
with "Continuing the discussion," just as if a discussion had
been in progress. After a time, I took to killfiling each
thread you started with that phrase, because I had found neither
enjoyment nor instruction in any of them. So your string code
was dragged down by its unfortunate setting.
> THEN
>
> "jacob doesn't post source code"
The post cited as an example does not use the quoted phrase,
so if that's the post you intended you've misquoted it. But I
don't think you need get too upset about that post: consider the
source, and decide how much attention is merited.
> And then
>
> "Jacob is paranoic"
Your search - "Jacob is paranoic" - did not match any documents.
After correcting the spelling error
Your search - "Jacob is paranoiac" - did not match any documents.
Ben Bacarisse
> Ralf Damaschke wrote:
>> Joachim Schmitz wrote:
>>
>>> jacob navia wrote:
>>>> Joachim Schmitz wrote:
>>>>> Show polite reples of Jacob to bug reports, start with just one!
>>> BTW: AT meanwhile showed 2 examples of reasonable answer of your, so I
>>> stand corrected here.
>>
>> <http://groups.google.com/group/comp.compilers.lcc/browse_frm/thread/191a54fa4ec2701e>
>> <http://groups.google.com/group/comp.compilers.lcc/browse_frm/thread/df047137e694c128>
>>
>> I disagree. The OPs only were posted to comp.compilers.lcc. That does not
>> qualify as "here".
>>
>> Ralf
>
> Because "here" there weren't any bug reports.
Bug reports would be off topic here so people who are both c.l.c savvy
and who care about topicality will not post them here.
> 1) All "bugs" posted here were ironic stuff to show how bad
> my compiler is. For instance somebody posted a "bug report"
> when he defined a dprintf function. It is not intrinsically
> bad, and the correction is easy, but the general tone is:
> "I am a new user and I can't understand"
There have been some seemingly disingenuous reports, I agree, but then
attributing motive to Usenet posts is very hard. There is a small
chance some of them were genuine.
> 2) No problems whatsoever with *real* problems, bad code
> generation, etc. The only "problems" are cosmetic.
Maybe not here, but I think there may be some serious issues. The
trouble is that if you don't say what your compiler supports, how can
anyone know if it is a bug or not? A number of reports I made
(topically, I think, to comp.compilers.lcc) were answered with "not
implemented". That is fine, but it made me not post several others.
In some sense, every compiler bug is just something that is "not
implemented".
I am not being pedantic about conformance here. A simple list of the
those things that you think are "done" and those that you know need
more work is all that is required. There is little motivation to
prepare a cut-down example to illustrate a potential problem if it is
likely that you already know that you have "not done that bit yet".
For example, if you have implemented C99's ... syntax for
function-like macros, then you have an error in the implementation.
If that is currently "not implemented" they you don't.
I occurs to me now that you might think I am one of these disingenuous
posters. This might explain why my post (again to comp.compilers.lcc)
about VLA parameters went un-answered[1]. If I am honest, I suspect
my motives for reporting bugs are not entirely honourable. I get a
buzz from finding them that has something to do with feeling clever,
but does that mean the information is any less useful to you? If it
helps, I would like to be able say there is another C99 compiler out
there. I am genuinely disappointed at the lack of C99 support.
[1] Message-ID: <873aqg6...@bsb.me.uk> The rather feeble "The code
looks fine to me" is just an expression of the fact I don't consider
myself an expert on VLAs, it was not my being disingenuous.
--
Ben.
CBFalconer
>
... snip ...
>
> That seems a shame. I find strict checking by a compiler quite
> useful but Jacob is entitled to move lcc-win32 in whatever
> direction he thinks best.
And he does. However, he neglects to bother to include any means
of identifying the version at hand, equivalent to using "gcc -v" on
gcc. Unless he has changed this practice, in which case I
apologize fo complaining.
christian.bau
> Since most gcc headers will not compile with other
> compilers I could post HUNDREDS of those bugs here,
> just to show that gcc is "bad". Obviously I will not
> do that, I am not a pedant.
That would just demonstrate that you are clueless. Standard header
files are part of the implementation. The combination of compiler and
standard header file together must produce the effect described by the
C Standard, and the gcc compiler + header files achieve exactly that.
It is _not_ a bug if a file that is part of the implementation cannot
be used with another compiler.
On the other hand, if including a standard header file defines
functions that are in the application name space, that is a serious
bug. gcc + gcc header files don't do that kind of thing.
Tor Rustad
[...]
> I have tried to initiate such discussions, to show code for a
> general container library for instance.
>
> There wasn't a SINGLE comment about my code.
>
> In that code I showed a software for developing general containers
> with the example of a resizable array.
Well Jacob,
I think there are quite a few people here, that could have been
interested in doing some "lcc" coding, _if_ it was an open source
project and _not_ Windows specific.
Both GNU gcc and libc are rather bloated.... ;)
So, "lcc" could do well as a C compiler. However, to become a major
success, excellent C89/C90 conformance level is very much needed, and
clean interfaces for the developers. With your repeated hate speech
against *pedants*, and lack of interest for ISO C conformance (vs adding
non-standard features), I sadly don't see anything of interest in your
project for now,
--
Tor <bwz...@wvtqvm.vw | tr i-za-h a-z>
CBFalconer
>
... snip ...
>
> Nothing. NONE of the people that now tell (in this same group)
> "Jacob never posts source code"
>
> This is a denigration campaign. And you have seen that, and
> apparently you did not notice.
Lets collect those denigrators. Will each one who is determined to
denigrate anything done by Jacob Navia, even if it complies with
the C standard, please answer this. You may also deny. I suggest
ticking one of the following two lines:
Denigrator ........ YES OUI JA
Denigrator ........ NO NON NEIN
santosh
> jacob navia wrote:
>>
> ... snip ...
>>
>> Nothing. NONE of the people that now tell (in this same group)
>> "Jacob never posts source code"
>>
>> This is a denigration campaign. And you have seen that, and
>> apparently you did not notice.
>
> Lets collect those denigrators. Will each one who is determined to
> denigrate anything done by Jacob Navia, even if it complies with
> the C standard, please answer this. You may also deny. I suggest
> ticking one of the following two lines:
>
> Denigrator ........ YES OUI JA
> Denigrator ........ NO NON NEIN
YES of course.
santosh
> Ben Bacarisse wrote:
>>
> ... snip ...
>>
>> That seems a shame. I find strict checking by a compiler quite
>> useful but Jacob is entitled to move lcc-win32 in whatever
>> direction he thinks best.
>
> And he does. However, he neglects to bother to include any means
> of identifying the version at hand, equivalent to using "gcc -v" on
> gcc. Unless he has changed this practice, in which case I
> apologize fo complaining.
Try lcc.exe -v
Serve Lau
"Eric Sosman" <Eric....@sun.com> schreef in bericht
news:1214259477.9471@news1nwk...
>
>> THEN
>>
>> "jacob doesn't post source code"
>
> The post cited as an example does not use the quoted phrase,
> so if that's the post you intended you've misquoted it. But I
> don't think you need get too upset about that post: consider the
> source, and decide how much attention is merited.
>
>> And then
>>
>> "Jacob is paranoic"
>
> Your search - "Jacob is paranoic" - did not match any documents.
>
> After correcting the spelling error
>
> Your search - "Jacob is paranoiac" - did not match any documents.
I dont read clc very often but even I know that that is what people say.
Maybe not literally but the regulars sure do. So I'm not sure why you have
to play games now. A little more respect for somebody maintaining a windows
C compiler would not hurt. I'm sure most regulars understand how hard it is
to keep adding features to a software system like this and not introduce
bugs.
>
> --
> Eric....@sun.com