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.