Subject: Nits and issues

From: [email-masked] (Paul D. Smith)
Date: 08 Nov 1998 01:34:48 -0500

A few random things:

  * I know there is a _potential_ bug in the new packet sending code for
    any non-32-bit system (any system where sizeof(int) !=
    sizeof(long)).  Because these functions are variadic, you don't get
    automatic integer promotion as you would if they were full
    prototypes.  Thus, all the integer values should be cast to
    (unsigned long) to be safe.

    I thought of doing this, but that just seemed too much to type.  And
    I think trying to rely on something like u_long or ulong and working
    around systems that may define that themselves, etc. would be a
    pain.  I wonder if we shouldn't make a typedef like UL, or ful or
    f_ul, or something.

  * I saw Dan made a pass at supporting systems that use varargs.h, then
    Steve tried to fix it up more.  A commit I made Friday undoes this.

    Note that it's not feasible to use varargs.h with ANSI C prototypes.
    Varargs.h requires you to define the last option as a "va_dcl", and
    not in a prototype.  You must define variadic functions like:

      foo(bar, va_alist)
        int bar;
        va_dcl
      {
        ...
      }

    This can get gross; to fully support both old and new styles
    requires a lot of work and, as I said, can't be used with
    prototypes.  Since we already require an ANSI C compiler, at least
    one that handles prototypes, I think we should just ignore the
    varargs.h case.  If we don't, we definitely need to do a lot more
    work to get it right.  Thoughts/concerns?

  * There's something odd going on in someone's distribution
    (Dominik's?)  Whenever I update I seem to get all those
    Makefile.in's changed.  They _shouldn't_ be changed every time like
    that.  One thing I noticed is that the ones I get from CVS use the
    --gnu option to automake instead of the --foreign, while mine, when
    rebuilt, always use --foreign.  The problem is --gnu doesn't work,
    because until there's a copy of the COPYING file in the fvwm root
    directory it doesn't comply with the GNU standards (btw, why isn't
    the COPYING file in the root directory?)  Anyway, for me it fails
    and I have to rebuild the makefile.in's.

    I'm not quite sure how that's happening, but I wish it weren't :)

  * Can we decide to remove the things we were talking about previously
    from the dist?  In particular:

      textures/*
      sample.fvwmrc/BradyMontz

    Are there some modules we think are too old and don't need to be
    supported anymore we could get rid of?

    Maybe these could be separated into a different package, rather than
    being under source control.  Seems like it'd be a lot faster to
    update and build fvwm if we could get rid of unnecessary stuff.

  * If it were up to me I'd forget the fancy backgrounds, etc. on the
    web pages and stick with basic black on (off?) white.  Just one
    opinion :)

-- 
-------------------------------------------------------------------------------
 Paul D. Smith <[email-masked]>         Network Management Development
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist
-------------------------------------------------------------------------------
   These are my opinions---Nortel Networks takes no responsibility for them.
--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked].

---

From: Dan Espen <[email-masked]>
Date: Sun, 08 Nov 1998 10:42:58 -0500

>     from the dist?  In particular:

Still OK with me.

>     supported anymore we could get rid of?

I don't  see any.  The  only module that has  significant distribution
size is extras/FvwmScript.

>     web pages and stick with basic black on (off?) white.  Just one

Hopefully just one.

I really like them, or I wouldn't have bothered.  I do understand tastes
vary.  Score so far, one for, one against.

> -- 
>  Paul D. Smith <[email-masked]>         Network Management Developmen

--
Dan Espen                                Phone: (732) 699-5570
444 Hoes Lane  Room RRC 1C-214           E-mail: [email-masked]
Piscataway, NJ 08854
--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked].

---

From: Steve Robbins <[email-masked]>
Date: Sun, 8 Nov 1998 13:29:07 -0500 (EST)

On 8 Nov 1998, Paul D. Smith wrote:

>     sizeof(long)).

Uh, well I have one of those systems, so I'm a little concerned!  

[Actually, I'm a bit confused, too.  The alpha reports that an int is only
32 bits, where longs and pointers are 64!  I wonder if they did this so as
to not break code that assumes 32 bit integers?]

I didn't really catch all the rest of what you said, but we'll have to
figure out some portable way to handle this.  And soon.

>     Steve tried to fix it up more.  A commit I made Friday undoes this.

I noticed!  :-)

I also noticed that you fixed up the includes for string and mem*
functions in acconfig.h.  Thanks!  What I had was copied directly out of
the autoconf manual.  I guess the manual should be updated, eh? 

>     Note that it's not feasible to use varargs.h with ANSI C prototypes.

[ ... ]

>     work to get it right.  Thoughts/concerns?

Is it the case that all compilers that handle prototypes have stdarg.h?

If stdarg.h is *required* to build fvwm, shouldn't we check for it in
configure and exit with a FATAL error if not found?  Currently vprintf and
vfprintf are probed for but the corresponding symbols (HAVE_VPRINTF,
HAVE_VFPRINTF) are never checked. 

For the instant, it doesn't bother me to drop varargs.h support.  All my
environments include gcc which supplies stdarg.h anyway.  But if there's a
chance that someone will try to build on a platform without stdarg.h, then
I think we should re-visit this before a 2.2 release comes out.

>     Makefile.in's changed.

It was me.  I had to change them because the ones you checked in had "TAR
= gtar" in them.  I don't understand why the TAR variable is hardcoded in
distributed files anyway.  It seems to be a bug in automake. 

>     They _shouldn't_ be changed every time like
>     rebuilt, always use --foreign. 

That was me, too.  I built the 2.1.1 distribution by linking
archives/COPYING into the root and using --gnu, since all the rest of the
required files (NEWS, AUTHORS, etc) are there, even if empty.

I thought the copyright issues were worked out now?  Dominik?  Can we put
the COPYING file into the root dir now?

--
Steve Robbins                              <[email-masked]>

I'm a member of the Elvis Death Cult.

---

From: Steve Robbins <[email-masked]>
Date: Sun, 8 Nov 1998 14:01:10 -0500 (EST)

> >     from the dist?  In particular:

Me too.

I also favour removing the entire icons directory into its own
distribution.  Someone (Paul?) already pointed out that the icons don't
change much, so they probably don't need to be under CVS control. 
Moreover, they don't really need to be tied to a particular fvwm
distribution. 

> size is extras/FvwmScript.

Size is not the only issue.  

There is duplication: FvwmM4 and FvwmCpp, for example, perform extremely
similar functions; Chuck has already said that he started work on merging
them into one module.  FvwmEvent seems to have been born of FvwmAudio, so
the latter is now obsolete, isn't it? 

There is also age: a module that is not maintained properly is very likely
to be broken.  To distribute code (even if labelled as "extra") that may
or may not work reflects badly upon us.  

> >     update and build fvwm if we could get rid of unnecessary stuff.

I think this is a good idea.

There are a few sort of "core" modules, like the pager, buttons, etc, that
should be distributed with fvwm.  The rest can be distributed separately.

Basically, the fvwm distribution should have a sample system.fvwm2rc file
that is very vanilla.  All the modules required for this sample file
should be included.  None of the others need be. 

When love is gone, there's always justice.
And when justice is gone, there's always force.
And when force is gone, there's always Mom.

---

From: Patrick Rogan <[email-masked]>
Date: Sun, 08 Nov 1998 15:58:19 -0500

> Uh, well I have one of those systems, so I'm a little concerned!  

I second that!  I've got one of those new-fangaled 64 bit alphas, too...

~p@

---

From: Dan Espen <[email-masked]>
Date: Sun, 08 Nov 1998 18:00:16 -0500

> Moreover, they don't really need to be tied to a particular fvwm

Didn't someone recently propose builtin menus with mini-icons?
Seemed like a good idea to me.

> the latter is now obsolete, isn't it? 

Sorry, I don't see  duplication as a   problem.  (Maybe for  us during
builds, but we are a minority.)  I don't  use M4 or  Cpp, but I'm sure
there are people that do.  If we drop one we inconvienience some group
of people.

FvwmEvent  and FvwmAudio  present   similar   issues.   FvwmAudio   is
redundant (not obsolete?) but users config  files still invoke it.  If
we  come up with  some way  to make  FvwmAudio  config files work with
FvwmEvent, I'm all for it.

> or may not work reflects badly upon us.  

Hmm...

I haven't   seen  any  module  become   more broken  due   to lack  of
maintenance, the module interface is amazingly stable.  There seems to
have been  one  incompatible change between  fvwm 1.x  and  2.x.  (Not
counting new facilities.)

> should be included.  None of the others need be. 

I'm not clear on what the proposal is.  Are we just dumping things, or
creating a separate source tree for the extras.  Which things?

---

From: [email-masked] (Paul D. Smith)
Date: 08 Nov 1998 20:08:09 -0500

%% Steve Robbins <[email-masked]> writes:

  >> * I know there is a _potential_ bug in the new packet sending code
  >> for any non-32-bit system (any system where sizeof(int) !=
  >> sizeof(long)).

  sr> Uh, well I have one of those systems, so I'm a little concerned!  

Hm.  Does it work for you?  (The ultimate test :).  It may be that
_so_far_ there are no problems because the values passed to variadic
functions are all of type long anyway.

Or, the compiler may be automatically promoting all integers to the
largest type (although that seems wrong to me... my C standard is at
work, though).

  sr> [Actually, I'm a bit confused, too.  The alpha reports that an int
  sr> is only 32 bits, where longs and pointers are 64!  I wonder if
  sr> they did this so as to not break code that assumes 32 bit
  sr> integers?]

There's nothing wrong with that.  The C standard only requires that
sizeof(short) <= sizeof(int) <= sizeof(long), and short must be at least
16 bits (and I think long must be at least 32, but I forget).

Am I missing the confusion? :)

  sr> I didn't really catch all the rest of what you said, but we'll
  sr> have to figure out some portable way to handle this.  And soon.

I specified the proper code in my email: all the integers passed to
variadic functions (those with "..." in the parameter list, specifying
that they take a variable number of arguments) must be explicitly cast
to the type you want them to have.

The deal is this: if you have a prototype in scope:

  void foo(unsigned long)

and you pass this function a variable of type "int", the compiler is
required to do the integer promotion from int to long for you by the C
standard.

But in the case of a variadic function there's no prototype, so the
compiler can't do that.  I _think_ (again I don't have my standard
handy) that in the absence of a prototype the compiler is supposed to
promote everything to "int", but I forget.

In this case (and in the other very common case of a variable number of
pointers, delimited by a NULL pointer, which everyone also forgets) you
need to cast the value by hand in order to ensure proper promotion
(remember NULL is just a 0; it's only in a pointer context that it
becomes the magical "null pointer").

So, all the arguments BroadcastPacket(..., foo, bar, baz) should be
BroadcastPacket(..., (unsigned long)foo, (unsigned long)bar, (unsigned
long)baz).  However, although I did know this I didn't do it because
that's a royal pain.  My email was to suggest we create a typedef for
"unsigned long" so we don't have to type the entire thing out over and
over :-/.

  sr> I also noticed that you fixed up the includes for string and mem*
  sr> functions in acconfig.h.  Thanks!  What I had was copied directly
  sr> out of the autoconf manual.  I guess the manual should be updated,
  sr> eh?

Probably.  The GNU make stuff has been around a lot longer and on more
systems :)

  sr> Is it the case that all compilers that handle prototypes have stdarg.h?

Well, probably.  But either way you cannot use varargs.h with
prototypes, so if we're requiring prototypes we must require stdarg.h.

  sr> If stdarg.h is *required* to build fvwm, shouldn't we check for it
  sr> in configure and exit with a FATAL error if not found?  Currently
  sr> vprintf and vfprintf are probed for but the corresponding symbols
  sr> (HAVE_VPRINTF, HAVE_VFPRINTF) are never checked.

Well, I put some code for this into libs/debug.c (or maybe
libs/fvwmlib.h, I forget).  But in general you're right, there's some
missing configuration there.

  sr> For the instant, it doesn't bother me to drop varargs.h support.
  sr> All my environments include gcc which supplies stdarg.h anyway.
  sr> But if there's a chance that someone will try to build on a
  sr> platform without stdarg.h, then I think we should re-visit this
  sr> before a 2.2 release comes out.

Agreed... but as I said, it'd be an extraordinarily strange system that
had a prototype-capable compiler but didn't have stdard.h.

  sr> It was me.  I had to change them because the ones you checked in
  sr> had "TAR = gtar" in them.

Ah.  I'll look into that.

---

From: [email-masked] (Paul D. Smith)
Date: 09 Nov 1998 00:19:04 -0500

>> >     update and build fvwm if we could get rid of unnecessary stuff.

  sr> I think this is a good idea.

  sr> There are a few sort of "core" modules, like the pager, buttons,
  sr> etc, that should be distributed with fvwm.  The rest can be
  sr> distributed separately.

  sr> Basically, the fvwm distribution should have a sample
  sr> system.fvwm2rc file that is very vanilla.  All the modules
  sr> required for this sample file should be included.  None of the
  sr> others need be.

I agree with this, sort of.  Definitely everything required by
system.fvwm2rc should be provided by default.  However, it's not
entirely obvious to me we should provide only the most generic stuff.  I
dunno, I just don't like it when I have to go get 3 or 4 separate
packages and install them before I can get interesting functionality.
I would like to see a simple, but still interesting default setup that
used some mini-icons, maybe some other things.  We could ship 2 or
three: basic, medium, and gaudy or something.

And I think it would be nice if there were a basic set of tools everyone
(writing modules and themes) could rely on: for example, FvwmAnimate
relies on FvwmForm being available, and I really like the direction Dan
is taking with gui configurability in general.  If FvwmForm isn't
standard, that will be a whole lot harder (as an example).

Maybe someone should generate a list of what we have, module-wise, and
make initial suggestions.  That might be the best way to reach consensus
on this.

PS. I really agree with Dan that something like FvwmForm _must_ provide
    the ability to set "defaults" that take effect for all forms that
    don't explicitly override them.  This kind of thing will be crucial
    for good themes, I expect.  I'm not extremely familiar with the
    module config interface: is something like that possible now, or
    does fvwm only feed lines matching the "module alias"?

---

From: Steve Robbins <[email-masked]>
Date: Mon, 9 Nov 1998 00:16:46 -0500 (EST)

> there are people that do.  If we drop one we inconvienience some group

The problem with duplicated code is not BUILDing it, but MAINTAINing it. 
It means you have to apply the same fix multiple times.  If you forget an
instance of the code, something may break.  It means you have to debug
very similar code multiple times.  This is boring, so if the code is
similar enough one is tempted to test one instance and assume the others
also work.  Not good. 

In short: it is inelegant and, for reasons alluded to above, I tend to
view duplicated code as less trustworthy. 

> redundant (not obsolete?) but users config  files still invoke it.

You're right, I meant "redundant".

> creating a separate source tree for the extras.  Which things?

There were actually two proposals that I lumped together.  However, either
one or the other or both could be adopted:

1.  Remove redundant code from the distribution.  Two examples were cited
above: dropping FvwmAudio in favour of FvwmEvent (if it is truly a
superset), and merging the functionality of FvwmCpp and FvwmM4 into
FvwmPreproc.  

2.  Remove "non-core" modules.  I don't have a clear idea of what the
criteria for being considered "core" should be.  Clearly, it should
include the modules used in the most simple config file from "samples". 
I'm not sure it would include everything in "extras", though. 

Removing a module does not mean it would disappear.  If there were
sufficient interest, it would get maintained by someone.  Removing a
module means that the fvwm distribution proper is smaller, more focused,
and has a higher probability of all working together. 

Is there something wrong with this?
I don't see how there possibly could be:
The waterbed's on fire, 
but everything else is as it should be.

---

From: Steve Robbins <[email-masked]>
Date: Mon, 9 Nov 1998 00:28:20 -0500 (EST)

> Am I missing the confusion? :)

Yes, because I wasn't being clear.  I thought the alpha was a "64 bit
machine" and I assumed this meant it had 64 bit registers.  What puzzles
me is: why use only half the register width for integers?  Sure, a 32-bit
integer follows the C standard, but then you haven't derived any benefit
from the "64 bitness" of the machine (except for pointers).

> prototypes, so if we're requiring prototypes we must require stdarg.h.

Okay I'm confused again.

Why are varags.h and prototypes incompatible?  Granted, you can't
prototype a varadic function.  But does that mean you can't prototype the
other (non-varadic) functions?

You can't prototype the stdarg.h version of varadic functions either, can
you?

---

From: [email-masked] (Paul D. Smith)
Date: 09 Nov 1998 00:54:57 -0500

>> there are people that do.  If we drop one we inconvienience some group

  sr> The problem with duplicated code is not BUILDing it, but MAINTAINing it. 
  sr> It means you have to apply the same fix multiple times.  If you forget an
  sr> instance of the code, something may break.  It means you have to debug
  sr> very similar code multiple times.  This is boring, so if the code is
  sr> similar enough one is tempted to test one instance and assume the others
  sr> also work.  Not good. 

  sr> In short: it is inelegant and, for reasons alluded to above, I tend to
  sr> view duplicated code as less trustworthy. 

My problem with it is slightly different: I think it's _confusing_.

Let me use the example of buttonbars/icon managers.  We have the builtin
windowlist, builtin iconbox, FvwmButtons, FvwmIconBox, FvwmIconMan,
FvwmWinList, FvwmGoodStuff, FvwmTaskBar, and FvwmWharf.  That's 9
different ways to deal with windows/icons!  Now, all of these (I
assume!) do slightly different things--I'm not very familiar with most
of them.  However, they're all somewhat overlapping, I think, and that's
pretty confusing for the user.  I know it confuses me!

Why should they use this one over that one?  What are differences?  The
features?  The shortcomings?  Which, if any, make sense to use together?
At the very least these things should be centrally documented.

  sr> 1.  Remove redundant code from the distribution.

  sr> 2.  Remove "non-core" modules.

I'd like to see the main areas of current modules examined, and try to
focus on _one_ module for each area.  This may mean merging features of
multiple modules or something, and I'm not saying this should be a 2.2
goal, of course.  But that's what I'd like to see.  Obviously the module
interface is still public and people can write all sorts of new
modules.  Maybe one of them will even become better than what's in fvwm
and become a standard.  My hope is that with a more open source
development there won't be as much incentive to "fork" whole new modules
to get slightly (?) different behavior.

Certainly there's something to be said for smaller, targeted modules but
there's also something to be said for more generically useful modules so
we don't need as many...

---

From: [email-masked] (Paul D. Smith)
Date: 09 Nov 1998 01:02:12 -0500

sr> Yes, because I wasn't being clear.  I thought the alpha was a "64
  sr> bit machine" and I assumed this meant it had 64 bit registers.
  sr> What puzzles me is: why use only half the register width for
  sr> integers?  Sure, a 32-bit integer follows the C standard, but then
  sr> you haven't derived any benefit from the "64 bitness" of the
  sr> machine (except for pointers).

Ah.  Well, you'd need to ask an Alpha person about this :).

  >> prototypes, so if we're requiring prototypes we must require stdarg.h.

  sr> Okay I'm confused again.

  sr> Why are varags.h and prototypes incompatible?  Granted, you can't
  sr> prototype a varadic function.  But does that mean you can't
  sr> prototype the other (non-varadic) functions?

No, you can.  But the point is, if your compiler supports prototypes
then it either (a) can't do variadic functions, which seems almost
impossible, or (b) has stdarg.h.  Or, I guess, (c) which is it has some
completely non-standard way of doing it.

So if we require a prototyping compiler it seems not worth it to worry
about not having stdarg.h.

Not that I'm saying we shouldn't test for it in configure, mind you.
That's probably a good thing.  I'm just saying we probably don't need to
spend a lot of coding effort in fvwm attempting to work with varargs.h
environments.

But, I could be wrong :).

  sr> You can't prototype the stdarg.h version of varadic functions
  sr> either, can you?

Sure, that's what ... is for:

  void foo(int count, ...);

---

From: Dan Espen <[email-masked]>
Date: Mon, 09 Nov 1998 08:20:08 -0500

> make initial suggestions.  That might be the best way to reach consensus

I have to  say, I admire Dominik's approach.   He  combines 2 modules,
points out the remaining problems, and we are done.

If  we  get the  make  process to  create  the links  needed,  I guess
FvwmAudio will follow shortly.

>     does fvwm only feed lines matching the "module alias"?

This is the relevant part of modconf.c:

void SendDataToModule(XEvent *eventp,Window w,FvwmWindow *tmp_win,
	      unsigned long context, char *action, int *Module)
{
  struct moduleInfoList *t;
...
  t = modlistroot;
  while(t != NULL) {
    SendName(*Module,M_CONFIG_INFO,0,0,0,t->data);
    t = t->next;
  }  
  SendPacket(*Module,M_END_CONFIG_INFO,0,0,0,0,0,0,0,0);
}

"modlistroot" is the list of all module config commands.
Note that fvwm2 has no knowledge of a module's alias.
This is something I'd like to fix, but it could get a little
tricky, as arg 1 to a module is not always the alias.

So the answer is...yes its possible now.

---

From: Steve Robbins <[email-masked]>
Date: Mon, 9 Nov 1998 11:18:00 -0500 (EST)

Hi Paul,

Sorry for being pedantic on this.  This is a genuine question, and not
rhetorical.

 

I didn't see the connection between varags.h and prototypes, so I asked:

>   sr> Why are varags.h and prototypes incompatible?

And Paul says:

> [...]  But the point is, if your compiler supports prototypes

So, this seems to come back to the original answer: "probably".

There is no connection between prototypes and stdarg.h.  You could
logically have a compiler with prototypes, varargs.h but without stdarg.h. 

On the other hand, if the compiler knows prototypes, it likely also has
stdarg.h.  In other words, option (b) is more likely than (c). 

Is this a correct reading?  

I am an anarchist.  
I am the antichrist.

---

From: [email-masked] (Paul D. Smith)
Date: 09 Nov 1998 13:04:27 -0500

sr> Sorry for being pedantic on this.  This is a genuine question, and not
  sr> rhetorical.

S'ok :)

 
  >> >> prototypes, so if we're requiring prototypes we must require stdarg.h.

  sr> I didn't see the connection between varags.h and prototypes, so I
  sr> asked:

Hm, I misread your question if that's what you wanted to know :).

They're incompatible because you cannot declare a function that uses the
"..." format using varargs.h.  Varargs.h creates a special type called
"va_dcl" that _requires_ an old-style, non-prototyped function
definition.  That is, to use varargs.h you _must_ declare your variadic
function like this:

  int foo(va_alist)
    va_dcl      /* Note!  No semicolon here, either! :( */
  {
    va_list ap;

    va_start(ap);
    ...
    va_end(ap);
  }

