mutt: new changeset

[Brendan Cully]

New changeset in mutt:

http://dev.mutt.org/hg/mutt/rev/55cd4cb611d9
changeset:   5178:55cd4cb611d9
branch:  HEAD
tag: tip
user:Serta? ?. Y?ld?z
date:Thu Jun 14 18:17:41 2007 -0700
summary: flowed: consider a single space as a hard line break. Closes #2906

-- 
Repository URL: http://dev.mutt.org/hg/mutt

[Mutt] #2912: decrypt gnupg message fails with "Could not copy message"

[Mutt]

#2912: decrypt gnupg message fails with "Could not copy message"

 This is what the .muttdebug0 looks like:
 {{{
 mutt_pgp_command: gpg --passphrase-fd 0 --no-verbose --batch --output -
 /tmp/mutt-valinor-1000-32324-5
 pgp_copy_checksig: "gpg: encrypted with 2048-bit ELG-E key, ID 8F9380D6,
 created 2007-04-23" doesn't match regexp.
 pgp_copy_checksig: "  "x"" doesn't match regexp.
 pgp_copy_checksig: "gpg: encrypted with 4096-bit ELG-E key, ID 376AE602,
 created 2006-09-29" doesn't match regexp.
 pgp_copy_checksig: "  "Kai Timmer <[EMAIL PROTECTED]>"" doesn't match
 regexp.
 parse_parameters: `micalg=pgp-sha1; protocol="application/pgp-signature";
 boundary="=-g/4hl8ulcKF1Ga3MI16U"'
 parse_parameter: `micalg' = `pgp-sha1'
 parse_parameter: `protocol' = `application/pgp-signature'
 parse_parameter: `boundary' = `=-g/4hl8ulcKF1Ga3MI16U'
 parse_parameters: `boundary="=-7n1Kb9Z71jvtel3HXM3B"'
 parse_parameter: `boundary' = `=-7n1Kb9Z71jvtel3HXM3B'
 parse_parameters: `name=signature.asc'
 parse_parameter: `name' = `signature.asc'
 parse_parameters: `filename=8295374E.asc'
 parse_parameter: `filename' = `8295374E.asc'
 parse_parameters: `name=8295374E.asc'
 parse_parameter: `name' = `8295374E.asc'
 ../crypt.c:836: mutt_mktemp returns "/tmp/mutt-valinor-1000-32324-6".
 ../pgp.c:604: mutt_mktemp returns "/tmp/mutt-valinor-1000-32324-7".
 mutt_pgp_command: gpg --no-verbose --batch --output - --verify /tmp/mutt-
 valinor-1000-32324-6.asc /tmp/mutt-valinor-1000-32324-6
 pgp_copy_checksig: "gpg: Signature made Do 14 Jun 2007 12:46:13 CEST using
 DSA key ID xxx doesn't match regexp.
 pgp_copy_checksig: "gpg: Good signature from "x"" matches regexp.
 pgp_copy_checksig: "gpg: aka "x" doesn't match regexp.
 pgp_copy_checksig: "gpg: aka "x"" doesn't match regexp.
 pgp_copy_checksig: "gpg: WARNING: This key is not certified with a trusted
 signature!" doesn't match regexp.
 pgp_copy_checksig: "gpg:  There is no indication that the
 signature belongs to the owner." doesn't match regexp.
 pgp_copy_checksig: "Primary key fingerprint:      
  " doesn't match regexp.
 pgp_verify_one: mutt_wait_filter returned 0.
 pgp_verify_one: returning 0.
 ../handler.c:1898: mutt_mktemp returns "/tmp/mutt-valinor-1000-32324-8".
 ../handler.c:302 [mutt_decode_base64()]: didn't get a multiple of 4 chars.
 mutt_free_body: Not unlinking 8295374E.asc.
 mutt_free_body: Not unlinking signature.asc.
 Konnte Nachricht nicht kopieren.
 }}}
 This happens only with a few PGP messages. Mostly i can check the
 signature and decrypt the messages without any problems.

-- 
Ticket URL: 

Re: [Mutt] #2912: decrypt gnupg message fails with "Could not copy

[Mutt]

#2912: decrypt gnupg message fails with "Could not copy message"

