From berwin at maths.uwa.edu.au  Sun Aug 28 13:46:24 2005
From: berwin at maths.uwa.edu.au (Berwin A Turlach)
Date: Sun, 28 Aug 2005 19:46:24 +0800
Subject: [Rd] Coding standards (was Re:  bug in L-BFGS-B? (PR#8099))
In-Reply-To: <Pine.LNX.4.61.0508271525290.4656@gannet.stats>
References: <20050827141028.DCE0218B9F@slim.kubism.ku.dk>
	<Pine.LNX.4.61.0508271525290.4656@gannet.stats>
Message-ID: <17169.42000.451244.55081@bossiaea.maths.uwa.edu.au>

G'day Brian,

>>>>> "BDR" == Prof Brian Ripley <ripley at stats.ox.ac.uk> writes:

    BDR> As for the problem, yes it probably is a bug in L-BFGS-B.
    BDR> Fancy debugging the code?
I was afraid that somebody would ask this. ;-)

I looked a bit at the code and it seems to be non-trivial.  Moreover,
it seems to be code translated from FORTRAN to C via f2c and I am not
a fan of such kind of code.  I know that "Writing R Extensions" lists
in Appendix B ("R coding standards") f2c as a tool that `can "safely
be assumed" for R extensions'.  However, f2c, despite its `-A' option,
does not produce ANSI C compliant code but rather C code that provokes
undefined behaviour.

The problem is, that the code produced by f2c is decrementing pointers
to simulate 1-based vectors and the C FAQ is pretty unambigious about
the fact that this provokes undefined behaviour, see
        http://www.eskimo.com/~scs/C-faq/q6.17.html

As far as I understand, this translated code mostly stems from the
time when some platforms did not have ready access to a fortran
compiler and, hence, f2c was used (extensively?).  But now, with g77
this does not seem to be an issue anymore.  So I wonder whether there
are any plans of returning to the original fortran code?  Or are there
plans to clean up these f2c'd code snippet to make them ANSI C
compliant?  

I noticed such f2c'd code already in the splines.c file when I studied
how splinefun was implemented (which lead to bug report #8030).  In
that case, I am fairly familiar with the algorithms used in splines.c
since I programmed them myself on other occassions and I probably
could rewrite the algorithms in proper ANSI C (it would still take
some time).  But it would be nice to know what the official stance of
the R Core Team is.

When I spoke with one member of the R Core Team about this on a
conference in 2004, the answer was, IIRC, "yes, we know that this code
invokes undefined behaviour, but there are bigger problems to fix
first and this pointer manipulation seems to work on all platforms
these days."  Another member of the R Core Team whom I recently asked:

      I guess all platforms on which R is running at the moment do not
      have a problem with this trick, but are there any plans to
      change such kind of code to "valid" C?  Would patches that do
      that be accepted?

answered:

      Hmm, I think we'd tend to disagree here. But in any case that
      would be a wide issue.  Can you address this question to R-core,
      please?  (or I forward?)

Cheers,

        Berwin



[Rd] Coding standards (was Re: bug in L-BFGS-B? (PR#8099))
Berwin A Turlach