public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Mike Hearn <mike@plan99.net>
To: Jonas Schnelli <jonas.schnelli@include7.ch>
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Introducing BitcoinKit.framework
Date: Tue, 16 Jul 2013 11:21:40 +0200	[thread overview]
Message-ID: <CANEZrP0McSrVzwv=-qimPyX41EEDmyQdYW5QjPr_i+KWyJZSZw@mail.gmail.com> (raw)
In-Reply-To: <2BDA0943-22BB-4405-9AF0-86FB41FD04A6@include7.ch>

[-- Attachment #1: Type: text/plain, Size: 3024 bytes --]

> Clear. Your right. C++ would give us more flexibility (other platforms)
> and also android compatibility (through NDK).
>

I'm a bit confused I'm afraid. bitcoinj already runs SPV wallets on Android
on top of Dalvik. In fact that's what it's designed for. The NDK is not
necessary to work with Bitcoin at any point.


> That's a great idea.
> Let me look into the quality of j2c's output.
>

There's an example of what it looks like here:

https://code.google.com/a/eclipselabs.org/p/j2c/wiki/Examples

If you're serious about playing with j2c let me know. It's an amazing piece
of work BUT it was written for fun, and as such isn't really documented at
all. It took me a little while to figure out how to make it work properly.
I'm now fixing bugs in it and making various improvements along with
filling out the native stubs (a.k.a. portability layer). If you want to
catch up to where I'm at, I can send you some notes because otherwise you
might waste a lot of time on blind alleys.

The main things be aware of so far are:

   - Lots of explicit null pointer checks are generated. The reason is that
   the output is meant to be entirely portable, so Jacek doesn't want to rely
   on platform specific stuff like signals or SEH. Simplest solution is just
   to disable npc() generation entirely because normal C++ libraries just
   segfault if a null pointer gets in the wrong place, they don't throw
   exceptions. Losing the Java behaviour would not be a downgrade for people
   used to C++.

   - Array accesses don't seem to be properly bounds-checked. That's a part
   of the Java security model - bitcoinj is written on the assumption that
   buffer and heap overflows aren't possible because they're caught by the
   runtime. If those checks go missing then it'd likely become possible to
   hack your program by exploiting buffer overflows. So that needs to be fixed.

   - Generated code doesn't use the STL of course, it can't because the
   Java library has more features than the STL. However as the way j2c works
   is you transpile your code alongside a copy of the (open source) Java class
   library, you can go in and modify the generated code for java::lang::String
   or java::util::List and so on to add helper methods for converting to
   various other forms. On Linux you'd have implicit c'tors to go back and
   forth between std::string, on MacOS X you'd have conversions for NSString,
   you could add code for QStrings or raw C strings too. Once the code has
   been generated you can extend or patch it to make the API more convenient.

   - Obviously, the resulting code requires the Boehm GC because there are
   no explicit delete calls anywhere. This is a safety feature though, it
   avoids use-after-free and double-free bugs that can create security holes.

   - The code generator doesn't do dependency tracing, so you end up with
   generated code that isn't used anywhere. It's up to the linker to do a dead
   code elimination pass. Otherwise the resulting binaries can be huge.

[-- Attachment #2: Type: text/html, Size: 3924 bytes --]

  parent reply	other threads:[~2013-07-16  9:21 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-15 10:07 [Bitcoin-development] Introducing BitcoinKit.framework Wendell
2013-07-15 13:19 ` Mike Hearn
2013-07-15 14:39   ` Wendell
2013-07-15 15:48     ` Mike Hearn
     [not found]       ` <3E7894A0-06F3-453D-87F8-975A244EBACF@include7.ch>
2013-07-15 20:08         ` Mike Hearn
     [not found]           ` <2BDA0943-22BB-4405-9AF0-86FB41FD04A6@include7.ch>
2013-07-16  9:21             ` Mike Hearn [this message]
     [not found]               ` <2F20A509-13A9-4C84-86D7-A15C21BACD53@include7.ch>
2013-07-16  9:51                 ` Mike Hearn
2013-07-16 10:17                   ` Wendell
2013-07-16 10:59                     ` Mike Hearn
2013-07-16 14:16                       ` [Bitcoin-development] SPV bitcoind? (was: Introducing BitcoinKit.framework) Wendell
2013-07-16 15:09                         ` Mike Hearn
2013-07-17 10:58                         ` Peter Todd
2013-07-17 12:29                           ` Mike Hearn
2013-07-17 14:32                             ` [Bitcoin-development] SPV bitcoind? Andreas Schildbach
2013-07-17 19:32                               ` Mike Hearn
2013-07-18 12:13                             ` [Bitcoin-development] SPV bitcoind? (was: Introducing BitcoinKit.framework) Peter Todd
2013-07-18 13:18                               ` Peter Todd
2013-07-18 13:38                               ` Mike Hearn
2013-07-17 13:37                           ` Wendell
2013-07-17 14:31                             ` Michael Gronager
2013-07-17 14:58                               ` Wendell
2013-07-17 19:33                                 ` Mike Hearn
2013-07-17 22:26                                   ` Michael Gronager
2013-07-17 23:04                                     ` Gregory Maxwell
2013-07-18  8:19                                     ` Mike Hearn
2013-07-18 11:40                                       ` Bazyli Zygan
2013-07-18 13:03                                         ` Michael Gronager
2013-07-18 13:16                                           ` Michael Gronager
2013-07-18 16:22                             ` Peter Todd
2013-07-18 16:46                               ` Wendell
2013-07-18 23:03                                 ` Peter Todd
2013-07-21 15:55                       ` [Bitcoin-development] Introducing BitcoinKit.framework Pieter Wuille
2013-07-21 17:20                         ` Mike Hearn
2013-07-22 13:08               ` Mike Hearn

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CANEZrP0McSrVzwv=-qimPyX41EEDmyQdYW5QjPr_i+KWyJZSZw@mail.gmail.com' \
    --to=mike@plan99.net \
    --cc=bitcoin-development@lists.sourceforge.net \
    --cc=jonas.schnelli@include7.ch \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox