On 03Mar2008 16:38, Thomas Roessler <[EMAIL PROTECTED]> wrote:
| On 2008-03-03 15:32:32 +, Paul Walker wrote:
| > At least for myself, I'd prefer a warning free build to warnings
| > which come out just because someone might potentially,
| > hypothetically change a piece of code at some random
On Tue, Mar 04, 2008 at 12:26:23AM +0100, Vincent Lefevre wrote:
> On 2008-03-03 17:42:01 +0100, Sébastien Hinderer wrote:
> > 2. It is true that testing pointers may avoid segfaults, but they don't
> > avoid problems.
That really depends on whether the code is written such that it knows
whether
On 2008-03-03 17:42:01 +0100, Sébastien Hinderer wrote:
> 1. I'm also _very_ interested in a warning-free compilation, because if
> the habit is to have no warnings at all, then each single warning which
> appears in the future is much more easy to notice. If it appears in a
> long list of warnings
On 2008-03-03, Aron Griffis <[EMAIL PROTECTED]> wrote:
> Rado S wrote: [Mon Mar 03 2008, 06:50:41AM EST]
> > Gary's solution is probably closer to what you expect(ed), but mine
> > has no magic with it: I simply define all my MLs as "ml-..." alias
> > and hit 'm' as usual to start a new msg.
>
>
On 2008-03-03, Thomas Roessler <[EMAIL PROTECTED]> wrote:
> On 2008-03-02 15:04:27 +, N.J. Mann wrote:
>
> >> I have created a patch that starts a new message to the sender
> >> of the currently selected message. In addition, I think I
> >> updated The Manual correctly.
>
> > Great idea.
>
Paul Walker (2008/03/03 15:32 +):
> But you can say that about any item of code. Any part of the tree might
> change at some point to render an assumption invalid. In the same function,
> there are strings helpstr and buf which are used without checking - by your
> logic, they should be checked
On Mon, Mar 03, 2008 at 04:38:00PM +0100, Thomas Roessler wrote:
> I don't think these particular cases are taken too far.
In which case we'll just have to disagree on that. ;-)
--
Paul
On 2008-03-03 12:37:06 +0100, Sébastien Hinderer wrote:
> Vincent Lefevre (2008/03/03 11:32 +0100):
> > And what if a part of the code changes? Such tests would allow
> > problem detection after such changes.
>
> Do you mean that every locally-allocated pointer should always be
> checked, because
On 2008-03-03 15:32:32 +, Paul Walker wrote:
> At least for myself, I'd prefer a warning free build to warnings
> which come out just because someone might potentially,
> hypothetically change a piece of code at some random time in the
> indefinite future. I think a warning-free build gives us
On Mon, Mar 03, 2008 at 02:48:35PM +0100, Thomas Roessler wrote:
> Indeed, it is -- in particular if (like in this case, I believe) the
> code which makes foo constant might change in the future in a way
> that would make foo non-constant.
But you can say that about any item of code. Any part of
Rado S wrote: [Mon Mar 03 2008, 06:50:41AM EST]
> Gary's solution is probably closer to what you expect(ed), but mine
> has no magic with it: I simply define all my MLs as "ml-..." alias
> and hit 'm' as usual to start a new msg.
How funny, I do exactly the same thing. I do it in m4 with:
c
On 2008-03-03 08:44:37 -0500, Thomas Dickey wrote:
> Not literally "if (1)".
Leaving out the good old
do {
...
break;
} while (0);
construct.
> But "if (foo)" where "foo" may be a constant expression is
> inarguably a valid way to construc
On Mon, 3 Mar 2008, Paul Walker wrote:
On Mon, Mar 03, 2008 at 12:20:02PM +0100, Vincent Lefevre wrote:
where the condition is always true, and which doesn't trigger any
warning.
Not really, because I'd argue that "if (1)" shouldn't exist in checked in
code. In that case, the variable will n
On Mon, Mar 03, 2008 at 12:20:02PM +0100, Vincent Lefevre wrote:
> where the condition is always true, and which doesn't trigger any
> warning.
Not really, because I'd argue that "if (1)" shouldn't exist in checked in
code. In that case, the variable will not be NULL, so why are we checking to
se
=- Patrick Shanahan wrote on Sun 2.Mar'08 at 15:52:13 -0500 -=
> > > > Would be great if there were also a 'compose to list'
> > > > option. Not sure if it would be better to have the function
> > > > compose to the list if the message is to a subscribed list,
> > > > or to have a different comma
Vincent Lefevre (2008/03/03 11:32 +0100):
> And what if a part of the code changes? Such tests would allow
> problem detection after such changes.
Do you mean that every locally-allocated pointer should always be
checked, because the code may change in such a way that the pointer
becomes non-local
On 2008-03-03 10:36:39 +, Paul Walker wrote:
> On Mon, Mar 03, 2008 at 10:45:39AM +0100, Thomas Roessler wrote:
> > From a quick look, the warnings are actually mistaken, and the patch
> > shouldn't be applied.
>
> I've checked, and I have to agree with gcc - the warnings are genuine.
> Both v
On Mon, Mar 03, 2008 at 10:45:39AM +0100, Thomas Roessler wrote:
> From a quick look, the warnings are actually mistaken, and the patch
> shouldn't be applied.
I've checked, and I have to agree with gcc - the warnings are genuine. Both
variables are allocated on the stack, and can't be NULL.
Not
On 2008-03-03 11:25:27 +0100, Sébastien Hinderer wrote:
> > From a quick look, the warnings are actually mistaken, and the patch
> > shouldn't be applied.
>
> Both variables are local, allocated on stack, so I thought they can't be
> NULL. But perhaps this understanding is wrong ?
And what if a p
On 2008-03-03 10:45:39 +0100, Thomas Roessler wrote:
> On 2008-03-03 08:40:36 +0100, Sébastien Hinderer wrote:
> > ../hg/compose.c: In function 'mutt_compose_menu':
> > ../hg/compose.c:1210: warning: the address of 'fname' will always evaluate
> > as 'true'
> > ../hg/mx.c: In function 'mx_close_ma
On 2008-03-03 10:38:09 +0100, Thomas Roessler wrote:
> On 2008-03-03 04:38:43 +0100, Vincent Lefevre wrote:
> > But is there a way to automatically remove some headers, such as
> > "Delivered-To:"?
>
> If I remember correctly, it does remove some headers. Might be that
> some more should be dropp
Hi,
> From a quick look, the warnings are actually mistaken, and the patch
> shouldn't be applied.
Both variables are local, allocated on stack, so I thought they can't be
NULL. But perhaps this understanding is wrong ?
Cheers,
Sébastien.
On 2008-03-03 08:40:36 +0100, Sébastien Hinderer wrote:
> ../hg/compose.c: In function 'mutt_compose_menu':
> ../hg/compose.c:1210: warning: the address of 'fname' will always evaluate as
> 'true'
> ../hg/mx.c: In function 'mx_close_mailbox':
> ../hg/mx.c:859: warning: the address of 'mbox' will
On 2008-03-03 04:38:43 +0100, Vincent Lefevre wrote:
> But is there a way to automatically remove some headers, such as
> "Delivered-To:"?
If I remember correctly, it does remove some headers. Might be that
some more should be dropped.
--
Thomas Roessler <[EMAIL PROTECTED]>
On 2008-03-02 15:04:27 +, N.J. Mann wrote:
>> I have created a patch that starts a new message to the sender
>> of the currently selected message. In addition, I think I
>> updated The Manual correctly.
> Great idea.
>> Suggestions/Thoughts/Criticism are welcome.
> I didn't compile without
New changeset in mutt:
http://dev.mutt.org/hg/mutt/rev/9a7d802004d3
changeset: 5356:9a7d802004d3
branch: HEAD
tag: tip
user:Vincent Lefevre <[EMAIL PROTECTED]>
date:Sun Mar 02 21:45:53 2008 -0800
summary: Updated French translation.
--
Repository URL: http://de
26 matches
Mail list logo
