[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Nmh-workers] New new/fn/fp/unseen program

From: Peter Maydell
Subject: Re: [Nmh-workers] New new/fn/fp/unseen program
Date: Wed, 23 Jul 2008 10:01:38 +0100

Eric Gillespie wrote:
>Peter Maydell <address@hidden> writes:
>> (4) you don't seem to handle the profile specifying multiple
>> unseen sequences
>I didn't know this was possible.  How does that work?

See mh-sequence(5) -- they're space-separated.

>Does context_find(usequence) return "unseen foo" or what?

Looks like it -- see the code in sbr/seq_setunseen.c to break
the results up.

>> Also, where does the '.folders' file come from? I seem to have one,
>> but it only has a few of my folders listed in it...
>  folders -fast -recur > .folders

If you're introducing a new standard config file then that definitely
needs to be documented, with its own manpage. It probably ought
to allow a custom name to be used (ie to have an entry in .mh_profile
giving the name). Anything that needs to create folders needs to be
configurable whether or not to update the file with the new folder
name, both on the command line and via .mh_profile.
The new 'unseen' etc need to behave sensibly in the absence of this
file (perhaps scanning all folders?).
Probably the command ought to let you specify a different file than
.folders on the command line too.

>> [Technically that call to concat() ought to end in "(char*)NULL"
>> or "(char*)0" but none of the rest of nmh seems to get that bit
>> of C trivia right either :-)]
>Are you sure?  All pointers are the same size, regardless of the
>size of the data they point to, and there is no type checking on
>a variadic function.  So, why the cast?

Because concat() is varargs, and the C standard doesn't guarantee
that NULL is a pointer (it might be of integer type). So in theory
if int is 32 bits and pointers are 64 then you might pass a 32 bit
value with the upper 64 bits garbage, and then the varargs function
interprets it as a 64 bit pointer. In practice so much code gets
this wrong that system implementors make it work anyway:

-- PMM

reply via email to

[Prev in Thread] Current Thread [Next in Thread]