Comment (by kait):

 Maybe i should tell you that i am using version 1.5.13 with these compile
 options:

 {{{
 -DOMAIN
 +DEBUG
 -HOMESPOOL  +USE_SETGID  +USE_DOTLOCK  +DL_STANDALONE
 +USE_FCNTL  -USE_FLOCK   +USE_INODESORT
 +USE_POP  +USE_IMAP  -USE_GSS  -USE_SSL_OPENSSL  +USE_SSL_GNUTLS
 +USE_SASL  +HAVE_GETADDRINFO
 +HAVE_REGCOMP  -USE_GNU_REGEX
 +HAVE_COLOR  +HAVE_START_COLOR  +HAVE_TYPEAHEAD  +HAVE_BKGDSET
 +HAVE_CURS_SET  +HAVE_META  +HAVE_RESIZETERM
 +CRYPT_BACKEND_CLASSIC_PGP  +CRYPT_BACKEND_CLASSIC_SMIME
 -CRYPT_BACKEND_GPGME
 -BUFFY_SIZE -EXACT_ADDRESS  -SUN_ATTACHMENT
 +ENABLE_NLS  -LOCALES_HACK  +COMPRESSED  +HAVE_WC_FUNCS
 +HAVE_LANGINFO_CODESET  +HAVE_LANGINFO_YESEXPR
 +HAVE_ICONV  -ICONV_NONTRANS  +HAVE_LIBIDN  +HAVE_GETSID  +USE_HCACHE
 -ISPELL
 SENDMAIL="/usr/sbin/sendmail"
 MAILPATH="/var/mail"
 PKGDATADIR="/usr/share/mutt"
 SYSCONFDIR="/etc"
 EXECSHELL="/bin/sh"
 MIXMASTER="mixmaster"
 To contact the developers, please mail to .
 To report a bug, please visit http://bugs.mutt.org/.

 patch-1.5.11.rr.compressed.1
 patch-1.5.4.vk.pgp_verbose_mime
 patch-1.5.5.1.nt.xtitles.3.ab.1
 patch-1.5.6.dw.maildir-mtime.1
 patch-1.5.6.tt.assumed_charset.1
 }}}

-- 
Ticket URL: 

Re: [ANNOUNCE] mutt 1.5.16 released

[Derek Martin]

On Thu, Jun 14, 2007 at 02:01:21AM +0200, Vincent Lefevre wrote:
> If your vi regards something like a failed pattern search as an error,
> you have to accept that. 

Nonsense.  If Mutt behaves badly dealing with a common application
that people use in conjunction with Mutt, especially one Mutt
specifically intends to be compatible with (like vi), then Mutt is
broken.

> Note that vi doesn't have this problem under Linux.

Linux is not the only OS in the universe, and this does not make the
current behavior correct.

-- 
Derek D. Martinhttp://www.pizzashack.org/   GPG Key ID: 0xDFBEAD02
-=-=-=-=-
This message is posted from an invalid address.  Replying to it will result in
undeliverable mail due to spam prevention.  Sorry for the inconvenience.



pgpmOHDd1eKM1.pgp
Description: PGP signature

Re: [ANNOUNCE] mutt 1.5.16 released

[Derek Martin]

On Wed, Jun 13, 2007 at 04:31:22PM -0600, Kyle Wheeler wrote:
> On Wednesday, June 13 at 06:03 PM, quoth Jean-Pierre Radley:
> >Under Posix 2004 rules, I'm not sure what exit status vi will 
> >present, but the vi on all variants of Unix from SCO, as well as the 
> >vi on Solaris 10, adhere to the Posix 2001 standard, which includes 
> >in the clause 'consequences of errors' "... or when an error is 
> >detected that is a consequence of data (not) present in the file, 
> >..." and "ex/vi shall terminate with a nonzero exit status."

The fact is, exit status is application-dependent on Unix systems,
POSIX or not.  Even if POSIX defines how vi should behave on exit,
the operating system has no means to enforce this behavior, and
authors of vi clones need not adhere to it if they so choose.  For
that matter, there is no reason the user is required to run vi or any
POSIX-compliant program as Mutt's editor.  A user could choose to use
a script which modifies a template as his editor, and that script
might return the number of changes it made, the day of the week, or
whatever other value the author decided to pass back to the OS.

Mutt can not know what the exit status of $EDITOR will indicate, and
as such Mutt MUST ignore it.

> Then again, what is an error in an interactive program?

Exactly.  Presumably, the user will be able to identify a failure of
the editor, and take actions to correct before the editor finishes.
 
> Do you have any suggested alternative solution for the problem 
> reported in that bugreport? http://dev.mutt.org/trac/ticket/1638

Yes: do nothing.  The only thing Mutt should care about is whether the
temp file changed since Mutt created it.

Not detecting a failure in the editor is NOT a bug.  It's the only
sensible behavior.  The OP's problem proves this.

