Allow printf-style arguments for Dart_Error and Api::Error.

Allow printf-style arguments for Dart_Error and Api::Error.

Convert one error message to use the new facility for testing
purposes.  The rest of the errors will be improved in follow-on
changes.

Add tests.

Minor comment fixes in dart_api_impl.h.

[turnidge, 2011-11-07 19:19:04]

Siva,

Using printf involves an extra copy step for all error messages.  I don't think
that this is a big deal, but wanted to point it out.

I'm truncated the error messages at 1024 chars right now.  I could add in code
to use the return value of VSNPrintf to resize the buffer but I'm just not sure
if it's really worth it.  Let me know what you think.

Todd

[siva, 2011-11-07 23:20:50]

LGTM

http://codereview.chromium.org/8492015/diff/1/runtime/include/dart_api.h
File runtime/include/dart_api.h (right):

http://codereview.chromium.org/8492015/diff/1/runtime/include/dart_api.h#newc...
runtime/include/dart_api.h:124: * claim ownership of the 'error' parameter.
The comment is out of date now as there is no explicit 'error' parameter

http://codereview.chromium.org/8492015/diff/1/runtime/vm/dart_api_impl.cc
File runtime/vm/dart_api_impl.cc (right):

http://codereview.chromium.org/8492015/diff/1/runtime/vm/dart_api_impl.cc#new...
runtime/vm/dart_api_impl.cc:2023: OS::VSNPrint(buffer, 1024, format, args);
Normally we have used this style to avoid having to allocate a standard size
buffer:
      intptr_t length = OS::SNPrint(NULL, 0, format, function_name.ToCString());
      msg = reinterpret_cast<char*>(Api::Allocate(length + 1));
      OS::SNPrint(msg, (length + 1), format, function_name.ToCString());

[turnidge, 2011-11-07 23:55:35]

http://codereview.chromium.org/8492015/diff/1/runtime/include/dart_api.h
File runtime/include/dart_api.h (right):

http://codereview.chromium.org/8492015/diff/1/runtime/include/dart_api.h#newc...
runtime/include/dart_api.h:124: * claim ownership of the 'error' parameter.
On 2011/11/07 23:20:50, asiva wrote:
> The comment is out of date now as there is no explicit 'error' parameter

Got rid of the comment.  Nobody expects printf to claim ownership of its
arguments.nn

http://codereview.chromium.org/8492015/diff/1/runtime/vm/dart_api_impl.cc
File runtime/vm/dart_api_impl.cc (right):

http://codereview.chromium.org/8492015/diff/1/runtime/vm/dart_api_impl.cc#new...
runtime/vm/dart_api_impl.cc:2023: OS::VSNPrint(buffer, 1024, format, args);
On 2011/11/07 23:20:50, asiva wrote:
> Normally we have used this style to avoid having to allocate a standard size
> buffer:
>       intptr_t length = OS::SNPrint(NULL, 0, format,
function_name.ToCString());
>       msg = reinterpret_cast<char*>(Api::Allocate(length + 1));
>       OS::SNPrint(msg, (length + 1), format, function_name.ToCString());

Done.

[Anton Muhin, 2011-11-08 08:32:18]

DBC

http://codereview.chromium.org/8492015/diff/4001/runtime/vm/dart_api_impl.cc
File runtime/vm/dart_api_impl.cc (right):

http://codereview.chromium.org/8492015/diff/4001/runtime/vm/dart_api_impl.cc#...
runtime/vm/dart_api_impl.cc:2023: OS::VSNPrint(buffer, len+1, format, args);
nit: space around + ?

http://codereview.chromium.org/8492015/diff/4001/runtime/vm/dart_api_impl.cc#...
runtime/vm/dart_api_impl.cc:2031: Dart_Handle Api::Error(const char* format,
...) {
looks pretty much like Dart_Error.  Do we need both?

[turnidge, 2011-11-08 19:01:56]

http://codereview.chromium.org/8492015/diff/4001/runtime/vm/dart_api_impl.cc
File runtime/vm/dart_api_impl.cc (right):

http://codereview.chromium.org/8492015/diff/4001/runtime/vm/dart_api_impl.cc#...
runtime/vm/dart_api_impl.cc:2023: OS::VSNPrint(buffer, len+1, format, args);
On 2011/11/08 08:32:18, antonmuhin wrote:
> nit: space around + ?

Done.

http://codereview.chromium.org/8492015/diff/4001/runtime/vm/dart_api_impl.cc#...
runtime/vm/dart_api_impl.cc:2031: Dart_Handle Api::Error(const char* format,
...) {
On 2011/11/08 08:32:18, antonmuhin wrote:
> looks pretty much like Dart_Error.  Do we need both?

I am providing Dart_Error for external developers.  The "Api" apis are a bit
more extensive and for internal use.  We may be able to get rid of one in the
future -- perhaps by moving more of the "Api" apis to "Dart_" and always using
those.

Will keep this in mind for later.