The shooter is back
Nathan Myers
tim<b...@fastinternet.net.au> wrote:
>Well as the original guy who "wants to shoot redhat"
>First I would like to say I installed from scratch, on a spare machine.
>
>It was quite obvious that nobody at redhat had done this before they
>released it.
>1. 2. 3. 4. 5. 6. 7. [obvious bugs]
>
>I could go on and on about niggling little things. My main bitch about
>redhat and the reason I would like to start shooting is the level of
>bugs in their redhat 5 baby that they have advertised so much.
Red Hat has always had trouble fixing installation bugs; it's been
their main weakness at least since 2.x. I used to send patches, and
the bugs would still be there in the next release, so I gave up. I'm
sure others have had the same experience, and so also have stopped
contributing, or even switched (as I did recently) to Debian.
Once you get RH running it works pretty well. I doubt anybody thinks
the Red Hat folks don't work hard enough for their money; they just have
different priorities than some of us, which is no crime. It has been
demonstrated with absolutely stunning clarity that reliability is not
a requirement for success in the software business in the U.S. What
Americans want is a continuous stream of new features, and Red Hat has
been quickest at getting the new stuff into their releases.
Unlike some companies I could name, they aren't strong-arming anybody.
If your priorities are different from their other customers', you can
use a distribution from somebody who is a better match for you. (The
magazines could certainly do a better job of helping potential buyers
choose a distribution based on something other than pretty logos.)
I haven't tried an SuSE system, so would be interested in reports
on peoples' experience with it. A thing I like less about Red Hat
than Debian is their attitudes toward mail system integrity.
Red Hat ships with procmail as the default mail delivery agent,
and sendmail as the mail transfer agent. Now, sendmail is finally
getting reasonably stable, although it's overkill for easily 99 out
of a hundred installations. I know of no excuse for procmail.
(If you can look at that code and believe it's maintainable, you
probably can believe the earth is flat too.)
--
Nathan Myers
n...@nospam.cantrip.org http://www.cantrip.org/
tim
Well as the original guy who "wants to shoot redhat"
First I would like to say I installed from scratch, on a spare machine.
It was quite obvious that nobody at redhat had done this before they
released it.
1. That disk driud thing didnt work.
2. X windows didnt work by default, ( simple fix -- missing config files if
you've used linux before)
3. Perl didn't allow you to instal any libraries (nice rpm)
4. Squid wouldn't compile. -- Bad setuid implementation
5. That apache configurator (piece of shit) didnt run.
6. I really hated that it took me all day to get radiusd to compile on it.
7. PAM madness
....
....
I could go on and on about niggling little things. My main bitch about
redhat and the reason I would like to start shooting is the level of bugs in
their redhat 5 baby that they have advertised so much.
I begun using redhat when 4 came out, and i got it installed and running ---
before I had to begin learning how it worked.
A day of beta testing would have made it so so much better.
Nathan Myers
Eric Lee Green<e_l_...@hotmail.com> wrote:
>Nathan Myers <n...@nospam.cantrip.org> wrote:
>>
>>Red Hat has always had trouble fixing installation bugs; it's been
>>their main weakness at least since 2.x. I used to send patches, and
>>the bugs would still be there in the next release, so I gave up.
>>Red Hat ships with procmail as the default mail delivery agent,
>
>various mailing lists and have procmail write them to various inboxes
>so I can browse them with pine at my leisure, rather than having the
>mailing list EMAIL mixed with my personal EMAIL. Okay, so the code's not
>so great. But as long as you don't touch it ... :-}.
I have no objection to including procmail on the distribution CD,
or to anybody using it. But nobody with an ounce of sense would
make it the default MDA. The most desirable quality in an MDA is
reliability. Anybody who actually wants to use a flaky mail sorter
can use a .forward file to call procmail -- or install procmail as
the MDA deliberately -- and take responsibility for the lost mail.
But people who don't even realize the code is a room full of cobras
shouldn't be sent through it unaware.
(If you haven't looked at the code, you owe it to yourself to see
just how bad code can be.)
Eric Lee Green
On 6 Feb 1998 20:15:11 -0800, Nathan Myers <n...@nospam.cantrip.org> wrote:
>tim<b...@fastinternet.net.au> wrote:
>Red Hat has always had trouble fixing installation bugs; it's been
>their main weakness at least since 2.x. I used to send patches, and
They've tended to listen to me a bit more. Maybe because I squawk a
little louder :-). But then, they totally re-wrote the install for
5.0, so the jury is out again on them.
I haven't even tried to install 5.0 yet. I wanted to wait at least two
months first. I had our business manager order two copies Friday (one
for me and one for the office), so I should be able to see Monday
whether they fixed the bugs yet.
The problem I've always had with Debian is that they require all those
bloody floppies for installation. SuSE and RedHat will both work off of
either a single boot floppy or off CD-ROM (if yours supports booting). Same
with Caldera.
>I haven't tried an SuSE system, so would be interested in reports
>on peoples' experience with it. A thing I like less about Red Hat
I am using SuSE right now. My experience: They have a reasonable
system but it is not as well-geared towards business as Red Hat
is. For example, they throw config files all over the file system
rather than dump them all in /etc (e.g. the UUCP config lives under
/usr/lib/uucp rather than under /etc/uucp). This matters because our
network backup strategy backs up /etc, /home, and /usr/local/src
(where our source code lives) daily, and the rest of the system weekly
or monthly, depending (/usr is backed up on a monthly basis, we just
don't change it very often). I'd hate to find out that all of my UUCP
config file changes for the past month have suddenly vaporized :-(.
In addition, while general users will appreciate the large selection
of software that comes with SuSE, they won't appreciate the lack of
GUI system tools, the difficulty of installation, and the
poorly-translated manual. The lack of a good web and FTP site for
support are also troubling. I'm not sorry I bought SuSE, but I'm not
going to cry when I install Red Hat on top of it either.
>than Debian is their attitudes toward mail system integrity.
>Red Hat ships with procmail as the default mail delivery agent,
>and sendmail as the mail transfer agent. Now, sendmail is finally
>getting reasonably stable, although it's overkill for easily 99 out
>of a hundred installations. I know of no excuse for procmail.
One thing about SuSE is they have a saner sendmail config than Red Hat
does. For example, it's easy for me to make it say that EMAIL sent as
user "eric" should actually be sent as coming from
"e_l_...@hotmail.com" rather than using whatever login name and host
name at whatever computer I'm sending EMAIL from (most of our
computers are hidden behind a firewall with no external DNS entry, and
on some systems I use a "generic" login -- someday I need to get
around to getting NIS configured, sigh).
But procmail -- I couldn't survive without procmail. I subscribe to
various mailing lists and have procmail write them to various inboxes
so I can browse them with pine at my leisure, rather than having the
mailing list EMAIL mixed with my personal EMAIL. Okay, so the code's not
so great. But as long as you don't touch it ... :-}.
--
Eric Lee Green e_l_...@hotmail.com
Linux & Educational Administration computer solutions
Richard Coleman
> I have no objection to including procmail on the distribution CD,
> or to anybody using it. But nobody with an ounce of sense would
> make it the default MDA. The most desirable quality in an MDA is
> reliability. Anybody who actually wants to use a flaky mail sorter
> can use a .forward file to call procmail -- or install procmail as
> the MDA deliberately -- and take responsibility for the lost mail.
> But people who don't even realize the code is a room full of cobras
> shouldn't be sent through it unaware.
>
> (If you haven't looked at the code, you owe it to yourself to see
> just how bad code can be.)
>
In my experience, procmail is highly stable, and generally more
secure than many other MDA's. Using procmail as the default MDA
seems like a good choice to me.
The code in procmail may be a room full of cobras. But why should
I care? I just use it, and it works.
--
Richard Coleman
col...@math.gatech.edu
Andi Kleen
n...@nospam.cantrip.org (Nathan Myers) writes:
>
> (If you haven't looked at the code, you owe it to yourself to see
> just how bad code can be.)
It looks bad, but it is surprisingly solid and reliable. I haven't
catched procmail doing something wrong yet (of course you never know,
but if it had serious real-world problems we would see more complaints
about it, wouldn't we?)
-Andi
Martin J. Maney
In comp.os.linux.development.system Richard Coleman <col...@math.gatech.edu> wrote:
> The code in procmail may be a room full of cobras. But why should
> I care? I just use it, and it works.
The short answer is, as Dijkstra put it so well, so long ago: "Program
testing can be used to show the presence of bugs, but never to show
their absence!" The long answer would be an introductory course in
software engineering...
Stefan Monnier
n...@nospam.cantrip.org (Nathan Myers) writes:
> (If you haven't looked at the code, you owe it to yourself to see
> just how bad code can be.)
The code *looks* bad! no doubt about that one.
But the coding style seems very defensive (which doesn't help make the code
more readable). And from my experience it is rock solid.
Stefan
Russell Nelson
e_l_...@hotmail.com (Eric Lee Green) writes:
> But procmail -- I couldn't survive without procmail. I subscribe to
> various mailing lists and have procmail write them to various inboxes
> so I can browse them with pine at my leisure, rather than having the
> mailing list EMAIL mixed with my personal EMAIL. Okay, so the code's not
> so great. But as long as you don't touch it ... :-}.
Bag sendmail+procmail and install qmail. Then, instead of delivering
everything to one mailbox, and filtering, you can subscribe using
different subaddresses. http://www.qmail.org.
--
-russ <nel...@crynwr.com> http://web.crynwr.com/~nelson
Crynwr Software supports freed software | PGPok | Freedom is the primary
521 Pleasant Valley Rd. | +1 315 268 1925 voice | cause of Peace, Love,
Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | Truth and Justice.
Richard Coleman
I know plenty about software engineering. I also know that procmail has
had lots of testing and usage under heavy loads. As a sysadmin, I know
that it is a program that can be trusted (as much as you can trust software
to do the right thing).
--
Richard Coleman
col...@math.gatech.edu
Nathan Myers
"There are two ways of constructing a software design. One way is to
make it so simple that there are obviously no deficiencies. And the
other way is to make it so complicated that there are no obvious
deficiencies." -- C.A.R. Hoare
Where does procmail sit, in this schema? Why should *all* mail go through
something extremely complicated, instead of only the mail that users ask
to have go through it?
Dominic Davidson
On 8 Feb 1998 03:32:46 GMT,[...]
>The problem I've always had with Debian is that they require all those
>bloody floppies for installation.
Not in recent versions; the ISO CD image at ftp.debian.org is
bootable. You need one floppy if you don't have a bootable CD ROM
drive.
-Dom
--
Dominic Davidson <d...@djd.ftech.co.uk>
Alex Buell
On 8 Feb 1998, Michael F Gordon wrote:
> We use procmail as the default MDA to trap spam and haven't had any
> reports of lost mail that we could attribute to it. I'm well aware
> of how horrible the code is - my boss and I exchanged email with the
> author to get NFS locking working before we switched to it - but it
> seems to work. Part of the problem may be the incredibly hideous
> coding style, apparently designed to get as much code on screen at
> once as possible.
Precisely! That's why procmail works - because noone's had the guts to
fiddle with it. :o)
Cheers,
Alex
--
/\_/\ Make the police happy,
( o.o ) Smoke some cannabis today!
> ^ < Peace, Love, Unity and Respect to all.
http://www.tahallah.demon.co.uk
Nathan Myers
m...@ee.ed.ac.uk (Michael F Gordon) writes:
>[about procmail]
>> Part of the problem may be the incredibly hideous coding style,
>> apparently designed to get as much code on screen at once as possible.
No, it's not the style: it's the (literally) hundreds of goto's, jumping
into loops, jumping out of one loop and into another, jumping into "if"
statements; just an unmaintainable mess. Nobody with any sense even
touches code like that, so all you're left with to maintain it is people
who have no sense. Does that inspire confidence?
Anyway, the point remains: it's one thing to put it on the CD, and
another thing to inflict it on people who aren't (yet) equipped to
decide whether to expose their mail to such a monstrosity. Nobody has
yet even hinted at any reason why it should be the default MDA in any
distribution, rather than something simple and reliable. Anybody can
use procmail (if they actually think they want to) by using a ".forward"
file, without damaging the integrity of the mail system,.
Nathan Myers
n...@nospam.catrip.org http://www.cantrip.org/
Matthew Hannigan
In article <rcafc13...@cypress.math.gatech.edu>,
>> > The code in procmail may be a room full of cobras. But why should
>> > I care? I just use it, and it works.
>>
>> The short answer is, as Dijkstra put it so well, so long ago: "Program
>> testing can be used to show the presence of bugs, but never to show
>> their absence!" The long answer would be an introductory course in
>> software engineering...
>
>I know plenty about software engineering. I also know that procmail has
>had lots of testing and usage under heavy loads. As a sysadmin, I know
>that it is a program that can be trusted (as much as you can trust software
>to do the right thing).
>
>Richard Coleman
>col...@math.gatech.edu
And that famous Dijkstra comment is a little misleading. Testing
may not show the absence of bugs in general, but tests can show
the absence of particular bugs.
--
-Matt
Alex Buell
On 8 Feb 1998, Nathan Myers wrote:
> Where does procmail sit, in this schema? Why should *all* mail go through
> something extremely complicated, instead of only the mail that users ask
> to have go through it?
Well, Sendmail is the Mail Transport Agent (MTA), where it picks up all
the mail from other mail servers, and sends any mail of yours out to
them. Sendmail places inbound mail in the mqueue, and triggers off
procmail (or whatever you have in place of it), which trundles off and
parses the mail mqueue and places it in the correct mail boxes. This
explains why procmail is often used as a filter to kill spam. (Grr..
spammers should be shot). Pine/elm/readmail are just programs that looks
in these mailboxes and displays them to you.
The best thing about having different programs do different things is that
you can do *proper* plug'n'play with them. You don't like procmail, you
replace it with something else, you don't like your mail reader, you
replace it with something else, and the rest of your system doesn't
suffer. Unlike certain systems from Micros***. :o)
Mats Andtbacka
Nathan Myers, in <6blbtq$ice$1...@shell7.ba.best.com>:
> "There are two ways of constructing a software design. One way is to
> make it so simple that there are obviously no deficiencies. And the
> other way is to make it so complicated that there are no obvious
> deficiencies." -- C.A.R. Hoare
>Where does procmail sit, in this schema? Why should *all* mail go through
>something extremely complicated, instead of only the mail that users ask
>to have go through it?
then i take it you do not use sendmail, either? which MTA would you
recommend in its stead, perchance qmail?
--
"Pitiful, isn't it?" - Marvin
Stefan Monnier
n...@nospam.cantrip.org (Nathan Myers) writes:
> No, it's not the style: it's the (literally) hundreds of goto's, jumping
> into loops, jumping out of one loop and into another, jumping into "if"
> statements; just an unmaintainable mess. Nobody with any sense even
> touches code like that, so all you're left with to maintain it is people
> who have no sense. Does that inspire confidence?
Depends: confidence in it doing what it's supposed to do ? probably not.
But skimming over the code gave me a sense of confidence that it would most
likely not dump a core or ignore exception situations or be subject to typical
security holes.
> decide whether to expose their mail to such a monstrosity. Nobody has
> yet even hinted at any reason why it should be the default MDA in any
> distribution, rather than something simple and reliable. Anybody can
1 - it is reliable
2 - it is small and fast
3 - it knows how to do locking
4 - it behaves reasonably well when your filesystem is full or in other such
supposedly unusual cases
5 - /etc/procmailrc allows the sysadm to setup some global services like
elimination of duplicate mail, maintenance of a backup mailbox, ...
6 - when using <user+arg@host> addresses, the use of procmail as the MDA
allows to access the "+arg" even if the actual address only appears in the
envelope (the destination address from the envelope is dropped by sendmail
if you go through a .forward, as opposed to the origin address which is
still available in the "From " line). This argument is supposedly moot
if you use qmail since qmail supposedly adds the destination address of the
envelope to the header.
> use procmail (if they actually think they want to) by using a ".forward"
> file, without damaging the integrity of the mail system,.
Please provide evidence that procmail can pose such problems.
Stefan
Chris Waters
m...@ee.ed.ac.uk (Michael F Gordon) writes:
> seems to work. Part of the problem may be the incredibly hideous
> coding style, apparently designed to get as much code on screen at
> once as possible.
Which is why someone invented indent(1). :-)
--
Chris Waters | Bill Gates: "We need room to innovate!"
cwa...@systems.DHL.COM |
xt...@dsp.net (personal) | Me: "Well, that would certainly be a change."
www.dsp.net/xtifr/ (web) |
Nathan Myers
Is this flame bait? Some people like qmail a lot, and say so with
mystifying frequency. I have not had occasion to try it yet. It
is one of several mailers simpler than sendmail, along with smail
and exim. Any of them seems more appropriate for the must-be-99%
of systems that send mail via an (intermittently-connected) ISP's
SMTP server, and receive mail via POP or IMAP.
Just in case I need to repeat this: I never said, "Nobody should use
procmail". I don't know *anybody* who says it. I said "It should not
be the default MDA in a distribution." Those are fundamentally different
statements, but every posting I have seen defending procmail pretended
that I had said the former.
Is there anybody who can actually defend putting in an unmaintainable
program as the default Mail Delivery Agent in a distribution, when
there are perfectly simple alternatives available? Try (try!) not to
forget that anybody can use procmail if they choose, regardless of the
MDA installed.
--
Nathan Myers
Stefan Monnier wrote:
>n...@nospam.cantrip.org (Nathan Myers) writes:
>> Nobody with any sense even
>> touches code like that, so all you're left with to maintain it is people
>> who have no sense. Does that inspire confidence?
>
>Depends: confidence in it doing what it's supposed to do ? probably not.
>But skimming over the code gave me a sense of confidence that it would most
>likely not dump a core or ignore exception situations or be subject to
>typical security holes.
Please forgive me for observing that your touching faith might
be better exercised in a monastery than in an engineering
environment. Skimming bad code does not inspire confidence
in a rational engineer.
>> decide whether to expose their mail to such a monstrosity. Nobody has
>> yet even hinted at any reason why it should be the default MDA in any
>> distribution, rather than something simple and reliable.
>
>1 - it is reliable
That is repeatedly asserted, contrary to the various evidence.
Reliability depends on fundamental simplicity, and procmail just
doesn't have it.
>2 - it is small and fast
This is also repeatedly asserted, despite that a simpler program
would be smaller and faster.
>3 - it knows how to do locking
Demonstrated false. (See below.)
>4 - it behaves reasonably well when your filesystem is full or in other such
> supposedly unusual cases
The documentation claims it does. Have you tested it thoroughly?
Can you follow the code through all the "unusual cases" to verify it?
Can anybody? Has anybody? Claims in the documentation are just
marketing, and as professionals we should know better than to be
taken in.
>5 - /etc/procmailrc allows the sysadm to setup some global services like
> elimination of duplicate mail, maintenance of a backup mailbox, ...
Is this appropriate for an MDA? It sounds like MTA business to me.
>6 - when using <user+arg@host> addresses, the use of procmail as the MDA
> allows to access the "+arg" even if the actual address only appears in
> the envelope (the destination address from the envelope is dropped by
> sendmail if you go through a .forward, as opposed to the origin address
> which is still available in the "From " line). This argument is
> supposedly moot if you use qmail since qmail supposedly adds the
> destination address of the envelope to the header.
This is properly done by the MTA; then no special magic in the MDA
is needed. Can you give some reason why the argument is only
"supposedly moot" and not actually moot?
>> Anybody can
>> use procmail (if they actually think they want to) by using a ".forward"
>> file, without damaging the integrity of the mail system,.
>
>Please provide evidence that procmail can pose such problems.
It has "posed such problems" in earlier Red Hat distributions.
Its locking (in 2.x?) used a different scheme than the MUA
packages in the distributions. It did lose mail. Few noticed,
or took enough notice, for several releases. This is the nature
of background processes; when they go wrong, it's hard to tell
who is responsible, or sometimes even that they went wrong.
(This is why it's imperative that it be reliable.)
All these claims that procmail is reliable are worth only as much
as the nonexistent paper they're printed on. Mail could be lost
occasionally, and how would you know? What program would you
blame if you did know?
Procmail does not belong as the default MDA in any distribution.
It probably should be included in distributions, and people who want
to risk it should be free to do so. But it should not be inflicted
on users unaware of the risks.
Stefan Monnier
n...@nospam.cantrip.org (Nathan Myers) writes:
> Is there anybody who can actually defend putting in an unmaintainable
> program as the default Mail Delivery Agent in a distribution, when
> there are perfectly simple alternatives available?
What do you care if it's not maintainable since it doesn't need to be
maintained ? (how many bugs in procmail-3.10 ?)
> Try (try!) not to forget that anybody can use procmail if they choose,
> regardless of the MDA installed.
Try not to forget that extracting the "+arg" by looking for "user+arg@host"
in the header is not the same as receiving it straight from sendmail: in the
first case, it is error prone and might fail (or erroneously succeed), in the
second it always succeeds because it comes straight out of the envelope.
procmail in the .forward is *not* the same as procmail as the MDA.
Stefan
Stefan Monnier
n...@nospam.cantrip.org (Nathan Myers) writes:
> environment. Skimming bad code does not inspire confidence
> in a rational engineer.
But skimming code shows that return values are checked and error codes are
checked. I admit not having checked whether they then get propagated in a
meaningful manner, but I've seen enough programs which don't even try to check
the return values.
> >1 - it is reliable
> That is repeatedly asserted, contrary to the various evidence.
What evidence ? (let's set aside locking for later)
> Reliability depends on fundamental simplicity, and procmail just
> doesn't have it.
No. Proving reliability is harder on ugly code than it is on beautiful and
simple code, but ugly code can be reliable just as well as awe-inspiring code.
> >2 - it is small and fast
> This is also repeatedly asserted, despite that a simpler program
> would be smaller and faster.
Simplicity isn't always synonym with fast.
> >4 - it behaves reasonably well when your filesystem is full or in other such
> > supposedly unusual cases
> The documentation claims it does. Have you tested it thoroughly?
Thoroughly, no. But I've had out-of-memory situations (both with overcommitting
OSes and non-overcommitting ones) as well as file-system full situations and
I've never noticed lost mail. On another hand I did notice proper
failure-indicating return codes from procmail to sendmail in sendmail's logs
which prompted redelivery later on.
> Can you follow the code through all the "unusual cases" to verify it?
> Can anybody? Has anybody? Claims in the documentation are just
> marketing, and as professionals we should know better than to be
> taken in.
Indeed. But most mail deliver agent on Unix don't even claim that much.
> >5 - /etc/procmailrc allows the sysadm to setup some global services like
> > elimination of duplicate mail, maintenance of a backup mailbox, ...
> Is this appropriate for an MDA? It sounds like MTA business to me.
First, this is highly debatable.
Second, no MTA that I know offers such features.
> >6 - when using <user+arg@host> addresses, the use of procmail as the MDA
> > allows to access the "+arg" even if the actual address only appears in
> > the envelope (the destination address from the envelope is dropped by
> > sendmail if you go through a .forward, as opposed to the origin address
> > which is still available in the "From " line). This argument is
> > supposedly moot if you use qmail since qmail supposedly adds the
> > destination address of the envelope to the header.
> This is properly done by the MTA; then no special magic in the MDA
> is needed.
Well, the standard MTA doesn't do it properly. Furthermore, is qmail
sufficiently careful to first remove any previous header looking like the one
it's adding ? I don't know what header it's using, but let's assume that it's
X-Envelope-To, if the mail you receive already has several such headers
and qmail doesn't remove them before adding its own, then how can you tell
which is "the right one" ?
> Can you give some reason why the argument is only "supposedly moot" and not
> actually moot?
Because I've never looked at qmail and so I've only heard that it does add such
headers, but I don't know if it always does it and if so if it does it properly
enough to make the issue moot.
> >Please provide evidence that procmail can pose such problems.
> It has "posed such problems" in earlier Red Hat distributions.
> Its locking (in 2.x?) used a different scheme than the MUA
> packages in the distributions. It did lose mail.
I've only used it since 3.10 and the locking it uses (at least from 3.10 on)
is either the "<mailbox>.lock" and/or fcntl and/or flock and/or lockf (if
memory serves).
This seems at least as good as or better than any other MDA I know. You can
even change the ".lock" extension to something else, if you prefer. (via the
always handy /etc/procmailrc which also allows you to change the mailbox
locations without having to recompile your MDA program even it then indeed
comes at some risk since procmail might fail to read /etc/procmailrc and it
might try delivering anyway to the compiled-in mailbox location).
Stefan
Nathan Myers
Chris Adams<cad...@ro.com> wrote:
>Nathan Myers <n...@nospam.cantrip.org>:
>>Stefan Monnier wrote:
>>>n...@nospam.cantrip.org (Nathan Myers) writes:
>>
>>>> decide whether to expose their mail to such a monstrosity. Nobody has
>>>> yet even hinted at any reason why it should be the default MDA in any
>>>> distribution, rather than something simple and reliable.
>>>
>>
>>That is repeatedly asserted, contrary to the various evidence.
>
>What evidence?
As presented in the previous mail.
>>>2 - it is small and fast
>>
>>This is also repeatedly asserted, despite that a simpler program
>>would be smaller and faster.
>
>Evidence?
Please try to reason abstractly for a moment, without involving
your prejudices involving procmail. At the very least, a simple
program can be shorter, and therefore load faster. Once loaded,
a simple program makes fewer choices at each juncture, so can be
faster, because making choices consumes runtime.
>>>3 - it knows how to do locking
>>
>>Demonstrated false. (See below.)
>
>The case below does not prove that procmail does not know how to do
>locking. It shows that someone miscompiled either procmail or the mail
>readers. If you tell procmail to do dot locking (for example) and the
>readers to do flock, it won't work. It doesn't matter if both types of
>locking are implemented 100% correct - they just won't work together.
You miss the point. Yes it does locking. All considerable MTAs do
locking, it's part of the job description. Do you notice if it does
locking properly? Evidently not.
>>>> Anybody can
>>>> use procmail (if they actually think they want to) by using a
>>>> ".forward" file, without damaging the integrity of the mail system,.
>>>
>>>Please provide evidence that procmail can pose such problems.
>>
>>It has "posed such problems" in earlier Red Hat distributions.
>>
>>Its locking (in 2.x?) used a different scheme than the MUA
>>packages in the distributions. It did lose mail. Few noticed,
>>or took enough notice, for several releases. This is the nature
>>of background processes; when they go wrong, it's hard to tell
>>who is responsible, or sometimes even that they went wrong.
>>(This is why it's imperative that it be reliable.)
>
>This is a configuration issue, not a code issue.
You miss the point. Over the course of more than a year (several
RH releases) the default MDA was configured such as to lose mail.
Nobody responsible enough to report (never mind patch) the problem
even noticed.
What does that say about its much-vaunted reliability? It says
that the supposed reliability of procmail is purely illusory. It's
faith and crossed fingers, it's see-no-evil/hear-no-evil. You
wouldn't notice if it was twice as unreliable as it is, and if it
were perfect you would have no way to tell, because nobody's checking.
>Nobody is forcing you to use procmail. If you don't like it, fine,
>don't use it. But there are a lot of people using it (and using its
>features for things like mailbox sorting and spam filtering); why do you
>want to force your opinion on the rest of us? If you just _can't_ have
>a distribution using procmail, that's fine. Build your own
>distribution.
Again you miss the point. Like any competent person I am perfectly
capable of substituting a better MDA in any distribution I install.
I don't need your permission. I don't care to release my own
distribution, but it wouldn't help if I did.
The point (again!) is that it is irresponsible to ship a distribution
with such an unreliable program as the default MDA, so that users who
are not (yet?) competent even to evaluate its risks are nonetheless
exposed to them.
(And (again!) I am not arguing that procmail should be removed from
any distribution. It merely should not be the default MDA. Users
who are equipped (or are so deluded as to think they are equipped)
to evaluate the risks are perfectly free to install procmail as the
MDA on any distribution, so there is no question of restricting anyone's
choices.)
Chris Adams
According to Nathan Myers <n...@nospam.cantrip.org>:
>>> touches code like that, so all you're left with to maintain it is people
>>> who have no sense. Does that inspire confidence?
>>
>>Depends: confidence in it doing what it's supposed to do ? probably not.
>>But skimming over the code gave me a sense of confidence that it would most
>>likely not dump a core or ignore exception situations or be subject to
>>typical security holes.
>
>Please forgive me for observing that your touching faith might
>be better exercised in a monastery than in an engineering
>in a rational engineer.
>
>>> yet even hinted at any reason why it should be the default MDA in any
>>> distribution, rather than something simple and reliable.
>>
>>1 - it is reliable
>
>That is repeatedly asserted, contrary to the various evidence.
What evidence?
>Reliability depends on fundamental simplicity, and procmail just
>doesn't have it.
What? I've never heard that "reliability depends on fundamental
simplicity." The more simple something gets, the more it tends to be
reliable, but that doesn't mean that something has to be simple to be
reliable.
>>2 - it is small and fast
>
>This is also repeatedly asserted, despite that a simpler program
>would be smaller and faster.
Evidence?
>>3 - it knows how to do locking
>
>Demonstrated false. (See below.)
The case below does not prove that procmail does not know how to do
locking. It shows that someone miscompiled either procmail or the mail
readers. If you tell procmail to do dot locking (for example) and the
readers to do flock, it won't work. It doesn't matter if both types of
locking are implemented 100% correct - they just won't work together.
>>5 - /etc/procmailrc allows the sysadm to setup some global services like
>> elimination of duplicate mail, maintenance of a backup mailbox, ...
>
>Is this appropriate for an MDA? It sounds like MTA business to me.
Nope. An MTA shouldn't deal with delivery, and mailbox stuff is
delivery.
>>> Anybody can
>>> use procmail (if they actually think they want to) by using a ".forward"
>>> file, without damaging the integrity of the mail system,.
>>
>>Please provide evidence that procmail can pose such problems.
>
>It has "posed such problems" in earlier Red Hat distributions.
>
>Its locking (in 2.x?) used a different scheme than the MUA
>packages in the distributions. It did lose mail. Few noticed,
>or took enough notice, for several releases. This is the nature
>of background processes; when they go wrong, it's hard to tell
>who is responsible, or sometimes even that they went wrong.
>(This is why it's imperative that it be reliable.)
This is a configuration issue, not a code issue.
Nobody is forcing you to use procmail. If you don't like it, fine,
don't use it. But there are a lot of people using it (and using its
features for things like mailbox sorting and spam filtering); why do you
want to force your opinion on the rest of us? If you just _can't_ have
a distribution using procmail, that's fine. Build your own
distribution.
--
Chris Adams - cad...@ro.com
System Administrator - Renaissance Internet Services
I don't speak for anybody but myself - that's enough trouble.
Peter Samuelson
[Eric Lee Green <e_l_...@hotmail.com>]
> > The problem I've always had with Debian is that they require all
> > those bloody floppies for installation.
> Not in recent versions; the ISO CD image at ftp.debian.org is
> bootable. You need one floppy if you don't have a bootable CD ROM
> drive.
I'm not sure about the CD, never having installed Debian except via
pure FTP, but I've always just used three files they have in the
stable/disks-i386 directory: linux (the kernel), root.bin (compressed
minix fs image) and loadlin.exe (MS-DOS executable), and oh yeah,
install.bat (so I don't have to remember the params for loadlin.exe.)
No floppies at all. Not a whiff of rawrite. (If your cdrom isn't
ATAPI or SCSI you might have to copy resc1440.bin and drv1440.bin to a
HD partition so you can load the appropriate cdrom driver module.)
--
Peter Samuelson
<psam...@sampo.creighton.edu>
Mike Kenney
n...@nospam.cantrip.org (Nathan Myers) writes:
> The point (again!) is that it is irresponsible to ship a distribution
> with such an unreliable program as the default MDA, so that users who
> are not (yet?) competent even to evaluate its risks are nonetheless
> exposed to them.
I was trying to resist jumping into this argument but I can't let the above
comment pass...
You have yet to prove that procmail is "unreliable" (and you have yet to
define what you mean by unreliable). You have mentioned a few anecdotes
regarding bad interactions with an un-named MUA in some Red Hat distribution
but that hardly qualifies as proof. I can present plenty of anecdotes
that say procmail is reliable but that is not proof either.
Face it, it is difficult to determine the reliability of software that
someone else has written -- and complexity does not imply unreliability.
With popular "free" software (such as procmail), you know the product is
used in a wide variety of environments and this helps to expose bugs
quickly. Provided you let the maintainer(s) know about them, the bugs
usually get squashed fast (so if you know of a bug in procmail, report
it!). As for Red Hat using another default MDA, how do we know other
MDAs are reliable? How do we know Linux is reliable?
--
Mike
-----------------------------------------------------------------------------
Mike Kenney
UW Applied Physics Lab
mi...@apl.washington.edu (206) 543-1300 / (206) 543-6785 FAX
-----------------------------------------------------------------------------
Nix
In article <vc7wwf4...@saturn.cs.uml.edu>,
Albert D. Cahalan <acah...@saturn.cs.uml.edu> wrote:
> n...@nospam.cantrip.org (Nathan Myers) writes:
> > into loops, jumping out of one loop and into another, jumping into "if"
> > who have no sense. Does that inspire confidence?
>
> a great hacker who understands how to produce good fast code.
*stunned*
You think using gotos is *good*?!?????
Now I *know* you're an alien being. Either that, or you've been stuck in
a timewarp for the last twenty-odd years. :)
Me, I'd be inclined to think the author bashed out the original program
rather fast and never got around to cleaning it up. (Is this actually the
case?)
> The Linux kernel has over 1000 goto's in it. Oddly, the code
> is often more readable than equivalent code without goto.
It was not done for readabilty (and does not increase readability). It was
done to make the control flow path blatantly obvious to the compiler, as an
optimisation measure. Where (for instance) kernel scheduler code is concerned,
speed is more important than readability. procmail isn't in the same league.
If gcc used an AI as its optimiser or the kernel code was not time-critical,
the gotos would be unnecessary (and unused). (If this is nonsense, Linus
will, I am sure, say so. :) )
> The "never use 'goto'" idea is educational garbage used to stop idiots
> from using goto all over the place. That idea is just like the rule
Incorrect.
> often taught to 2nd grade kids: "never start a sentence with 'because'".
> Sure, nonsense like "Because it was hot." is bad and code that uses
> goto without reason is bad. It is unwise to condemn powerful tools
> merely because some idiots abuse them.
*sigh*
Have you actually *read* Dijkstra's _Go To Statement Considered Harmful_,
or are you just guessing? If you're just guessing, read it before coming
out with lines like that one.
It's not blocked `because of idiots', it is blocked because it rapidly
converts code into a mess that the human brain simply cannot cope with. It's
a recipe for instant combinatorial explosions, and a very, *very* bad idea.
Very low-level or absolutely time-critical code are the *only* places, IMAO,
where it is in any way acceptable. (Naturally I class portions of the Linux
kernel as `absolutely time-critical code'. How could they not be?)
I really do wonder if you've done much with large programming projects. If
not, it would explain why you said this - I thought the same, before I
noticed the rate at which goto-ed code rotted versus the rate at which
similar code not involving gotos rotted. Writing good code with gotos is
possible, sure - but it's incredibly difficult. You need to be *really*,
*really* careful whenever you make any maintenance changes, as goto
introduces so many unobvious dependencies.
I think I'll leave the rest of the anti-goto stuff to Dijkstra's classic
letter. :)
--
`... it's because acceleration equals mass times distance.' - Matt
Cloy, personal communication
Ian Burrell
In article <vc7wwf4...@saturn.cs.uml.edu>,
Albert D. Cahalan <acah...@saturn.cs.uml.edu> wrote:
>n...@nospam.cantrip.org (Nathan Myers) writes:
>>
>> No, it's not the style: it's the (literally) hundreds of goto's, jumping
>> into loops, jumping out of one loop and into another, jumping into "if"
>> statements; just an unmaintainable mess. Nobody with any sense even
>> touches code like that, so all you're left with to maintain it is people
>> who have no sense. Does that inspire confidence?
>
>It gives me confidence, since I now think that the author is
>a great hacker who understands how to produce good fast code.
>
>is often more readable than equivalent code without goto.
>
>from using goto all over the place. That idea is just like the rule
>Sure, nonsense like "Because it was hot." is bad and code that uses
>goto without reason is bad. It is unwise to condemn powerful tools
>merely because some idiots abuse them.
>
Goto has its place in C but it should be used sparingly. It is used
in the Linux kernel when it produces better code; for such uses as
jumping out of nested loops and for error handling. Gotos are good in
these cases because C doesn't have control flow constructs to support
these cases. Using gotos in those places actually helps the optimizer
and people by producing code that is more explicit and readable.
However, gotos in general contribute unreadable code and don't produce
code that is faster. Arbitrary gotos make the job of the optimizer
harder and may prevent it from applying optimizations that make the
structured code faster. Especially some of the uses Nathan mentioned:
jumping into loops, jumping into conditionals, jumping between loops.
"Never use goto" is a over-general rule, but that is rarely stated.
"Use gotos only when absolutely required" is a much better and much
more-often stated rule.
- Ian
--
ibur...@leland.stanford.edu http://www-leland.stanford.edu/~iburrell/
Finster's Law: A closed mouth gathers no feet.
Jürgen Exner
Nix wrote in message <6bqkcl$5ot$1...@esperi.demon.co.uk>...
>In article <vc7wwf4...@saturn.cs.uml.edu>,
>Albert D. Cahalan <acah...@saturn.cs.uml.edu> wrote:
>> n...@nospam.cantrip.org (Nathan Myers) writes:
>> > No, it's not the style: it's the (literally) hundreds of goto's,
jumping
>> > into loops, jumping out of one loop and into another, jumping into "if"
>> > statements; just an unmaintainable mess. Nobody with any sense even
>> > touches code like that, so all you're left with to maintain it is
people
>> > who have no sense. Does that inspire confidence?
>>
>> It gives me confidence, since I now think that the author is
>> a great hacker who understands how to produce good fast code.
>> The "never use 'goto'" idea is educational garbage used to stop idiots
>> from using goto all over the place. That idea is just like the rule
>
>
>> often taught to 2nd grade kids: "never start a sentence with 'because'".
>> Sure, nonsense like "Because it was hot." is bad and code that uses
>> goto without reason is bad. It is unwise to condemn powerful tools
>> merely because some idiots abuse them.
[lot of good comments deleted]
>I think I'll leave the rest of the anti-goto stuff to Dijkstra's classic
>letter. :)
Let me add just another remark:
Have you ever tried to write an optimization pass for a compiler, if the
language contains "goto"? As soon as you have gotos the data flow analysis
will help you almost nothing and medium-level optimization becomes virtually
impossible. Not to mention high-level optimization (in the source language
itself), which is useless because of the missing structural element of the
goto.
jue
--
Jürgen Exner; jurgenex AT microsoft.com
Sorry for this anti-spam inconvenience
Nathan Myers
Albert D. Cahalan <acah...@saturn.cs.uml.edu> wrote:
>n...@nospam.cantrip.org (Nathan Myers) writes:
>>
>> No, it's not the style: it's the (literally) hundreds of goto's, jumping
>> into loops, jumping out of one loop and into another, jumping into "if"
>> statements; just an unmaintainable mess. Nobody with any sense even
>> touches code like that, so all you're left with to maintain it is people
>> who have no sense. Does that inspire confidence?
>
>It gives me confidence, since I now think that the author is
>a great hacker who understands how to produce good fast code.
>
>is often more readable than equivalent code without goto.
Albert Calahan is absolutely not an idiot. However, he is not always right.
Most of those of us who use gotos on occasion would agree that a thousand
gotos in one program is quite a large number. Too large? That would
depend. In a large kernel where they are being used in a disciplined
way, and where the performance effect is readily characterized, it might
be fine. Still, I daresay half could be removed without harming
measurable performance.
Now, consider the relative sizes of the two programs: the Linux kernel
is about a hundred times as large as procmail. That means that the
density of gotos in procmail is about a hundred times as large as in
the kernel. Furthermore, they are used in a completely undisciplined
way. They probably result in a net slow down in the program because an
optimizer's flow analyzer must give up and punt.
A great hacker works with the compiler, not against it.
Chris Waters
Nix <df$n1x$x...@esperi.demon.co.uk> writes:
> In article <vc7wwf4...@saturn.cs.uml.edu>,
> Albert D. Cahalan <acah...@saturn.cs.uml.edu> wrote:
> > It gives me confidence, since I now think that the author is
> > a great hacker who understands how to produce good fast code.
> *stunned*
> You think using gotos is *good*?!?????
I've got to disagree with both of you here. Seeing goto-filled code
does *not* fill me with confidence. But neither does it make me think
the code is bad, per se. Not enough information is my diagnosis.
(No, I haven't looked at the procmail sources.)
> Me, I'd be inclined to think the author bashed out the original program
> rather fast and never got around to cleaning it up.
I have used goto in C. I have never used it in haste. I've never had
to "clean it up", because the only times I've used it have been after
careful analysis or profiling. It's not in my default toolbox of
stuff I use when I'm bashing out code. I can't even imagine using it
the way you seen to think people use it. Thinking that it was used in
haste and never cleaned up is one of the *last* things *I'd* infer,
and is a conclusion I'd come to only after studying the code for quite
a while.
> > The Linux kernel has over 1000 goto's in it. Oddly, the code
> > is often more readable than equivalent code without goto.
> It was not done for readabilty (and does not increase
> readability).
It's an optimization technique, and unlike many other hand-
optimization techniques in C (e.g. register variables), it can
actually be useful, i.e. it can actually make the code work
better/faster/tighter. If done well, however, it *can* increase
readability, by making the flow clearer. Having dozens of flags
tested after every few lines of code can seriously obscure what the
code is trying to accomplish.
It took me nearly a decade of professional programming to work up the
courage (and discover the desire) to use a goto. And I had to have my
face rubbed a few times in the fact that my natural inclination to use
flags and tests could, in extreme cases, actually produce *less*
readable code. Not to mention slower -- slower I don't care about
unless the profiler says I do. But readable I do care about.
There's a thread on comp.std.c about using break with named labels to
exit an outer loop in C, as you already can in perl. I was in favor
of the idea, but the opponents, who point out that you can simply use
goto to exit an inner loop, seem likely to carry the day. The fact
that it would eliminate one of the more common uses of goto in C code
seems to have no weight with the very competent programmers on the C
standards committee.
> > The "never use 'goto'" idea is educational garbage used to stop idiots
> > from using goto all over the place. That idea is just like the rule
> Incorrect.
Not only is it NOT incorrect, but the really sad part is that goto is
only one of many things that violate strict structured programming
principles. Multiple returns within a function are every bit as bad.
And yet, code with multiple returns abounds, and is written even by
people who are fanatic followers of the "no-gotos" rule. It's easier
to learn "don't use goto" than it is to actually learn what structured
programming is all about.
> Have you actually *read* Dijkstra's _Go To Statement Considered Harmful_,
> or are you just guessing?
I don't know if he has, but I certainly have. Heck, I saw it when it
first came out -- my Dad's a programmer too. My first exposure to the
religious fanaticism that is so common in our field came from
listening to him and his cronies discussing this new idea, structured
programming, back in the late sixties/early seventies.
Have you read Don Knuth's rebuttal? Or Dijkstra's letter agreeing
with Knuth? No, Don's not an advocate of the mindless use of gotos.
He, and any competent programmer, understands the dangers of goto.
But mindless rejection of goto is just as bad, especially since it's
far more widespread.
And to my mind, the main difference between Dijkstra and Knuth is that
Knuth has actually produced things I find useful. :-)
Followups should probably go to comp.software_eng or something. This
decades-old debate has very little to do with Linux. Maybe
comp.beating.a.dead.horse. :-)
hor...@collegium.adsl.net.cmu.edu
In article <6bqkcl$5ot$1...@esperi.demon.co.uk>,
Nix <df$n1x$x...@esperi.demon.co.uk> wrote:
>
> In article <vc7wwf4...@saturn.cs.uml.edu>,
> Albert D. Cahalan <acah...@saturn.cs.uml.edu> wrote:
> > > No, it's not the style: it's the (literally) hundreds of goto's, jumping
> > > into loops, jumping out of one loop and into another, jumping into "if"
> > > statements; just an unmaintainable mess. Nobody with any sense even
> > > touches code like that, so all you're left with to maintain it is people
> > > who have no sense. Does that inspire confidence?
> >
> > a great hacker who understands how to produce good fast code.
>
> *stunned*
>
> You think using gotos is *good*?!?????
>
> a timewarp for the last twenty-odd years. :)
Oops. Sounds like someone's read Dijkstra without placing it in
context or thinking about it too much.
(For reference: the Dijkstra paper is available at:
http://www.acm.org/classics/oct95
This paper spawned one of the biggest flamewars in the history of
the ACM.)
> > The Linux kernel has over 1000 goto's in it. Oddly, the code
> > is often more readable than equivalent code without goto.
>
> It was not done for readabilty (and does not increase readability). It was
> done to make the control flow path blatantly obvious to the compiler, as an
> optimisation measure. Where (for instance) kernel scheduler code is
> concerned,
> speed is more important than readability. procmail isn't in the same league.
>
> If gcc used an AI as its optimiser or the kernel code was not time-critical,
> the gotos would be unnecessary (and unused). (If this is nonsense, Linus
> will, I am sure, say so. :) )
>
> > The "never use 'goto'" idea is educational garbage used to stop idiots
> > from using goto all over the place. That idea is just like the rule
>
> Incorrect.
>
> > often taught to 2nd grade kids: "never start a sentence with 'because'".
> > Sure, nonsense like "Because it was hot." is bad and code that uses
> > goto without reason is bad. It is unwise to condemn powerful tools
> > merely because some idiots abuse them.
>
> *sigh*
>
> Have you actually *read* Dijkstra's _Go To Statement Considered Harmful_,
> or are you just guessing? If you're just guessing, read it before coming
> out with lines like that one.
>
> It's not blocked `because of idiots', it is blocked because it rapidly
> converts code into a mess that the human brain simply cannot cope with. It's
> a recipe for instant combinatorial explosions, and a very, *very* bad idea.
>
> Very low-level or absolutely time-critical code are the *only* places, IMAO,
> where it is in any way acceptable. (Naturally I class portions of the Linux
> kernel as `absolutely time-critical code'. How could they not be?)
>
Sounds like you need to read D.E. Knuth's "Structured Programming With
Goto Statements". (In case you've forgotten, Knuth is the man behind
The Art of Computer Programming). Gotos are useful in more places than
you think, and when I use them it's generally to enhance readability and
maintainability (rather than as an optimization hack). Certain types of
state machines are impossible to write readably without goto. Yes, it's
bad to use gotos everywhere, but there are still many circumstances
where the goto is the software engineer's (not just the hacker's) friend.
Yes, use them very rarely. That's different from avoiding them completely,
though.
"Please don't fall into the trap of believing that I am terribly
dogmatical about [the goto statement]. I have the uncomfortable
feeling that others are making a religion out of it, as if the
conceptual problems of programming could be solved by a single trick,
by a simple form of coding discipline!" -Dijkstra
> I think I'll leave the rest of the anti-goto stuff to Dijkstra's classic
> letter. :)
Here are some other things you might want to read:
C. Böhm and G. Jacopini, "Flow Diagrams, Turing Machines, and Languages
with Only Two Formation Rules",
Communications of the ACM 9 (1966), pp. 366-371.
E. W. Dijkstra, "Notes on Structured Programming", in Dahl, Dijkstra
and Hoare, Structured Programming,
Academic Press, 1972, pp. 1-82.
D. E. Knuth, "Structured Programming with Goto Statements", ACM
Computing Surveys 6 (1974), pp. 261-302.
-Sumner
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/ Now offering spam-free web-based newsreading
Martin J. Maney
In comp.os.linux.development.system Albert D. Cahalan <acah...@saturn.cs.uml.edu> wrote:
> Danger sign: you have goto's overlapping in opposite directions.
Such as the first example I found in procmail.c (grep is pretty good
at finding gotos and labels - you ought to try it sometime):
goto findrc;
fake_rc:
findrc:
goto fake_rc;
(intervening code omitted, of course)
The silliest aspect of this whole discussion is the way those who make
the most sweeping statements seem to have actually read the code the
least. :-(
Martin J. Maney
In comp.os.linux.development.system Chris Ebenezer <chr...@bnr.ca> wrote:
> acah...@saturn.cs.uml.edu (Albert D. Cahalan) writes:
> : I am aware that someone (Turing?) defended goto, and that Dijkstra then
> : admitted that goto could have uses and that it would not be wise to
> : remove goto from algorithms to which it naturally applies.
> It was Knuth actually :-
> "Structured Programming with go to Statements", Knuth
> ACM Computing Surveys, Vol. 6, No. 4, Dec. 1974
And Knuth isn't really defending the goto for general use - as he says
up front, the title was chosen more for its shock value than as an
accurate synopsis of the article. He does defend the presence of the
goto in procedural languages, but only in fairly narrow circumstances.
His longest example of optimization ends up having the gotos optimized
out of it, IIRC. :-)
Martin J. Maney
In comp.os.linux.development.system hor...@collegium.adsl.net.cmu.edu wrote:
> Here are some other things you might want to read:
> C. Böhm and G. Jacopini, "Flow Diagrams, Turing Machines, and Languages
> with Only Two Formation Rules",
> Communications of the ACM 9 (1966), pp. 366-371.
> E. W. Dijkstra, "Notes on Structured Programming", in Dahl, Dijkstra
> and Hoare, Structured Programming,
> Academic Press, 1972, pp. 1-82.
> D. E. Knuth, "Structured Programming with Goto Statements", ACM
> Computing Surveys 6 (1974), pp. 261-302.
All of these (and,as they say, much more) can be found in Yourdon's
_Classics in Software Engineering_, if it's still in print. If it
isn't, I'm not telling where I have hidden my own falling-apart from
repeated readings copy. :-)
Roger Gonzalez
There's a cool way to avoid gotos for the escape-from-a-block case
that I picked up from some RSA code. It basically uses a do-while
as an escapable container block. This is the "negative" version,
the semantics can be easily reversed.
char *spoo(int n)
{
char *spoobuf = NULL;
do /* once */
{
spoobuf = (char *) malloc(n);
if (!spoobuf)
break;
if (canfail(spoobuf) == -1)
break;
if (!succeeded(spoobuf))
break;
if (itfailed(spoobuf))
break;
return spoobuf;
} while (0); /* end do-once */
if (spoobuf)
free(spoobuf);
/* other cleanup here */
return NULL;
}
-Roger
Roger Gonzalez Datapult Communications
ar...@datapult.com http://datapult.com/
Andi Kleen
Roger Gonzalez <r...@xyzzy.datapult.com> writes:
> There's a cool way to avoid gotos for the escape-from-a-block case
> that I picked up from some RSA code. It basically uses a do-while
> as an escapable container block. This is the "negative" version,
> the semantics can be easily reversed.
But wouldn't you say that gotos are clearer in this case?
-Andi
Marco Anglesio
On 11 Feb 1998 01:10:59 -0500, Albert D. Cahalan <acah...@saturn.cs.uml.edu> wrote:
>Nix <df$n1x$x...@esperi.demon.co.uk> writes:
>> Have you actually *read* Dijkstra's _Go To Statement Considered Harmful_,
>> or are you just guessing? If you're just guessing, read it before coming
>> out with lines like that one.
>
>admitted that goto could have uses and that it would not be wise to
>remove goto from algorithms to which it naturally applies.
Knuth, I believe. Turing's been dead for forty years or more.
marco
marco anglesio mpa at squawk dot ml dot org | Life would be tolerable
visit squawk: http://squawk.ml.org | but for its amusements.
read SURFACE: http://asus.queensu.ca/~surface | -- G. B. Shaw
Albert D. Cahalan
hor...@collegium.adsl.net.cmu.edu writes:
> Here are some other things you might want to read:
>
> C. Böhm and G. Jacopini, "Flow Diagrams, Turing Machines, and Languages
> with Only Two Formation Rules",
> Communications of the ACM 9 (1966), pp. 366-371.
>
> E. W. Dijkstra, "Notes on Structured Programming", in Dahl, Dijkstra
> and Hoare, Structured Programming,
> Academic Press, 1972, pp. 1-82.
>
> D. E. Knuth, "Structured Programming with Goto Statements", ACM
> Computing Surveys 6 (1974), pp. 261-302.
Is there any hope for those of us that weren't ACM members in 1966?
You can't find those articles just anywhere.
p...@foxharp.boston.ma.us
although clever, this trick is far worse than using an explicit goto.
the do/while construct is an iteratative construct. using it
implies iteration will take place, and i, as the reader, need
to get to the end to find that we're oh-so cleverly relying on a
side effect of the loop semantic to give a non-looping effect.
and all this so that we can avoid using a well-understood feature of the
language in a way that is commonly accepted as being reasonable.
doesn't add up, in my opinion.
paul
(that being said, it has been pointed out to me that using this trick
in C++ _can_ make sense, since leaving the block via break can cause
desctructors to be invoked that would not be invoked via the goto.
if used for that reason, i would advocate using macros to hide the
do/while implementation details, since the expectation of do/while
semantics is at odds with the author's intention.)
: There's a cool way to avoid gotos for the escape-from-a-block case
: that I picked up from some RSA code. It basically uses a do-while
: as an escapable container block. This is the "negative" version,
...
: char *spoo(int n)
: {
: char *spoobuf = NULL;
:
: do /* once */
: {
: spoobuf = (char *) malloc(n);
: if (!spoobuf)
: break;
...
: if (itfailed(spoobuf))
: break;
:
: return spoobuf;
: } while (0); /* end do-once */
:
: if (spoobuf)
: free(spoobuf);
: /* other cleanup here */
: return NULL;
--
=---------------------
paul fox, p...@foxharp.boston.ma.us (arlington, ma, where it's 46.8 degrees)
Preston F. Crow
I often resort to goto to break out of multi-level loops, but that's
about it. If there was an optional argument to the C statements
'break' and 'continue' that indicated how many levels to break out of
(instead of just the top level), then I would have little need for
gotos in C.
Of course, some have argued that break and continue are as evil as
goto (at least someone once told me this). I don't think I agree with
that, though. Still, if C allowed a loop where the condition was
checked at a given point in the middle (instead of the beginning or
end as with while and do loops respectively), there would be less need
for them. Not that I would advocate such a construct being added.
I've heard people advocate using gotos for exception handling in C.
In general, if you can point to a general construction that is cleaner
when written with a goto, you are probably looking at a place where an
extension to the language might be a good idea.
Of course, it it's a matter of optimization, it is at least better to
use C with goto statements than assembly, at least if you want to port
the code.
--PC
--
"And he [Christopher Robin] respects Owl, because you can't help respecting
anybody who can spell TUESDAY, even if he doesn't spell it right; but spelling
isn't everything. There are days when spelling Tuesday just doesn't matter."
-- _The House at Pooh Corner_ by A.A. Milne
Andi Kleen
p...@foxharp.boston.ma.us writes:
> (that being said, it has been pointed out to me that using this trick
> in C++ _can_ make sense, since leaving the block via break can cause
> desctructors to be invoked that would not be invoked via the goto.
> if used for that reason, i would advocate using macros to hide the
> do/while implementation details, since the expectation of do/while
> semantics is at odds with the author's intention.)
In C++ you would use try/catch.
-Andi
Paul D. Smith
%% cr...@coos.dartmouth.edu (Preston F. Crow) writes:
pfc> I often resort to goto to break out of multi-level loops, but
pfc> that's about it. If there was an optional argument to the C
pfc> statements 'break' and 'continue' that indicated how many levels
pfc> to break out of (instead of just the top level), then I would
pfc> have little need for gotos in C.
Oh boy, I hope you're not advocating something like "break 4;". What a
nightmare. I harken back to the days of BASIC and "gosub 3000"... only
much worse! :-/ :(
Labelled break and continue statements are definitely better,
but... they're only marginally different than the current goto anyway.
If you want Ada, you know where to find it...
C's goto is very powerful, and it deserves a place in the experienced
programmer's toolchest. It makes code more readable and maintainable,
when properly used.
By all means, if you don't know how to use it properly, it's better to
not use it at all!
--
-------------------------------------------------------------------------------
Paul D. Smith <psm...@baynetworks.com> Network Management Development
"Please remain calm...I may be mad, but I am a professional." --Mad Scientist
-------------------------------------------------------------------------------
These are my opinions--Bay Networks takes no responsibility for them.
Frank Sweetser
psm...@baynetworks.com (Paul D. Smith) writes:
> %% cr...@coos.dartmouth.edu (Preston F. Crow) writes:
>
> pfc> I often resort to goto to break out of multi-level loops, but
> pfc> that's about it. If there was an optional argument to the C
> pfc> statements 'break' and 'continue' that indicated how many levels
> pfc> to break out of (instead of just the top level), then I would
> pfc> have little need for gotos in C.
>
> Oh boy, I hope you're not advocating something like "break 4;". What a
> nightmare. I harken back to the days of BASIC and "gosub 3000"... only
> much worse! :-/ :(
>
> Labelled break and continue statements are definitely better,
> but... they're only marginally different than the current goto anyway.
actually, perl does labelled break/next statements quite nicely, by
allowing you to label blocks of code. for example
LABEL:{
while(some_nasty_nested_loop){
if(time_to_exit){
last LABEL
}
}
}
this is especially nice w/emacs, because then you get the whole block
auto-indented, which makes for good readability.
--
Frank Sweetser rasmusin at wpi.edu fsweetser at blee.net | PGP key available
paramount.res.wpi.net RH 5.0 kernel 2.0.33/2.1.85 i586 | at public servers
Sigh. I like to think it's just the Linux people who want to be on
the "leading edge" so bad they walk right off the precipice.
(Craig E. Groeschel)
Nix
In article <6brk7e$cdb$1...@nnrp2.dejanews.com>,
<hor...@collegium.adsl.net.cmu.edu> wrote:
> In article <6bqkcl$5ot$1...@esperi.demon.co.uk>,
> Nix <df$n1x$x...@esperi.demon.co.uk> wrote:
> >
> > Now I *know* you're an alien being. Either that, or you've been stuck in
> > a timewarp for the last twenty-odd years. :)
>
> Oops. Sounds like someone's read Dijkstra without placing it in
> context or thinking about it too much.
I was simplifying a bit for argument's sake. (Perhaps I shouldn't've done
that, but I wanted to slap Albert down good and hard before anyone believed
him.)
> This paper spawned one of the biggest flamewars in the history of
> the ACM.)
And led to an apparent desire on the part of the editors not to publish
anything controversial, for a good few years :)
> > Very low-level or absolutely time-critical code are the *only* places, IMAO,
> > where it is in any way acceptable. (Naturally I class portions of the Linux
> > kernel as `absolutely time-critical code'. How could they not be?)
> >
>
> Sounds like you need to read D.E. Knuth's "Structured Programming With
> Goto Statements". (In case you've forgotten, Knuth is the man behind
> The Art of Computer Programming). Gotos are useful in more places than
> you think, and when I use them it's generally to enhance readability and
Can be useful when jumping out of really deeply nested loops - in theory.
IMO, that's what exceptions are for (but then I'm a C++ man, really). In
the absence of exceptions, signalling error conditions across a lot of code
calls for goto - but the goto in C doesn't allow that kind of thing, hence
longjmp. IMO the goto *in C* is normally useless for other things. A truly
general `jump anywhere' goto is useful in many places - e.g., in parsers.
But it shouldn't be used to replace other control flow constructs (which
is a bad habit a lot of goto users tend to slip into IME.)
> Certain types of
> state machines are impossible to write readably without goto. Yes, it's
e.g., parsers.
> Yes, use them very rarely. That's different from avoiding them completely,
> though.
Agreed.
> "Please don't fall into the trap of believing that I am terribly
> dogmatical about [the goto statement]. I have the uncomfortable
> feeling that others are making a religion out of it, as if the
> conceptual problems of programming could be solved by a single trick,
> by a simple form of coding discipline!" -Dijkstra
Once, I made a religion out of it, and it is possible I let a bit of that
back out in my tirade. This was principally because I think that underusing
goto is much better than overusing it, and that when you need to use it it
is obvious, because nothing else fits. The problem with goto is that it can
be used as a `one-size-fits-all' shoe - i.e., that if it isn't tried *last*
of all the control-flow constructs, that it can be used much too much.
> Here are some other things you might want to read:
>
> C. Böhm and G. Jacopini, "Flow Diagrams, Turing Machines, and Languages
> with Only Two Formation Rules",
> Communications of the ACM 9 (1966), pp. 366-371.
>
> E. W. Dijkstra, "Notes on Structured Programming", in Dahl, Dijkstra
> and Hoare, Structured Programming,
> Academic Press, 1972, pp. 1-82.
>
> D. E. Knuth, "Structured Programming with Goto Statements", ACM
> Computing Surveys 6 (1974), pp. 261-302.
Many thanks, grabbed. I've read Knuth, but not the Dijkstra or Bohm.
(God only knows where I'll get that '66 CACM from, though. The Uni
library only goes back to ~'83.)
--
`... I find that if I put certain kinds of meat in a casserole dish, in
water, and add an oxo cube and some salt, and forget about it for a
few hours, it goes soft enough to chew.' - the *real* art of cookery
Nix
In article <rnbiuqm...@bnr.ca>, Chris Ebenezer <chr...@bnr.ca> wrote:
>
> Nix <df$n1x$x...@esperi.demon.co.uk> writes:
> : It's not blocked `because of idiots', it is blocked because it rapidly
> : converts code into a mess that the human brain simply cannot cope with. It's
> : a recipe for instant combinatorial explosions, and a very, *very* bad idea.
>
As I said in another response, I was overgeneralising 'cos I believe that
where goto is concerned, underuse is rather better than overuse. I've seen
too much code where it was overused, y'see. :(
> : Very low-level or absolutely time-critical code are the *only* places, IMAO,
>
> IMAO = In my absolute opinion ? :-). Try running a yacc/bison parser
A == Arrogant - or perhaps `absolutist' or `argumentative'...
> file through those programs then grep and count the amount of 'goto's, i
> think you'll be suprised.
Hardly. They'll be stuffed with 'em. Because of... oh, you said it already
below. :)
> These programs create their output by
> constructing FSMs which are easiest to express using gotos. So your
> absolute opinion has to be altered a tad to bring it into line with
> reality.
I was overgeneralising. Besides, I'd be surprised if gotos were necessary
in procmail much outside of the regexp parser. (Does procmail use the
GNU regexp library, btw?) In the regexp parser, of course, they'd be a
godsend.[1]
[1] or Knuthsend. Kind of like TeX...
Tim Smith
Preston F. Crow <cr...@coos.dartmouth.edu> wrote:
>I often resort to goto to break out of multi-level loops, but that's
>about it. If there was an optional argument to the C statements
>'break' and 'continue' that indicated how many levels to break out of
>(instead of just the top level), then I would have little need for
>gotos in C.
...until you got tired of tracking down bugs from getting the level count
wrong. A multilevel break (or continue) needs to use a label, not a count,
to be generally useful.
The syntax I'd like is for the label for a for or while to be between
the for or while and the opening paren of the condition:
for ( ... ) /* loop without label */
for label ( ... ) /* loop with label */
while ( ... ) /* without label */
while label ( ... ) /* with label */
This looks good, in my opinion, and is easy to parse.
Break would then look like this:
break; /* break out of innermost loop */
break label; /* break out of loop with specified label */
Continue would be handled similarly.
--Tim Smith
hor...@collegium.adsl.net.cmu.edu
In article <m24t26v...@xyzzy.datapult.com>,
Roger Gonzalez <r...@xyzzy.datapult.com> wrote:
>
>
> There's a cool way to avoid gotos for the escape-from-a-block case
> that I picked up from some RSA code. It basically uses a do-while
> as an escapable container block. This is the "negative" version,
"cool"? Using gotos would be a lot clearer. Using do/while implies
that there's a loop, and there isn't.
Andrew Bardsley
In article <6btkrm$1o8$1...@halcyon.com>, t...@halcyon.com (Tim Smith) writes:
> Preston F. Crow <cr...@coos.dartmouth.edu> wrote:
> >I often resort to goto to break out of multi-level loops, but that's
> >about it. If there was an optional argument to the C statements
> >'break' and 'continue' that indicated how many levels to break out of
> >(instead of just the top level), then I would have little need for
> >gotos in C.
>
> ...until you got tired of tracking down bugs from getting the level count
> wrong. A multilevel break (or continue) needs to use a label, not a count,
> to be generally useful.
>
> The syntax I'd like is for the label for a for or while to be between
> the for or while and the opening paren of the condition:
>
> for ( ... ) /* loop without label */
>
> for label ( ... ) /* loop with label */
How about Java's labelled break statements.
- Andrew
--
_______________
___/Andrew Bardsley\____________________________________________
University_of_Manchester Dept. of Computer Science AMULET Group
PhD__/student Mail:\bardsleyATcs.man.ac.uk_Tel:_+44_161_275_6844
Snail: Room IT302, Man. Uni., Oxford Rd, Manchester, M13 9PL, UK
Roger Gonzalez
p...@foxharp.boston.ma.us writes:
> although clever, this trick is far worse than using an explicit goto.
>
> the do/while construct is an iteratative construct. using it
> implies iteration will take place, and i, as the reader, need
> to get to the end to find that we're oh-so cleverly relying on a
> side effect of the loop semantic to give a non-looping effect.
I had the same reaction when I first saw it, but it grew on me.
With sufficient comments, it can be made very clear. I'd use
macros to hide the semantics, but I wasn't able to come up
with any that I could use without confusing the emacs C mode
indentation.
Martin J. Maney
In comp.os.linux.development.system Tim Smith <t...@halcyon.com> wrote:
> ...until you got tired of tracking down bugs from getting the level count
> wrong. A multilevel break (or continue) needs to use a label, not a count,
> to be generally useful.
The analogy with using a symbolic name rather than a literal magic
value in your code is pretty compelling. ;-)
And of course at this point the only difference between the
generalized break and a goto is a little bit of syntax. My own
preference is to use the goto and label:, chiefly because they stand
out like a sore thumb in well-written code. In something like
procmail's main(), with one goto for every thirty-some lines... well,
a mess is a mess, and cosmetic measures aren't going to accomplish
much for it anyway. :-(
FWIW, I doubt I've wanted a multi-level break as often as once a year.
Milage no doubt varies with style in this as in so much else.
> break; /* break out of innermost loop */
> break label; /* break out of loop with specified label */
One dificulty is that the "break label" form could be the innermost
loop, too. I would wager that given this feature, there would quickly
arise a popular style that labeled all loops and breaks in the
mistaken belief that redundant specification was an advantage. See,
by way of analogy, "Hungarian" notation. <bletch, bletch>
What I would like more than any such syntactic addition would be a
brief synopsis of the loop's invariants. I am perhaps overly fond of
C's for(;;) construct even when it gets excessively long exactly
because it provides a consistent place to put the code that
establishes, tests, and maintains the loop invariant.
Sequence, if/else, and a simple looping construct such as while are
all that is necessary; the rest is accomodation for uses so common as
to deserve canonification, and by its nature there can be disagreement
about just what falls into this set. Goto is the escape hatch to let
you express uncommon control structures efficently (when that's
essential) and, sometimes (as for some FSMs), cleanly.
Nathan Myers
Mats Andtbacka <at> wrote:
>>Just in case I need to repeat this: I never said, "Nobody should use
>>procmail". I don't know *anybody* who says it. I said "It should not
>>be the default MDA in a distribution." Those are fundamentally different
>>statements, but every posting I have seen defending procmail pretended
>>that I had said the former.
>
>you may even have a valid argument, but i fail to see why it would not
>apply to sendmail just as well. it is likely every bit as complex as
>procmail, and has a known history of bugginess procmail apparently
>lacks.
If I were making decisions about Red Hat's distribution, it would
certainly not install sendmail by default, though sendmail would
certainly be on the CD. Debian's installer encourages people toward
exim or smail. I would probably be running exim if the default
installation set it up appropriately for my needs.
Larry Blanchard
Tim Smith wrote:
>
<snip>
> Break would then look like this:
>
> break; /* break out of innermost loop */
>
> break label; /* break out of loop with specified label */
Other than different character strings, I see no difference between
"break label" and "goto label". Political correctness, perhaps?
--
Larry Blanchard - Old roses, old motorcycles, and old trains
Homo Sapiens is a goal, not a description.
Frank Sweetser
Larry Blanchard <lar...@boink.net> writes:
> Tim Smith wrote:
> >
> <snip>
>
> > Break would then look like this:
> >
> > break; /* break out of innermost loop */
> >
> > break label; /* break out of loop with specified label */
>
> Other than different character strings, I see no difference between
> "break label" and "goto label". Political correctness, perhaps?
goto jumps to a particular point. using labels allows you to reference
arbitrary blocks of code with break, and related functions such as
continue, or in perl, last and next. it also puts the whole chunk of code
you're breaking out of in brackets, which helps improve readability.
--
Frank Sweetser rasmusin at wpi.edu fsweetser at blee.net | PGP key available
paramount.res.wpi.net RH 5.0 kernel 2.0.33/2.1.85 i586 | at public servers
When all else fails, pour a pint of Guinness in the gas tank, advance
the spark 20 degrees, cry "God Save the Queen!", and pull the starter knob.
-- MG "Series MGA" Workshop Manual
Klaus-Georg Adams
Larry Blanchard <lar...@boink.net> writes:
>
> Tim Smith wrote:
> >
> <snip>
>
> > Break would then look like this:
> >
> > break; /* break out of innermost loop */
> >
> > break label; /* break out of loop with specified label */
>
> Other than different character strings, I see no difference between
> "break label" and "goto label". Political correctness, perhaps?
The problem is not so much the `goto' than the `comefrom'. When you
see a label in program text, you never know where the controlflow will
come from. With a labeled loop this is not a problem. I rather liked
the feature when I saw it in Fortran 90.
-- kga
-------------------------------------------------------------------------
Klaus-Georg Adams Email: Klaus-Ge...@chemie.uni-karlsruhe.de
Institut f. Anorg. Chemie II Tel: 0721 608 3485
Uni Karlsruhe
-------------------------------------------------------------------------
Wayne Schlitt
In <34E32C...@boink.net> Larry Blanchard <lar...@boink.net> writes:
>
> Other than different character strings, I see no difference between
> "break label" and "goto label". Political correctness, perhaps?
Which direction does the program flow after it does a "break label"?
Which way after a "continue label"? Which way after a "goto label"?
Back in the days when I did mainframe assembler programming, I used a
consistent notation of ending a label with a "c" (a la the fortran
continue statement) if it branched forward, and "l" (loop) if it
branched backwards. No label was used for both purposes. Actually,
most of the characters in the label was dedicated helping you locate
*where* the label would be. Comments on the branch and/or the label
target told you *why* you would want to go there. (label targets were
never instructions, always place holders ("equ *"s).)
While I don't avoid goto's at all costs, and I generally argue that
goto's have their place in well structured code, I *very* rarely use
them. For example, instead of using a goto to break out of a deeply
nested set of loops, I typically have those loops in a small function
(better style anyway IMHO), and use a return statement. I don't like
gratuitous flag variables, but I often end up having to use flag
variables anyway, because I need to record *why* the loop terminated.
Instead of using goto's to implement a finite state machine, I usually
use a loop with a switch statement and a control variable that gets
assigned with defined constants. Yes, this is effectively equivalent
to goto's, and probably less efficient, but I almost always use the
control variable (and a previous state control variable) to detect
error conditions in my implementation of the FSM and for error
messages in general.
The company that I work for has a software package with ~1.5 million
lines of C code that has been developed over the last 15 years by
dozens of different people. It has about 60 goto's in it almost all
written by a structural engineer that didn't know anything about
computers when he started at the company. Yes, I would say that if we
*added* another 60-100 goto's, we could make the code "cleaner", but
the vast majority of "problems" with the code have *nothing* to do
with goto's or the lack there of.
*blah* Given the choice, I would rather see no goto's every used than
to see more goto's used than are already being coded in all the
programs everywhere. I have done a lot of work in Forth which *has*
no goto's, and my complaints about Forth are about other things.
IF YOU ARE USING A GOTO, YOU ARE ALMOST CERTAINLY NOT THINKING
CLEARLY OR DOING FALSE OPTIMIZATIONS.
-wayne
--
Wayne Schlitt can not assert the truth of all statements in this
article and still be consistent.
Joe Buck
In <34E32C...@boink.net> Larry Blanchard <lar...@boink.net> writes:
> Other than different character strings, I see no difference between
> "break label" and "goto label". Political correctness, perhaps?
Larry, if you ever write an optimizing compiler, and attempt to
do dataflow analysis, the difference will become clear to you.
break and continue don't mess things up (you still have a nice, easy
to analyze loop structure); unlimited goto will hose you in a hurry.
If you use gotos in an unstructured way, compilers will do a poor job
of optimizing your code (unless they first transform your code to a
structured form internally -- unfortunately this transformation can
increase the size of your code by as much as 2^n (1<<n for C folk)
where n is the number of gotos).
There's only one exception I can think of: a goto to break out of
more than one loop. That doesn't mess up dataflow analysis and isn't
that confusing to readers of the code. For that reason Perl provides
a construct to do this.
--
-- Joe Buck
"One good rule for avoiding brain death in the mediascape is to question
everything that is not being questioned." -- Jon Carroll
Joseph H Allen
In article <6c7i83$3...@hermes.synopsys.com>,
Joe Buck <jb...@synopsys.com> wrote:
>
>In <34E32C...@boink.net> Larry Blanchard <lar...@boink.net> writes:
>> Other than different character strings, I see no difference between
>> "break label" and "goto label". Political correctness, perhaps?
>Larry, if you ever write an optimizing compiler, and attempt to
>do dataflow analysis, the difference will become clear to you.
>break and continue don't mess things up (you still have a nice, easy
>to analyze loop structure); unlimited goto will hose you in a hurry.
>If you use gotos in an unstructured way, compilers will do a poor job
>of optimizing your code (unless they first transform your code to a
>structured form internally -- unfortunately this transformation can
>increase the size of your code by as much as 2^n (1<<n for C folk)
>where n is the number of gotos).
C compilers already have to handle gotos, so they already have to do complex
dataflow analysis. So... loops are tranformed into gotos before you get to
the dataflow analysis (which then proceedes to find the loops again). So it
ends up that break and goto are no different in C except for code
appearance.
--
/* jha...@world.std.com (192.74.137.5) */ /* Joseph H. Allen */
int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
+r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2
]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}
Larry Blanchard
Joseph H Allen wrote:
>
> In article <6c7i83$3...@hermes.synopsys.com>,
> Joe Buck <jb...@synopsys.com> wrote:
> >
> >In <34E32C...@boink.net> Larry Blanchard <lar...@boink.net> writes:
> >> Other than different character strings, I see no difference between
> >> "break label" and "goto label". Political correctness, perhaps?
>
> >Larry, if you ever write an optimizing compiler, and attempt to
> >do dataflow analysis, the difference will become clear to you.
> C compilers already have to handle gotos, so they already have to do complex
> dataflow analysis. So... loops are tranformed into gotos before you get to
> the dataflow analysis (which then proceedes to find the loops again). So it
> ends up that break and goto are no different in C except for code
> appearance.
Thank you - I was beginning to wonder if I'd gone though the looking
glass without noticing :-).
Joe Buck
jha...@world.std.com (Joseph H Allen) writes:
>C compilers already have to handle gotos, so they already have to do complex
>dataflow analysis. So... loops are tranformed into gotos before you get to
>the dataflow analysis (which then proceedes to find the loops again). So it
>ends up that break and goto are no different in C except for code
>appearance.
This is only correct if the gotos are equivalent in structure to loops and
if-then-else statements. (break or continue effectively just put the rest
of the loop inside an "if" and are thus no problem). gotos that jump into
the middle of loops or the like will force the compiler either to do a
transformation that expands the code size, or not perform some
optimizations.
Ian Burrell
In article <EoG2A...@world.std.com>,
Joseph H Allen <jha...@world.std.com> wrote:
>
>C compilers already have to handle gotos, so they already have to do complex
>dataflow analysis. So... loops are tranformed into gotos before you get to
>the dataflow analysis (which then proceedes to find the loops again). So it
>ends up that break and goto are no different in C except for code
>appearance.
>
True, the optimizer and data-flow analyzers have to deal with
arbitrary gotos because they usually work with intermediate code where
loops and higher-level constructs have been removed. For example, the
optimizer can detect a loop formed out of gotos and treat it the same
as a programming language loop.
However, there is a big difference betweens nicely structured
constructs and the code the formed by arbitrary use of branches and
jumps. For example, jumping into the middle of a loop produces an
irreducible flow graph that needs to be removed before it can be
analyzed. This is what increases the code size and gives the compiler
trouble. Such problems can't be produced with well-structured code.
As the previous posters said, the compiler has no trouble breaking out
of loops and other well-structured uses of gotos.
- Ian
--
ibur...@leland.stanford.edu http://www-leland.stanford.edu/~iburrell/
Kinkler's First Law: Responsibility always exceeds authority.
Joseph H Allen
In article <6cao79$1...@epic7.Stanford.EDU>,
Ian Burrell <ibur...@leland.Stanford.EDU> wrote:
>However, there is a big difference betweens nicely structured
>constructs and the code the formed by arbitrary use of branches and
>jumps. For example, jumping into the middle of a loop produces an
>irreducible flow graph that needs to be removed before it can be
>analyzed. This is what increases the code size and gives the compiler
>trouble. Such problems can't be produced with well-structured code.
>As the previous posters said, the compiler has no trouble breaking out
>of loops and other well-structured uses of gotos.
Ok, I thought I'd try this with a bunch of compilers I have access to and
see what happens. Here are two equivalent loops with an obvious strength
reduction, but the second has a goto:
nogoto() {
int row=0,z;
do {
z=bill(row++*80);
if(z) tom();
} while(z);
}
yesgoto() {
int row=0;
goto into;
do {
tom();
into:;
} while(bill(row++*80));
}
The results are very interesting. Basically yesgoto() makes better code on
everything except for gcc. This table lists the number of instructions in
the inner loop and gives a '*' if the compiler converted the multiply into
an add. The problem with gcc is that it didn't convert the multiply to an
add in yesgoto(), but it did in nogoto(). It did convert the multiply into
a series of shifts and adds, which happens to be just as fast as nogoto()
for this particular constant. Note that Turbo-C and the freeware lcc are
not optimizing compilers. Note that the Silicon Graphics compiler is for
MIPS and everything else is for x86.
Anyway, you are right that gotos screw up optimizations in some compilers
and that in any case they produce very different code from the loops without
gotos.
nogoto yesgoto
------ -------
lcc-4.0: 16 11
Turbo-C: 15 11
Microsoft VC++: 11 * 8 *
Watcom-C 16: 10 * 7 *
Watcom-C 32: 10 * 7 *
GCC: 9 * 9
SGI IRIX cc: 7 * 5 *
Here's the actual code. Notice how nice (short) the assembly language is
for the RISC processor:
'nogoto' Turbo-C v2.0:
@4: mov ax,di
mov dx,80
mul dx
mov word ptr [bp-2],ax
inc di
push ax
call near ptr _bill
inc sp
inc sp
mov si,ax
or si,si
je @2
call near ptr _tom
@2: or si,si
jne @4
'goto' Turbo-C v2.0:
jmp short @3
@5: call near ptr _tom
@3: mov ax,si
inc si
mov dx,80
mul dx
push ax
call near ptr _bill
inc sp
inc sp
or ax,ax
jne @5
'nogoto' Watcom-C v11 16-bit:
L$1:mov ax,dx
call bill_
add dx,0x0050
mov bx,ax
test ax,ax
jne L$3
L$2:test bx,bx
jne L$1
ret
L$3:call tom_
jmp L$2
'goto' Watcom-C v11 16-bit:
L$1:mov ax,dx
call bill_
add dx,0x0050
test ax,ax
jne L$2
ret
L$2:call tom_
jmp L$1
'nogoto' Watcom-C v11 32-bit:
L$1:mov eax,edx
call bill_
add edx,0x00000050
mov ecx,eax
test eax,eax
jne L$3
L$2:test ecx,ecx
jne L$1
ret
L$3:call tom_
jmp L$2
'goto' Watcom-C v11 32-bit:
L$1:mov eax,edx
call bill_
add edx,0x00000050
test eax,eax
jne L$2
ret
L$2:call tom_
jmp L$1
'nogoto' VC++ v5.0:
$L85: mov eax, edi
add edi, 80
push eax
call _bill
mov esi, eax
add esp, 4
test esi, esi
je SHORT $L95
call _tom
test esi, esi
jne SHORT $L85
$L95:
'goto' VC++ v5.0:
$into$83:call _tom
mov eax, esi
add esi, 80
push eax
call _bill
add esp, 4
test eax, eax
jne SHORT $into$83
'nogoto' gcc v2.7.2:
.L8: movl %ebx,%eax
addl $80,%ebx
pushl %eax
call bill
addl $4,%esp
testl %eax,%eax
je .L13
call tom
jmp .L8
.L13:
'goto' gcc v2.7.2:
.globl bar
.L9: call tom
.L11: leal (%ebx,%ebx,4),%eax bx+bx*4 -> ax
sall $4,%eax ax * 16 -> ax
pushl %eax
incl %ebx
call bill
addl $4,%esp
testl %eax,%eax
jne .L9
'nogoto' lcc v4.0:
L2: mov edi,dword ptr (-12)[ebp]
lea esi,(1)[edi]
mov dword ptr (-12)[ebp],esi
imul edi,edi,80
mov dword ptr (-8)[ebp],edi
mov edi,dword ptr (-8)[ebp]
push edi
call _bill
add esp,4
mov dword ptr (-4)[ebp],eax
cmp dword ptr (-4)[ebp],0
je L5
call _tom
add esp,0
L5:
L3: cmp dword ptr (-4)[ebp],0
jne L2
'goto' lcc v4.0:
jmp L2
L3: call _tom
add esp,0
L2:
L4: mov edi,dword ptr (-4)[ebp]
lea esi,(1)[edi]
mov dword ptr (-4)[ebp],esi
imul edi,edi,80
push edi
call _bill
add esp,4
cmp eax,0
jne L3
'nogoto' SGI cc:
$32: move $4, $16
addu $16, $16, 80
jal bill
move $17, $2
beq $2, 0, $33
jal tom
$33: bne $17, 0, $32
'goto' SGI cc:
$32: jal tom
$33: move $4, $16
addu $16, $16, 80
jal bill
bne $2, 0, $32
Linus Torvalds
In article <6cao79$1...@epic7.Stanford.EDU>,
Ian Burrell <ibur...@leland.Stanford.EDU> wrote:
>
>However, there is a big difference betweens nicely structured
>constructs and the code the formed by arbitrary use of branches and
>jumps. For example, jumping into the middle of a loop produces an
>irreducible flow graph that needs to be removed before it can be
>analyzed. This is what increases the code size and gives the compiler
>trouble. Such problems can't be produced with well-structured code.
It can easily be done without goto's, using only "structured
constructs". Admittedly nobody calls this well-structured code ;)
i = 1;
switch (-1) {
do {
printf("i=%d\n", i);
case -1:
printf("i=%d\n", i);
} while (++i < 10);
}
The point being that you can mess up source code multiple ways, and
goto's aren't the worst of your problems.
Yes, goto's can result in worse code. But goto's can result in better
code too, so what's the point here?
The fact is that bad programmers generate bad code, regardless of
whether they use goto's or not. Blaming bad code on goto's is silly,
it's a tool like any other, and can be mis-used like any other.
You can create a better _simple_ compiler if your language does not have
goto's (and doesn't allow the ugly case construct above that C allows).
But any compiler worth anything at all can handle goto's as well as
anything else, and if it makes the source code better structured then it
often makes the compiler generate better code too.
Goto's are often very useful for error cases, or odd cases that aren't
structured and where structured constructs only result in strange on
non-obvious code. These cases may not be common, but they are no less
valid for all that..
So people, please don't vilify the poor goto, nor make it anything more
than it is. It's a supremely useful construct in some cases, and a
language without it is a poorer language.
Linus
Nathan Myers
>> ... jumping into the middle of a loop produces an
>>irreducible flow graph that needs to be removed before it can be
>>analyzed. This is what increases the code size and gives the compiler
>>trouble.
>
>see what happens. Here are two equivalent loops with an obvious strength
>reduction, but the second has a goto:
>
>nogoto() {
> do { z=bill(row++*80); if(z) tom();
> } while(z);
>}
>
>yesgoto() {
> int row=0;
> goto into;
> do {
> tom();
> into:;
> } while(bill(row++*80));
> }
>
>The results are very interesting.
I found this interesting too. After squinting for a moment,
it became clear that both functions above are equivalent to:
mugoto() {
int row=0;
while (bill(row++*80)) tom();
}
In fact, it appears that the Watcom compiler noticed this as well,
though only for the yesgoto case, because it produced almost the
same code for nogoto() as gcc did for mugoto(). (The difference
between watcom and gcc is just an effect of different calling
conventions.)
Even more interesting, gcc seems to have noticed the same thing
about nogoto(), and produced *exactly* the same code for nogoto()
and mugoto(). I count 8 instructions for each.
Most interesting, if I understand the code snippet presented, it
appears that VC++ actually produced bad code for the yesgoto() case.
>'goto' Watcom-C v11 32-bit:
>
>L$1:mov eax,edx
> call bill_
> add edx,0x00000050
> test eax,eax
> jne L$2
> ret
>L$2:call tom_
> jmp L$1
>'goto' VC++ v5.0:
>
>$into$83:call _tom <-- isn't this an error?
> mov eax, esi
> add esi, 80
> push eax
> call _bill
> add esp, 4
> test eax, eax
> jne SHORT $into$83
For the record, here's gcc-2.7.2 on mugoto():
(invoked as "gcc -O3 -fomit-frame-pointer -S goto.c")
L6: pushl %ebx
addl $80,%ebx
call _bill
addl $4,%esp
testl %eax,%eax
je L7
call _tom
jmp L6
What can we learn from this? Gcc doesn't try very hard
to fix up spaghetti code; but it's very good at cleaning
up loop control variables. If you're writing code to be
compiled with gcc, using "goto-tricks" to avoid loop control
variables doesn't help, and likely hurts. The other compilers
don't seem very good at teasing out loop control variables.
At least one seems to produce *bad code* when presented with gotos.
Coming back to the original topic... one shouldn't expect a
program written like `procmail' to be compiled optimally with
gcc -- or (it seems) even correctly when compiled with VC++
(although it is possible I have misunderstood the listing
presented.)
Fortunately (though I can't see it as accidental) code written
according to modern guidelines seems very compatible with gcc's
optimizer. I find it hard to get very upset that gcc does less
well on bad code,
Tony Cook
p...@foxharp.boston.ma.us wrote:
: (that being said, it has been pointed out to me that using this trick
: in C++ _can_ make sense, since leaving the block via break can cause
: desctructors to be invoked that would not be invoked via the goto.
: if used for that reason, i would advocate using macros to hide the
: do/while implementation details, since the expectation of do/while
: semantics is at odds with the author's intention.)
Wrong. If you leave a scope using goto any objects constructed in
that scope are destroyed (ie. their destructors are called).
--
Tony Cook - to...@online.tmx.com.au