-- 
Derek D. Martinhttp://www.pizzashack.org/   GPG Key ID: 0xDFBEAD02
-=-=-=-=-
This message is posted from an invalid address.  Replying to it will result in
undeliverable mail due to spam prevention.  Sorry for the inconvenience.



pgpkq97XrQv6a.pgp
Description: PGP signature

Re: [Mutt] #2909: Display problems for spams with strange chars

[Mutt]

#2909: Display problems for spams with strange chars

Comment (by Alain Bench):

 {{{
 Bonjour, et merci pour ce rapport de problème.

  On Wednesday, June 13, 2007 at 10:43:36 -, Mutt wrote:

 > For many spams, I have display problems for summary line (in index
 > window). Columns after subject are shifted and unreadable.

 That garbage subject may look like an unannounced raw BIG-5 Chinese
 one. Is it displayed correctly with $assumed_charset=big-5?

 Otherwise please send us the header of this spam, and please
 describe us your locale, iconv, and charset setup.


 Bye!Alain.
 }}}

-- 
Ticket URL: 

Re: [ANNOUNCE] mutt 1.5.16 released

[Vincent Lefevre]

On 2007-06-15 08:19:15 -0400, Derek Martin wrote:
> On Thu, Jun 14, 2007 at 02:01:21AM +0200, Vincent Lefevre wrote:
> > If your vi regards something like a failed pattern search as an error,
> > you have to accept that. 
> 
> Nonsense.  If Mutt behaves badly dealing with a common application
> that people use in conjunction with Mutt, especially one Mutt
> specifically intends to be compatible with (like vi), then Mutt is
> broken.

Then Mutt should check if the editor command is named vi.

-- 
Vincent Lefèvre <[EMAIL PROTECTED]> - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)

Bug in Sun studio 11

[Vladimír Marek]

Hi, I found bug in SS11 which is triggered by mutt source. It makes
function crc_matches return false even if the crc is correct. This
virtually disables header cache.

Workaround I found is to change the definition

unsigned int mycrc = 0;

to

static unsigned int mycrc = 0;

I don't want to file a bug against mutt straight away,but you might
consider this change.

I filed the bug against the compiler, but it might take a while until
patch is ready.

Thanks

-- 
Vlad

Re: [ANNOUNCE] mutt 1.5.16 released

[Oswald Buddenhagen]

On Fri, Jun 15, 2007 at 08:19:15AM -0400, Derek Martin wrote:
> On Thu, Jun 14, 2007 at 02:01:21AM +0200, Vincent Lefevre wrote:
> > If your vi regards something like a failed pattern search as an error,
> > you have to accept that. 
> 
> Nonsense.  If Mutt behaves badly dealing with a common application
> that people use in conjunction with Mutt, especially one Mutt
> specifically intends to be compatible with (like vi), then Mutt is
> broken.
> 
that's absurd. if you have such an utterly broken program and still want
to use it, wrap it in a script. if you lose data then, it's you own
fault.

-- 
Hi! I'm a .signature virus! Copy me into your ~/.signature, please!
--
Chaos, panic, and disorder - my work here is done.

Re: Bug in Sun studio 11

[Dan Nelson]

In the last episode (Jun 15), Vladimr Marek said: Hi, I found bug in
> SS11 which is triggered by mutt source. It makes function crc_matches
> return false even if the crc is correct. This virtually disables
> header cache.
> 
> Workaround I found is to change the definition
> 
> unsigned int mycrc = 0;
> 
> to
> 
> static unsigned int mycrc = 0;
> 
> I don't want to file a bug against mutt straight away, but you might
> consider this change.
> 
> I filed the bug against the compiler, but it might take a while until
> patch is ready.

Does it happen with Sun Studio 12, too?

-- 
Dan Nelson
[EMAIL PROTECTED]

Re: Bug in Sun studio 11

[Vladimír Marek]

> > SS11 which is triggered by mutt source. It makes function crc_matches
> > return false even if the crc is correct. This virtually disables
> > header cache.
> > 
> > Workaround I found is to change the definition
> > 
> > unsigned int mycrc = 0;
> > 
> > to
> > 
> > static unsigned int mycrc = 0;
> > 
> > I don't want to file a bug against mutt straight away, but you might
> > consider this change.
> > 
> > I filed the bug against the compiler, but it might take a while until
> > patch is ready.
> 
> Does it happen with Sun Studio 12, too?

I currently don't have SS12 available, but I was told that it should be
fixed there.

-- 
Vlad

Re: Mutt 1.5.16 editor exit status brain damage

[Derek Martin]

