This last part of the discussion is way out of my league, but if I 
understand, there are corner cases that could cause erroneous results when 
a Julia function with variable arguments passes those arguments to a C 
function that also accepts variable arguments. So this "issue" doesn't only 
affect the printf family. Doesn't it look like something that needs fixing?

The flexibility of the C printf is quite desirable, and in my opinion, it 
would make sense to have access to [f]printf / [f]scanf. The C printf is 
substantially faster than the "print_formatted" function in my code 
(originally proposed by Stefan). It's not full-featured by any means, but 
so far, it's done the job correctly.

On Monday, April 21, 2014 8:52:28 AM UTC-7, Jameson wrote:
>
> Unfortunately, va_list is also undefined at the ABI level, so different 
> compilers define it differently on the same platform, making it a worse 
> problem than that of adding syntax to Julia to declare varargs functions
>
> On Monday, April 21, 2014, Stefan Karpinski 
> <[email protected]<javascript:>> 
> wrote:
>
>> You may be able to use vprintf and family to do this more reliably and 
>> without needing metaprogramming at all, but unfortunately the definition of 
>> va_list is equally ill defined by the C standards. At least this avoids 
>> call-time ABI problems, however.
>>
>>
>> On Mon, Apr 21, 2014 at 10:17 AM, Jameson Nash <[email protected]> wrote:
>>
>>> On anything but x86-32 or older processors, the output is undefined.
>>> The compiler authors when ANSI C was introduced decided to sacrifice
>>> performance in order to make the three ways of declaring a C function
>>> (K&R-style without arguments, with arguments, and with varargs) to
>>> generate the same code for the x86-legacy processors of that time.
>>>
>>> However, newer ABI's, such as the x64 platform standard, define these
>>> function as using different rules for where to place the arguments,
>>> depending on the value in another register that is left uninitialized
>>> for non-variadic calls.
>>>
>>> On Win64, varargs are never placed in registers. On ARM, varargs are
>>> never optimized in their register allocation
>>>
>>> On Mon, Apr 21, 2014 at 1:30 AM, Dominique Orban
>>> <[email protected]> wrote:
>>> > I posted some timings here but I think they went unnoticed because 
>>> they're
>>> > buried in a conversation:
>>> > https://groups.google.com/d/msg/julia-users/7Sn5yys0UJE/Fy8TyTNNQEQJ
>>> >
>>> > Jameson, could you be more specific? In what kind of situation would 
>>> printf
>>> > give incorrect output?
>>> >
>>> >
>>> > On Sunday, April 20, 2014 8:06:52 PM UTC-7, Jameson wrote:
>>> >>
>>> >> just as a vague warning, va_arg lists are similar to, but subtly
>>> >> different from their fully specified counterparts. what this means is
>>> >> that calling printf from julia will work most of the time, but will
>>> >> also probably fail (by which I mean produce slightly incorrect output)
>>> >> at random and at the worst possible time given the same inputs
>>> >>
>>> >> On Sun, Apr 20, 2014 at 10:22 PM, Kevin Squire <[email protected]>
>>> >> wrote:
>>> >> > Looks interesting. I'm not at a computer right now, so can't test. 
>>> Can
>>> >> > you
>>> >> > give an example run? How are the timings?
>>> >> >
>>> >> > Kevin
>>> >> >
>>> >> >
>>> >> > On Sunday, April 20, 2014, Dominique Orban <[email protected]>
>>> >> > wrote:
>>> >> >>
>>> >> >> Here's how I wrapped printf, allowing for varargs:
>>> >> >> https://gist.github.com/dpo/11000433
>>> >> >> I'd be interested in any comments. I expect it's possible to wrap 
>>> scanf
>>> >> >> similarly?!
>>> >> >>
>>> >> >> On Friday, February 21, 2014 5:05:32 PM UTC-8, Stefan Karpinski 
>>> wrote:
>>> >> >>>
>>> >> >>> You could maybe make vscanf and company work though. In general, 
>>> using
>>> >> >>> the c library for this kind of thing will be awkward.
>>> >> >>>
>>> >> >>> > On Feb 21, 2014, at 7:12 PM, "Steven G. Johnson"
>>> >> >>> > <[email protected]>
>>> >> >>> > wrote:
>>> >> >>> >
>>> >> >>> > Varargs functions like scanf won't work with ccall, in general.
>>>
>>
>>  

Reply via email to