This is quite incompatible with prototypes "..." format; you can't use
them together.  Or at least, I've never heard of a way (and I can't see
any way) to do so.

So...

  >> [...]  But the point is, if your compiler supports prototypes then
  >> it either (a) can't do variadic functions, which seems almost
  >> impossible, or (b) has stdarg.h.  Or, I guess, (c) which is it has
  >> some completely non-standard way of doing it.

In other words, since varargs.h can't be used with "...", if the
compiler supports "..." it must support something besides varargs.h.

So, either (case a) it supports prototypes in general but _not_ "..." in
particular, which I've never heard of, or (case b) it supports "..." and
has stdarg.h (most everyone), or (case c) it supports "..." and has some
other way, not stdarg.h or varargs.h, to deal with it (again, I've not
heard of this--seems very silly to not use stdarg.h in this case).

  sr> There is no connection between prototypes and stdarg.h.  You could
  sr> logically have a compiler with prototypes, varargs.h but without
  sr> stdarg.h.

I don't see how this is possible (assuming, here, you are including the
"..." notation when you say "prototypes").  Without stdarg.h (or some
other, non-varargs.h method) prototyped variadic functions are useless
as they cannot be defined.

---

From: Dan Espen <[email-masked]>
Date: Tue, 10 Nov 1998 09:29:36 -0500

> tricky, as arg 1 to a module is not always the alias.

Forgot to mention, I've updated the web docs so that this is now
fully explained.

> >  Paul D. Smith <[email-masked]>         Network Management Developm
> 
> --

---

From: Dan Espen <[email-masked]>
Date: Tue, 10 Nov 1998 09:29:36 -0500

---

From: [email-masked] (Paul D. Smith)
Date: 10 Nov 1998 19:37:38 -0500

>> tricky, as arg 1 to a module is not always the alias.

In retrospect, I wish the module command line had been defined to use
UNIX option format instead of a fixed set of parameters, and that
modules were required to ignore any params that they didn't understand.
Might have made upgrades simpler...