On Fri, Jun 15, 2007 at 06:17:53PM +0200, Oswald Buddenhagen wrote:
> > Nonsense.  If Mutt behaves badly dealing with a common application
> > that people use in conjunction with Mutt, especially one Mutt
> > specifically intends to be compatible with (like vi), then Mutt is
> > broken.
> > 
> that's absurd. if you have such an utterly broken program and still want
> to use it, wrap it in a script. if you lose data then, it's you own
> fault.

It's not broken.  The application developer has the right to use any
exit status he wants.  Mutt CAN NOT make assumptions about what the
exit status means.  The user is a USER.  They should not have to
write code to make Mutt behave sanely.

It's far from absurd, it is in fact the only reasonable option, and I
have no doubt that is why it was designed that way from the start, and
persisted that way for 9 years.


-- 
Derek D. Martinhttp://www.pizzashack.org/   GPG Key ID: 0xDFBEAD02
-=-=-=-=-
This message is posted from an invalid address.  Replying to it will result in
undeliverable mail due to spam prevention.  Sorry for the inconvenience.



pgpzt1iypejG2.pgp
Description: PGP signature

Re: Bug in Sun studio 11

[Brendan Cully]

On Friday, 15 June 2007 at 18:06, Vladimír Marek wrote:
> Hi, I found bug in SS11 which is triggered by mutt source. It makes
> function crc_matches return false even if the crc is correct. This
> virtually disables header cache.
> 
> Workaround I found is to change the definition
> 
> unsigned int mycrc = 0;
> 
> to
> 
> static unsigned int mycrc = 0;
> 
> I don't want to file a bug against mutt straight away,but you might
> consider this change.
> 
> I filed the bug against the compiler, but it might take a while until
> patch is ready.

Wow, that's voodoo. I don't see any harm in making the change though.


pgp9mE5nRY1ut.pgp
Description: PGP signature

Re: Mutt 1.5.16 editor exit status brain damage

[Kyle Wheeler]

On Friday, June 15 at 02:25 PM, quoth Derek Martin:
It's not broken.  The application developer has the right to use any 
exit status he wants.  Mutt CAN NOT make assumptions about what the 
exit status means.


Now wait a minute, you're mixing standards here. Just as the 
application developer has the *right* to use any exit status he wants, 
mutt has the *right* to make whatever assumptions it feels like about 
what the exit status means. But whether you have the *right* to do 
something does not mean that you have an obligation to do it, and 
doesn't mean that it's even a good idea. You have the *right* to jab 
yourself in the eye with a fork, but it's probably unwise. In fact, 
mutt has the *right* to delete every file on your computer, but that's 
also unwise. If a program does things (that it has  every *right* to 
do) that are irritating, useless, dangerous, or whatever, you as the 
user have the right to refuse to use them (or, in the OSS case, change 
that behavior).


For example, most shells (including /bin/sh, even when it's not an 
alias for bash) make the *assumption* that an exit status of 0 means 
success and that anything else means an error of some sort. Thus, when 
doing `command1 && command2`, the shell *assumes* that if command1 
does not exit with a status of 0 then something (who knows what) has 
gone wrong and command2 will not be executed. I don't know if that's 
in the POSIX standard or where it might be defined, but its reasonable 
enough to have been consistent for at least the last decade. And 
aren't you glad that it is pretty consistent? I mean, imagine doing 
shell-scripting if the result ALWAYS depended on the program, the 
version, and the OS. Instructions like './configure && make && make 
install' suddenly become incredibly ugly:


./configure; ret=$?
if [ "$OS" = "Linux" ] ; then
if [ $ret -eq 0 ] ; then
make
if [ $? -eq 0 ] ; then
make install
fi
fi
elif [ "$OS" = "Solaris" ] ; then
if [ $ret -ne 100 ] ; then
make
if [ $? -eq 43 ] ; then
make install
fi
fi
fi
# When we support more OS's, add them here.

It seems to me that making the same assumption that every single major 
shell makes (i.e. that a non-zero status code means that an error 
occurred) is perfectly reasonable (and mutt of course has every 
*right* to make that assumption). The question then becomes: what 
should mutt DO with that assumption? The options are: something or 
nothing. "Something" could be informing the user of the (assumed) 
error, for example. And "nothing" would of course be similar to the 
result of assuming that the exit code contains no useful information.


So which route should mutt take once it has made the assumption (that 
it has every right to make) about what the exit code of the editor 
means? Doing nothing is undesirable for some, and doing something is 
undesirable for others. It may be worthwhile to add a configure option 
to mutt that allows the user to specify whether their editor's exit 
status matches the de-facto standard shell semantics (and thus 
non-zero codes should be considered actionable errors) or whether 
their editor's exit status should be ignored.


