> There are several things I'd like us to discuss before the next release. > > The first issue regards the use of __P() wrappers around arguments in function > declarations in our header files. In my opinion, it is pretty > useless now. First, anybody wishing to compile mailutils can get gcc (or > other ansi-compatible compiler). Secondly, no special effort was ever > made to make sure mailutils would compile with a pre-ansi > compiler. Moreover, such an effort would be polluting the code. So, I > propose to get rid of these wrappers. It will surely improve the > code readability and facilitate the maintenance.
Absolutely! It is time we move in the 20th century 8-). I think nowadays ANSI C should be the norm. In the worst case, folks can run the ansi2knr utility. > The second issue regards mailutils namespace. Our naming rules, or > better said, lack thereof, can create lots of problems when linking > mailutils with some other projects. For example, such name types > as list_t or record_t are pretty common. The same goes for function > names list_create() and many others. My proposition is to prefix each > external identifier with `mu_'. Yes, agreed. It was an oversight. Really all of our API should be prefix with "mu_". But we can do it by iterations. > Finally, our main library is called `libmailbox', although it has little > to do with mailboxes, being a collection of rather general-purpose > utilities. Wouldn't it be better if we call it `libmailutils' (which is > currently the name of our convenience library)? I understand that the name > is the reason of historic processes and that this is not so important, > and yet ... Another oversight 8-), mailbox was consider to be the sum of all. But I agree mailutils is a much better name for the sum of all. _______________________________________________ Bug-mailutils mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-mailutils
