Thanks Martin, that's just what I'll do. However, isn't the entire point of a groveler to build a little C program that gathers information like this for later use? If one were to write a general purpose way to do this, wouldn't the logical place to put that code be in cffi-groveler? Is the main hurdle here the fact that HUGE_VAL doesn't necessarily have a representation as a Lisp interger or double-float, the only two types that cvar allows? Even though some of these sound a bit rhetorical, these are honest questions.
Zach On Fri, Apr 26, 2013 at 8:25 AM, Martin Simmons <mar...@lispworks.com>wrote: > >>>>> On Thu, 25 Apr 2013 20:55:38 -0600, Zach said: > > > > > (constant (+huge-val+ "HUGE_VAL") :type integer) > > > > > > then > > > > > > (with-foreign-object (huge-ptr :uint64) > > > (setf (mem-ref huge-ptr :uint64) +huge-val+) > > > (nlopt-set-lower-bound opts huge-ptr)) > > > > I have also been thinking along these lines. The only thing I worry > about > > is whether this is strictly correct or just correct in practice. Is > there > > a guarantee that a double float is always the same size as a uint64. > It's > > true on every platform I have ever programmed for (I think), but will it > > always be true? Back when I programmed in C more often, hard coding data > > type sizes into a program just seemed wrong so I didn't do it, so I > guess I > > wouldn't know. Perhaps I am sweating a non-issue... > > That's not the only problem -- on some platforms, HUGE_VAL is not a > compile-time constant. It looks like the only portable way to get the > value > is to write a C helper function to return it. > > -- > Martin Simmons > LispWorks Ltd > http://www.lispworks.com/ > >