The user is a USER.  They should not have to write code to make Mutt 
behave sanely.


HEH. Depends on your definition of sanity, I guess. There's a wishlist 
as long as your arm for new features in mutt, and most of them 
approach things from the "email reading would be much more sane if 
mutt did X" perspective. You could say, for example, that using 
anything other than DR-DOS is "insane", but you'll have to write code 
to make mutt work there. Is making the same assumption about exit 
codes that bash, csh, tcsh, ksh, ash, dash, and others make to be 
considered "insane"? I guess it depends on who you ask---you would 
(apparently) say yes and I would say no.


~Kyle
--
Three things in human life are important.  The first is to be kind. 
The second is to be kind.  And the third is to be kind.

-- Henry James


pgpg1kPI8HbBH.pgp
Description: PGP signature

Re: Bug in Sun studio 11

[Vladimír Marek]

> > Hi, I found bug in SS11 which is triggered by mutt source. It makes
> > function crc_matches return false even if the crc is correct. This
> > virtually disables header cache.

> > unsigned int mycrc = 0;
> > to
> > static unsigned int mycrc = 0;

[...]

> Wow, that's voodoo. I don't see any harm in making the change though.

Making the variable static makes compiler to store the value to physical
memory and not just to register. I can confirm that on SS12 the problem
no longer exists. But at the same time, SS11 may not be fixed, since it
is not priority anymore ...

-- 
Vlad

Attaching a file in trac doesn't notify the list?

[Daniel Jacobowitz]

As per Subject.  I attached a hacky patch to 2910, and expected trac
to mail that fact to the list - nothing.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [ANNOUNCE] mutt 1.5.16 released

[Jean-Pierre Radley]

Vincent Lefevre typed (on Fri, Jun 15, 2007 at 04:42:18PM +0200):
| On 2007-06-15 08:19:15 -0400, Derek Martin wrote:
| > On Thu, Jun 14, 2007 at 02:01:21AM +0200, Vincent Lefevre wrote:
| > > If your vi regards something like a failed pattern search as an error,
| > > you have to accept that. 
| > 
| > Nonsense.  If Mutt behaves badly dealing with a common application
| > that people use in conjunction with Mutt, especially one Mutt
| > specifically intends to be compatible with (like vi), then Mutt is
| > broken.
| 
| Then Mutt should check if the editor command is named vi.

Too simplistic, since vi in Linux is (always? usually?) vim.

-- 
JP
==> http://www.frappr.com/cusm <==

Re: Mutt 1.5.16 editor exit status brain damage

[Derek Martin]

On Fri, Jun 15, 2007 at 02:06:10PM -0600, Kyle Wheeler wrote:
> Now wait a minute, you're mixing standards here. 

No I'm not.  The OP's version is technically compliant to the
standard.  It is exiting with a non-zero status when an error has
occured.  I should be able to stop here, as that is proof that the
current behavior is wrong.  But I'll continue.

IIRC, the POSIX standard mandates the exit status of "standard
utilities" -- an author of a program which is not a "standard utility"
can use the exit status in whatever way is convenient.  It could
be used to pass interesting numerical information back to the OS
(calling process).  There's no reason an author should avoid this
behavior if it makes sense for his application.

> You have the *right* to jab yourself in the eye with a fork, but
> it's probably unwise. 

Aren't you one of the people that argues that Mutt should not prevent
people from doing things that are unwise?

> For example, most shells (including /bin/sh, even when it's not an 
> alias for bash) make the *assumption* that an exit status of 0 means 
> success and that anything else means an error of some sort. 

No, that's not correct.  Strictly speaking, the shell assumes an exit
status of 0 evaluates to TRUE, and any non-zero exit status evaluates
to FALSE.  Any interpretation about whether that means success or
failure is open to interpretation by the author.  Over time, shell
programmers, and in some cases shell man page writers have assumed
what you are assuming: that the meaning is success or failure.  But
that is false.

> It seems to me that making the same assumption that every single major 
> shell makes (i.e. that a non-zero status code means that an error 
> occurred) is perfectly reasonable (and mutt of course has every 
> *right* to make that assumption). 

Your statement is not correct, and Mutt does not have the right to
make such an assumption.  Such an assumption is false, even if it is
true *BY CONVENTION* in the majority of cases, and by standard in some
cases.  Rules of logic dictate that if a premise is not always true,
then it is false.

