Problems with warnings from loess under Windows, at least (PR#119)

[ripley@stats.ox.ac.uk]

There are two separate problems with loess under Guido's rw0632 on
Windows, neither of which appear unless you try to do something that it is
trying to tell you is inadvisable.  It bombs trying to tell you. I have
put up a replacement modreg.zip in the CRAN contrib collection that will
be mirrored tonight.

Both of these could potentially affect other platforms.

(1) A problem relating to the declaration of problem_buf in S.h.

> On Fri, 5 Feb 1999, Guido Masarotto wrote:

> On Thu, Feb 04, 1999 at 06:54:34PM +0000, Prof Brian D Ripley wrote:
> > OK, I have got to the bottom of this.
> > 
> > For some reason Guido has problem_buf in globalvar.h, twice. It should
> > not be there, and used not to be.  That means that any call to warning() or
> > stop() from compiled code in a DLL will bomb R. The solution is to remove
> > those lines and re-compile modreg.  I can do that for you if you need it.

>   The problem seems to happen
>   since every file which includes S.h declare a 'public' version
>   of problem_buf,i.e, got a declaration of the type
>   char problem_buf[4096];
>   I suspect that problem_buf should or declared extern (with memory
>   allocated somewhere, e.g.,in src/main.c) or static.
>   (BTW, the two files are appl/loglin.c and main/print.c).
>   In general, I am beginning to think that my 'automatic'
>   approch for globalvar.h is too much dangerous. It assumes
>   that global variables in all the 'main' files are 
>   properly declared and named. And, this is not the case now.

This needs resolving to static or extern for all the platforms. Those
writing `main' files might like to be aware that leaving symbols exposed
causes some problems, as on Windows we have to declare as imports all the
variables used from the R engine. The current scheme is to assume that all
exposed variables are intended to be imported.  (Can f1 and f2 in
approx.c be declared static?)

(2) Problems mixing Fortran and C.

> > The messages are then not very clear, because loessf.f passes strings
> > to loessc.c to call the warning/stop routines, and in Windows (but not
> > Unix) those strings seem to be missing a '\0' terminator. So you gets of
> > the next string, .... That will need rather more extensive changes to fix.

The problem here is that the loess code (not mine!) assumes that Fortran
uses strings in C format. This is not a safe assumption, but I was
surprised to find it not true for a port of g77. There may be no universal
answer, but I have modified the code to pass to C what Fortran thinks the
length is, and this works on the platforms I have. I will submit the
changed code shortly.

-- 
Brian D. Ripley,                  ripley@stats.ox.ac.uk
Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
University of Oxford,             Tel:  +44 1865 272861 (self)
1 South Parks Road,                     +44 1865 272860 (secr)
Oxford OX1 3TG, UK                Fax:  +44 1865 272595


-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !)  To: r-devel-request@stat.math.ethz.ch
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._