Thanks Achim for finding and fixing this bug. I do agree about fuzziness between int and float. My Emacs considers 2305843009213693951 as an integer, 2305843009213693952 too large to be an integer. My C++ compiler sees 4294967295 as an integer, 4294967296 as too large to fit an int.
So Babel C++ may cause problem for large integers. I am not sure how we can fix this in any case. In the meantime, we can force large values to be declared as doubles by adding dot zero like this: #+BEGIN_SRC C++ :var large=9876543210 .0 printf ("%g", large); #+END_SRC Thierry Le 13/06/2014 08:51, Achim Gratz a écrit : > Eric Schulte writes: >> This new patch looks great, and the test suite passes locally. I've >> just applied it. > You also get a warning from the byte-compiler on something that is > clearly a bug. I think the fix should be: > > --8<---------------cut here---------------start------------->8--- > diff --git a/lisp/ob-C.el b/lisp/ob-C.el > index dd03fa7..a794e2a 100644 > --- a/lisp/ob-C.el > +++ b/lisp/ob-C.el > @@ -264,7 +264,7 @@ (defun org-babel-C-val-to-C-type (val) > (list > (if (equal org-babel-c-variant 'd) "string" "const char*") > "\"%s\"")) > - (t (error "unknown type %S" type))))) > + (t (error "unknown type %S" basetype))))) > (cond > ((integerp val) type) ;; an integer declared in the #+begin_src line > ((floatp val) type) ;; a numeric declared in the #+begin_src line > --8<---------------cut here---------------end--------------->8--- > > The type determination is a tad optimistic, too. An Emacs integer may > or may not fit into C type "int" depending on how Emacs is compiled and > which compiler you are using. > > > Regards, > Achim.