Case in point: fsck returns an exit status of 1 when it repaired
filesystem errors.  This is not an error condition of the program, it
is actually a success.  There are errors on the filesystem, sure; but
that is not a failure case for fsck.  Rather, fsck has succeeded
fantastically at doing what it is supposed to do.  But it still
returns a "failure" exit code.  But this is for very good reason, and
consumers of fsck's exit status need to be aware of this.

> So which route should mutt take once it has made the assumption (that 
> it has every right to make) about what the exit code of the editor 
> means? Doing nothing is undesirable for some, and doing something is 
> undesirable for others. 

It has been doing nothing (based on the exit code) for 9 years, and
AFAIK only 1 person has complained.  By contrast, the current behavior
is broken for users of vi on 2 major operating systems (at least,
possibly more).  Which behavior is correct?  The answer is obvious:
the old behavior is correct.

> It may be worthwhile to add a configure option to mutt that allows
> the user to specify whether their editor's exit status matches the
> de-facto standard shell semantics (and thus non-zero codes should be
> considered actionable errors) or whether their editor's exit status
> should be ignored.

That doesn't seem worthwhile to me.  Mutt can detect if the user was
able to edit the file by seeing if it changed after the editor ran on
it.  If it didn't change, mutt should (at least provide an option to)
prompt the user about what to do.  It can not and should not make
assumptions about the meaning of the exit status of the editor.

-- 
Derek D. Martinhttp://www.pizzashack.org/   GPG Key ID: 0xDFBEAD02
-=-=-=-=-
This message is posted from an invalid address.  Replying to it will result in
undeliverable mail due to spam prevention.  Sorry for the inconvenience.



pgp10jJoMXJfv.pgp
Description: PGP signature

Re: Bug in Sun studio 11

[Brendan Cully]

On Friday, 15 June 2007 at 22:08, Vladimír Marek wrote:
> > > Hi, I found bug in SS11 which is triggered by mutt source. It makes
> > > function crc_matches return false even if the crc is correct. This
> > > virtually disables header cache.
> 
> > > unsigned int mycrc = 0;
> > > to
> > > static unsigned int mycrc = 0;
> 
> [...]
> 
> > Wow, that's voodoo. I don't see any harm in making the change though.
> 
> Making the variable static makes compiler to store the value to physical
> memory and not just to register. I can confirm that on SS12 the problem

you'd think &mycrc would have the same effect :)

> no longer exists. But at the same time, SS11 may not be fixed, since it
> is not priority anymore ...

I'll probably apply it. I'm just giving it time to see if any other C
gurus comment.


pgpa8mYNqd3Va.pgp
Description: PGP signature

Re: Mutt 1.5.16 editor exit status brain damage

[Kyle Wheeler]

On Friday, June 15 at 05:51 PM, quoth Derek Martin:

On Fri, Jun 15, 2007 at 02:06:10PM -0600, Kyle Wheeler wrote:
Now wait a minute, you're mixing standards here. 


No I'm not.  The OP's version is technically compliant to the 
standard.


I didn't mean "standards" as in "you're mixing the X standard with the 
Y standard", I meant it in terms of "you're holding general 
applications to one standard (i.e. they can do whatever they like) and 
mutt to a different standard (i.e. it is forbidden from doing whatever 
it likes)."


IIRC, the POSIX standard mandates the exit status of "standard 
utilities" -- an author of a program which is not a "standard 
utility" can use the exit status in whatever way is convenient.  It 
could be used to pass interesting numerical information back to the 
OS (calling process).  There's no reason an author should avoid this 
behavior if it makes sense for his application.


Of course, and I would agree, however, the definition of what is a 
"standard utility" is a bit vague, wouldn't you say? I mean, what 
makes something a standard utility? The fact that 'vi' and 'fsck' are 
distributed with virtually every version of UNIX certainly makes them 
a de-facto standard. They are also useful programs, which makes them 
"utilities" as well. Aren't they both therefore "standard utilities"? 
Or maybe "standard" in POSIX means something else?


You have the *right* to jab yourself in the eye with a fork, but 
it's probably unwise. 


Aren't you one of the people that argues that Mutt should not prevent 
people from doing things that are unwise?


 Why on earth would other arguments I may have made about 
unrelated (unnamed) details have any bearing on this discussion?


Not that it matters, but I agree that mutt shouldn't prevent people 
from doing unwise things. I suggested mutt be made more flexible 
rather than that mutt be made to prevent anyone from doing anything 
unwise, thus being consistent with my (apparent) reputation. But 
again, why should my reputation matter?


For example, most shells (including /bin/sh, even when it's not an 
alias for bash) make the *assumption* that an exit status of 0 means 
success and that anything else means an error of some sort. 


