1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mh.in.england@gmail.com>) id 1Uz1S8-0000Xg-B2
for bitcoin-development@lists.sourceforge.net;
Tue, 16 Jul 2013 09:21:48 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.214.179 as permitted sender)
client-ip=209.85.214.179; envelope-from=mh.in.england@gmail.com;
helo=mail-ob0-f179.google.com;
Received: from mail-ob0-f179.google.com ([209.85.214.179])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Uz1S6-0008Ej-D5
for bitcoin-development@lists.sourceforge.net;
Tue, 16 Jul 2013 09:21:48 +0000
Received: by mail-ob0-f179.google.com with SMTP id xk17so473984obc.24
for <bitcoin-development@lists.sourceforge.net>;
Tue, 16 Jul 2013 02:21:41 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.60.99.42 with SMTP id en10mr688862oeb.85.1373966500948; Tue,
16 Jul 2013 02:21:40 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.76.23.36 with HTTP; Tue, 16 Jul 2013 02:21:40 -0700 (PDT)
In-Reply-To: <2BDA0943-22BB-4405-9AF0-86FB41FD04A6@include7.ch>
References: <B87F1213-5BD8-43F5-9744-F69947561ED5@grabhive.com>
<CANEZrP2xh=m8yWLt-o2UrrUVfU+cUYBuMVxkVFF5mVMtWdRwOQ@mail.gmail.com>
<C1727B41-AF61-44FA-BE17-5FE4425FDEA8@grabhive.com>
<CANEZrP0_H9+prDSF92q8a4QzP=fzDM6cTDv0+KcfV9NF9thkmw@mail.gmail.com>
<3E7894A0-06F3-453D-87F8-975A244EBACF@include7.ch>
<CANEZrP2jmWkDbpJEm0vd2CKF-prFNbz_ZeNJfDWtSCKb8k5ZXA@mail.gmail.com>
<2BDA0943-22BB-4405-9AF0-86FB41FD04A6@include7.ch>
Date: Tue, 16 Jul 2013 11:21:40 +0200
X-Google-Sender-Auth: O7fJJChmqu0PB-5OcMtV0ipoZ7E
Message-ID: <CANEZrP0McSrVzwv=-qimPyX41EEDmyQdYW5QjPr_i+KWyJZSZw@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Jonas Schnelli <jonas.schnelli@include7.ch>
Content-Type: multipart/alternative; boundary=047d7b33d26a38f0a504e19d8134
X-Spam-Score: -0.5 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(mh.in.england[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1Uz1S6-0008Ej-D5
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Introducing BitcoinKit.framework
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Tue, 16 Jul 2013 09:21:48 -0000
--047d7b33d26a38f0a504e19d8134
Content-Type: text/plain; charset=UTF-8
> 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.
--047d7b33d26a38f0a504e19d8134
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><div class=3D"gmail_quote">=
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex">
<div style=3D"word-wrap:break-word"><div>Clear. Your right. C++ would give =
us more flexibility (other platforms) and also android compatibility (throu=
gh NDK).</div></div></blockquote><div><br></div><div>I'm a bit confused=
I'm afraid. bitcoinj already runs SPV wallets on Android on top of Dal=
vik. In fact that's what it's designed for. The NDK is not necessar=
y to work with Bitcoin at any point.</div>
<div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-l=
eft-style:solid;padding-left:1ex"><div style=3D"word-wrap:break-word"><div>=
<div>That's a great idea.</div>
<div>Let me look into the quality of j2c's output.</div></div></div></b=
lockquote><div><br></div><div>There's an example of what it looks like =
here:</div><div><br></div><div><a href=3D"https://code.google.com/a/eclipse=
labs.org/p/j2c/wiki/Examples">https://code.google.com/a/eclipselabs.org/p/j=
2c/wiki/Examples</a><br>
</div><div><br></div><div>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 fi=
gure out how to make it work properly. I'm now fixing bugs in it and ma=
king various improvements along with filling out the native stubs (a.k.a. p=
ortability 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 all=
eys.</div>
<div><br></div><div>The main things be aware of so far are:</div><div><ul><=
li>Lots of explicit null pointer checks are generated. The reason is that t=
he output is meant to be entirely portable, so Jacek doesn't want to re=
ly on platform specific stuff like signals or SEH. Simplest solution is jus=
t to disable npc() generation entirely because normal C++ libraries just se=
gfault if a null pointer gets in the wrong place, they don't throw exce=
ptions. Losing the Java behaviour would not be a downgrade for people used =
to C++.<br>
<br></li><li>Array accesses don't seem to be properly bounds-checked. T=
hat's a part of the Java security model - bitcoinj is written on the as=
sumption that buffer and heap overflows aren't possible because they=
9;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 th=
at needs to be fixed.<br>
<br></li><li>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 wa=
y 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 conve=
rting to various other forms. On Linux you'd have implicit c'tors t=
o go back and forth between std::string, on MacOS X you'd have conversi=
ons for NSString, you could add code for QStrings or raw C strings too. Onc=
e the code has been generated you can extend or patch it to make the API mo=
re convenient.<br>
<br></li><li>Obviously, the resulting code requires the Boehm GC because th=
ere 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 hol=
es.<br>
<br></li><li>The code generator doesn't do dependency tracing, so you e=
nd 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.</li>
</ul><div><br></div></div></div></div></div>
--047d7b33d26a38f0a504e19d8134--
|
