On 8/12/14 4:20, Chen Gang wrote:
On 08/10/2014 04:22 PM, Chen Gang wrote:
I guess, I find the root cause:
I have given the test, if remove the hardcoded --disable-core-jni from
libjava/configure, we can let JNIDIR enabled.
So I am sure, it must be the root cause.
Thanks.
Although I
On 08/10/2014 04:22 PM, Chen Gang wrote:
I guess, I find the root cause:
Although I say I guess, in fact, I already had related proofs for it.
- When configure libjava/classpath, --disable-core-jni is passed
as parameter explicitly (can check x86_64-.../libjava/classpatch/
config.log
On 8/3/14 13:50, Chen Gang wrote:
Excuse me, after tried, I still did not know hot to build the source
code for x86_64-unknown-linux-gnu/32/libjava/classpath/native/jni.
What I have done is:
- ../gcc/configure --enable-core-jni --enable-languages=c,c++,java
make all-target-libjava
I guess, I find the root cause:
In gcc/libjava/configure, --disable-core-jni is hardcoded manually
for classpath with FIXME, then all related trying are useless. For me,
if have parameter --enable-core-jni, need skip --disable-core-jni.
The related information in gcc/libjava/configure:
6820 #
Excuse me, after tried, I still did not know hot to build the source
code for x86_64-unknown-linux-gnu/32/libjava/classpath/native/jni.
What I have done is:
- ../gcc/configure --enable-core-jni --enable-languages=c,c++,java
make all-target-libjava
- also try ../gcc/configure make, but get
Sorry for no testsuite, I shall send patch v2 for it after finish
related testsuite within this week end (2014-08-03).
And the patch v2 also need cc to java-patc...@gcc.gnu.org
Thanks.
On 07/31/2014 12:59 PM, Chen Gang wrote:
On 07/31/2014 12:10 PM, Jeff Law wrote:
On 07/30/14 09:01,
Hello All:
I shall stop making this kind of patch, next. The reason is that I worry
about what I have done have negative effect to others. And next, I shall
try to send another kinds of patches for gcc when I have time.
Many persons or companies use open source who never give thanks or
Chen == Chen Gang gang.chen.5...@gmail.com writes:
Chen 'errbuf' assumes itself will be zero terminated, and it also assumes
Chen cpnative_getErrorString() may get larger length string than 'errbuf'.
Chen So after strncpy(), 'errbuf' may not be zero terminated.
Chen strncpy() is sure of zero
Chen == Chen Gang gang.chen.5...@gmail.com writes:
Chen I shall stop making this kind of patch, next. The reason is that I worry
Chen about what I have done have negative effect to others. And next, I shall
Chen try to send another kinds of patches for gcc when I have time.
It's customary to
On 07/30/2014 04:01 PM, Chen Gang wrote:
I shall stop making this kind of patch, next. The reason is that I worry
about what I have done have negative effect to others. And next, I shall
try to send another kinds of patches for gcc when I have time.
Many persons or companies use open source
On 07/30/2014 11:24 PM, Tom Tromey wrote:
Chen == Chen Gang gang.chen.5...@gmail.com writes:
Chen I shall stop making this kind of patch, next. The reason is that I worry
Chen about what I have done have negative effect to others. And next, I shall
Chen try to send another kinds of patches
On 07/30/2014 11:32 PM, Andrew Haley wrote:
On 07/30/2014 04:01 PM, Chen Gang wrote:
I shall stop making this kind of patch, next. The reason is that I worry
about what I have done have negative effect to others. And next, I shall
try to send another kinds of patches for gcc when I have time.
On 07/30/14 09:01, Chen Gang wrote:
Hello All:
I shall stop making this kind of patch, next. The reason is that I worry
about what I have done have negative effect to others. And next, I shall
try to send another kinds of patches for gcc when I have time.
Many persons or companies use open
On 07/31/2014 12:10 PM, Jeff Law wrote:
On 07/30/14 09:01, Chen Gang wrote:
Hello All:
I shall stop making this kind of patch, next. The reason is that I worry
about what I have done have negative effect to others. And next, I shall
try to send another kinds of patches for gcc when I have
'errbuf' assumes itself will be zero terminated, and it also assumes
cpnative_getErrorString() may get larger length string than 'errbuf'.
So after strncpy(), 'errbuf' may not be zero terminated.
strncpy() is sure of zero pad, but not be sure of zero terminated.
Signed-off-by: Chen Gang
Hello All:
It is a simple way for finding these kinds of issues (issues may not be
bugs), one sample for 'strncpy' (the same way for sprintf, strcpy,
memcpy ...):
- grep strncpy in all source code.
- and then check each one by one.
- at present, I have finish check about 30% for strncpy.
16 matches
Mail list logo