No, that's not correct.  Strictly speaking, the shell assumes an exit 
status of 0 evaluates to TRUE, and any non-zero exit status evaluates 
to FALSE.  Any interpretation about whether that means success or 
failure is open to interpretation by the author.  Over time, shell 
programmers, and in some cases shell man page writers have assumed 
what you are assuming: that the meaning is success or failure.  But 
that is false.


I like how you conveniently positioned yourself such that, should 
anyone choose to find shell documentation contradicting you, you'd 
simply claim that the documentation is wrong (no matter whether every 
man page of every shell said it or not). But fair enough, you're 
right. "True" can, strictly speaking, mean anything.


Your statement is not correct, and Mutt does not have the right to 
make such an assumption.


Of course it does. Is making this assumption illegal in any country on 
earth? Will anyone be jailed, fined, or killed if mutt makes this 
assumption? No, of course not. Even if the assumption is *WRONG*, mutt 
has the *right* to make any assumption it likes. In fact, mutt has the 
*right* to have bugs in it too, which may have the effect of (or have 
as their cause) making all sorts of assumptions.


If you wish to argue that mutt does not have the right to assume 
whatever it likes, then I would ask: by what authority?


Of course, that then gets into a more philosophical argument about 
where "rights" come from, but the same logic can then be applied to 
the so-called "right" of programmers to use whatever return value they 
wish. From whence does this "right" come?


Rules of logic dictate that if a premise is not always true, then it 
is false.


You wanna get nitpicky, lets get nitpicky. Otherwise, let's stop 
treating me like an idiot and attempting to explain "rules of logic" 
to me.


Since turnabout is fair play... Premises may have truth that is 
dependent upon context. For example, every day around noon I go in 
search of sustenance. My actions are based upon the premise that I am 
hungry. Once I have eaten, I am no longer hungry. This does not mean 
that I was never hungry and never will be hungry, despite the fact 
that the premise "I am hungry" is not always true. A premise is, after 
all, only a claim (either true or false). Only universal claims, such 
as "I am always hungry", are false if they are not always true.


It has been doing nothing (based on the exit code) for 9 years, and 
AFAIK only 1 person has complained.  By contrast, the current 
behavior is broken for users of vi on 2 major operating systems (at 
least, possibly more).  Which behavior is correct?  The answer is 
obvious:

the old behavior is correct.


Not necessarily. It really means one of tw

Re: Bug in Sun studio 11

[Kyle Wheeler]

On Friday, June 15 at 02:59 PM, quoth Brendan Cully:

On Friday, 15 June 2007 at 22:08, Vladim'ir Marek wrote:
Hi, I found bug in SS11 which is triggered by mutt source. It makes 
function crc_matches return false even if the crc is correct. This 
virtually disables header cache.


unsigned int mycrc = 0; 
to 
static unsigned int mycrc = 0;


[...]


Wow, that's voodoo. I don't see any harm in making the change though.


Making the variable static makes compiler to store the value to physical 
memory and not just to register. I can confirm that on SS12 the problem


you'd think &mycrc would have the same effect :)


It *should*, but I guess that's the very definition of a bug, eh? :)

no longer exists. But at the same time, SS11 may not be fixed, 
since it is not priority anymore ...


I'll probably apply it. I'm just giving it time to see if any other C 
gurus comment.


Well... there's the obvious comment, which is that if you're relying 
on mycrc being initialized to zero in the function, making it static 
will break that, so you'd need to add a separate mycrc=0; line in 
after it is declared, because the existing initialization won't take 
care of that.


The other problem with making it static is that it prevents the 
compiler from doing certain kinds of optimization. That's not a 
performance-critical function, but... I'd be somewhat uncomfortable 
with adding goofy-looking code to work around compiler 
bugs---especially when the bug has been fixed in the current version 
of the compiler. I mean, we aren't still working around gcc 1.0 bugs, 
why work around SS11 bugs? If anything, put it in an #ifdef, such as:


#ifdef __SUN11__ /* or whatever signifies that compiler */
static int mycrc;
mycrc = 0;
#else
int mycrc = 0;
#endif

~Kyle
--
America will never be destroyed from the outside. If we falter and 
lose our freedoms, it will be because we destroyed ourselves.

-- Abraham Lincoln


pgpwD4y3rJMM4.pgp
Description: PGP signature

Feature request for somewhen

[David Woodfall]

When entering an mbox from a folder, and then exiting back to the folder,
presently the cursor returns to the top of the folder. It would be nice if
the cursor remained opposite the mbox exited from, in the same way that
when browsing an mbox and exiting an email/thread does.

