bug#7848: 23.2.91; Can't build with MinGW

[Eli Zaretskii <eliz@gnu.org>]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: kzhr@d1.dion.ne.jp,  7848@debbugs.gnu.org
> Date: Sun, 16 Jan 2011 10:21:53 -0500
> 
> >> I would recommend to stay away from such low-level code unless you're
> >> writing code that tries to implement part of the binding-semantics
> >> of Emacs.  I.e. just use Fset.
> > Using Fset here would be a terrible overkill, IMO.
> 
> Overkill?  For code that's not even inside a loop?  What are you talking about?

Look at its body, man.  All I want is to assign a simple value to a
simple global-scope variable.  Look how many unrelated use-cases the
implementation of Fset handles.  How can a mere mortal who was never
privy to the intimate details of whatever-local variables possibly
grasp what is going on there?  How can I be expected to be able to
install a quick and safe fix on a release branch with all that
complexity that is utterly unrelated to what I want to do?

If you want to avoid code that knows too much about variable
internals, we should have a much simpler utility function to do this
kind of job in such special cases.  SET_SYMBOL_VAL looked like such a
utility.

> > I'm not even sure I understand all of its semantics,
> 
> The semantics of Fset are the same as the ones of `setq' which you use
> days-in days-out in Elisp.

I use no Lisp at all during dumping.  There are certain things one
shouldn't do at that time.  My everyday experience in Emacs does not
help me in this case.

> I.e. it's the semantics you know best, whereas the semantics of
> SET_SYMBOL_VAL are a lot more tricky.

If it is tricky, please consider putting a suitable commentary near it
to explain the trickery, and also tell why this macro should be used
with care, or be avoided, or whatever.

> > and not sure it will work correctly in the context of an init_*
> > function that is called when Emacs is dumped.
> 
> Yes, it'll work just fine, pretty much in any context (the only tricky
> context in this respect is when/before the `nil' symbol&variable and the
> `unbound' value are built, AFAIK).

And I'm supposed to learn this from where, exactly? And how do I know
whether any specific code runs after that critical point?

That's precisely why I avoided Fset: because I could not convince
myself that it is always safe to use it in a function that runs during
dumping.  If Fset's implementation was simpler, I could have
understood that myself.

> I'm not complaining, at all.  Just giving advice.

Thanks for the advice.