It would save an awful lot of scrolling down when, say, checking new posts
in mailing lists.

Just a thought anyway.

Cheers

-- 
Boling's postulate:
If you're feeling good, don't worry.  You'll get over it.

Re: [Mutt] #2910: Number of new mails in change-folder view

[Mutt]

#2910: Number of new mails in change-folder view

Comment (by brendan):

 This patch appears to remove the ability to distinguish between "new" and
 "old" unread messages over IMAP (which was finally fixed in 1.5.14 IIRC).
 You're not supposed to be prompted to open mailboxes that only have old
 messages.

 I think the actual problem is that the mailbox display uses the buffy new
 count (only new messages), when what it should probably be doing is
 fetching the unseen count from the IMAP mailbox status cache.

-- 
Ticket URL: 

Re: Bug in Sun studio 11

[Brendan Cully]

On Friday, 15 June 2007 at 17:02, Kyle Wheeler wrote:
> On Friday, June 15 at 02:59 PM, quoth Brendan Cully:
>> On Friday, 15 June 2007 at 22:08, Vladim'ir Marek wrote:
> Hi, I found bug in SS11 which is triggered by mutt source. It makes 
> function crc_matches return false even if the crc is correct. This 
> virtually disables header cache.
> unsigned int mycrc = 0; to static unsigned int mycrc = 0;
>>> [...]
 Wow, that's voodoo. I don't see any harm in making the change though.
>>> Making the variable static makes compiler to store the value to physical 
>>> memory and not just to register. I can confirm that on SS12 the problem
>>
>> you'd think &mycrc would have the same effect :)
>
> It *should*, but I guess that's the very definition of a bug, eh? :)
>
>>> no longer exists. But at the same time, SS11 may not be fixed, since it is 
>>> not priority anymore ...
>>
>> I'll probably apply it. I'm just giving it time to see if any other C gurus 
>> comment.
>
> Well... there's the obvious comment, which is that if you're relying on 
> mycrc being initialized to zero in the function, making it static will break 
> that, so you'd need to add a separate mycrc=0; line in after it is declared, 
> because the existing initialization won't take care of that.

No, restore_int always clobbers the variable. The zeroing just looks
like paranoia.

> The other problem with making it static is that it prevents the compiler 
> from doing certain kinds of optimization. That's not a performance-critical 
> function, but... I'd be somewhat uncomfortable with adding goofy-looking 
> code to work around compiler bugs---especially when the bug has been fixed 
> in the current version of the compiler. I mean, we aren't still working 
> around gcc 1.0 bugs, why work around SS11 bugs? If anything, put it in an 
> #ifdef, such as:

Yeah, fair enough. I'll put it in if someone can tell me the right
guard macro.


pgpWVYRNK3FHP.pgp
Description: PGP signature

Re: Bug in Sun studio 11

[Vladimír Marek]

> >>>Wow, that's voodoo. I don't see any harm in making the change though.
> >>
> >>Making the variable static makes compiler to store the value to physical 
> >>memory and not just to register. I can confirm that on SS12 the problem
> >
> >you'd think &mycrc would have the same effect :)
> 
> It *should*, but I guess that's the very definition of a bug, eh? :)

:)


> >>no longer exists. But at the same time, SS11 may not be fixed, 
> >>since it is not priority anymore ...
> >
> >I'll probably apply it. I'm just giving it time to see if any other C 
> >gurus comment.
> 
> Well... there's the obvious comment, which is that if you're relying 
> on mycrc being initialized to zero in the function, making it static 
> will break that, so you'd need to add a separate mycrc=0; line in 
> after it is declared, because the existing initialization won't take 
> care of that.

Correct, although it does not matter in this case, as mycrc is filled by
restore_int.


> The other problem with making it static is that it prevents the 
> compiler from doing certain kinds of optimization. That's not a 
> performance-critical function, but...

Unmeasurable.


> I'd be somewhat uncomfortable with adding goofy-looking code to work
> around compiler bugs---especially when the bug has been fixed in the
> current version of the compiler. I mean, we aren't still working
> around gcc 1.0 bugs, why work around SS11 bugs?

Agreed. SS12 is out one month, thought ...



> If anything, put it in
> an #ifdef, such as:
> 
> #ifdef __SUN11__ /* or whatever signifies that compiler */
> static int mycrc;
> mycrc = 0;
> #else
> int mycrc = 0;
> #endif

Why not, if you believe that it's worth of six lines instead of one.
Anything which will potentially stop others seeing the issue. I can't
force the C team so I'm trying my luck here :) I'll forge the correct
version and post it here.

Thanks for the comments
-- 
Vlad