compile error in whio_amalgamation.c

[Gibbon1]

Hello,

I was trying to build the whio addion on Ubuntu 10.04 LTS and ran into
the following error.

Code is checked out from
http://v8-juice.googlecode.com/svn/convert

whio directory listing

dasfoo@vmub904-mh:~/workspace/JavascriptV8/cvv8/cvv8/addons/whio$ ls -
l
total 1484
-rw-rw-r-- 1 dasfoo tehamadomain 6622 2012-02-13 16:22 bytearray.hpp
-rw-rw-r-- 1 dasfoo tehamadomain 44875 2012-02-12 16:38 cvv8-whio.cpp
-rw-rw-r-- 1 dasfoo tehamadomain 15518 2012-02-12 16:38 cvv8-whio.hpp
-rw-rw-r-- 1 dasfoo tehamadomain 1521 2012-02-12 16:38 Makefile
-rw-rw-r-- 1 dasfoo tehamadomain 8314 2012-02-12 16:38 test.js
-rw-rw-r-- 1 dasfoo tehamadomain 714863 2012-02-12 16:38
whio_amalgamation.c
-rw-rw-r-- 1 dasfoo tehamadomain 38615 2012-02-12 16:38
whio_amalgamation_cpp.cpp
-rw-rw-r-- 1 dasfoo tehamadomain 59119 2012-02-12 16:38
whio_amalgamation_cpp.hpp
-rw-rw-r-- 1 dasfoo tehamadomain 599056 2012-02-12 16:38
whio_amalgamation.h

Error

dasfoo@vmub904-mh:~/workspace/JavascriptV8/cvv8/cvv8/addons/whio$ make
+ cc -pedantic -Wall -Werror -fPIC -ansi -std=c89 -O2 -std=c89 -I/home/
dasfoo/workspace/JavascriptV8/v8-read-only/include -I. -I../../include
-UDEBUG -DNDEBUG=1 -DWHIO_CONFIG_ENABLE_ZLIB=1 -c -o
whio_amalgamation.o whio_amalgamation.c
cc1: warnings being treated as errors
whio_amalgamation.c: In function ‘whio_epfs_handle_open’:
whio_amalgamation.c:18055: error: assuming signed overflow does not
occur when assuming that (X + c) < X is always false
make: *** [whio_amalgamation.o] Error 1
dasfoo@vmub904-mh:~/workspace/JavascriptV8/cvv8/cvv8/addons/whio$

I can probably suppress this error and try to build the code, but this
looks like bug in the source.

[Stephan Beal]

On Tue, Feb 14, 2012 at 3:45 AM, Gibbon1 <das...@gmail.com> wrote:

I was trying to build the whio addion on Ubuntu 10.04 LTS and ran into
the following error.

Hi!

Thanks for the report. Was this on a 32- or 64-bit machine, or something more exotic?

 

I can probably suppress this error and try to build the code, but this
looks like bug in the source.

It certainly needs to be cleaned up, but i haven't seen that one on my machines. i build on 64- and 32-bit intels using whatever gcc is current on those machines (4.5 and 4.6 at the moment).

Which gcc version has 10.04 got?

--
----- stephan beal
http://wanderinghorse.net/home/stephan/

http://gplus.to/sgbeal

[Stephan Beal]

On Tue, Feb 14, 2012 at 3:45 AM, Gibbon1 <das...@gmail.com> wrote:

whio_amalgamation.c:18055: error: assuming signed overflow does not
occur when assuming that (X + c) < X is always false

gcc 4.5 and 4.6 don't trigger this, but the code it's referring to is actually an explicit check for overflow:

if( (origin->inode->openCount+1) < origin->inode->openCount )

{ /* overflow! */

    WHIO_DEBUG("WARNING: continuing would overflow whio_epfs_inode::openCount!\n");

    return whio_rc.RangeError;

}

So i'm hesitant to say it's a bug (and more hesitant to remove the check for overflow). Alternately, maybe my overflow check logic is too naive?

-- 

[Gibbon1]

On Feb 14, 10:48 am, Stephan Beal <sgb...@googlemail.com> wrote:

> On Tue, Feb 14, 2012 at 3:45 AM, Gibbon1 <dasf...@gmail.com> wrote:
> > whio_amalgamation.c:18055: error: assuming signed overflow does not
> > occur when assuming that (X + c) < X is always false
>
> gcc 4.5 and 4.6 don't trigger this, but the code it's referring to is
> actually an explicit check for overflow:
>
> if( (origin->inode->openCount+1) < origin->inode->openCount )
> { /* overflow! */
>     WHIO_DEBUG("WARNING: continuing would overflow
> whio_epfs_inode::openCount!\n");
>     return whio_rc.RangeError;
>
> }
>
> So i'm hesitant to say it's a bug (and more hesitant to remove the check
> for overflow). Alternately, maybe my overflow check logic is too naive?
>

The compiler I'm using is whatever gets installed with Ununtu 486/32
bit. Version info below.

dasfoo@vmub904-mh:~/workspace/JavascriptV8/cvv8/cvv8/addons/whio$ g++ -
v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
4.4.3-4ubuntu5' --with-bugurl=file:///usr/share/doc/gcc-4.4/
README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/
usr --enable-shared --enable-multiarch --enable-linker-build-id --with-
system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-
threads=posix --with-gxx-include-dir=/usr/include/c++/4.4 --program-
suffix=-4.4 --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug
--enable-plugin --enable-objc-gc --enable-targets=all --disable-werror
--with-arch-32=i486 --with-tune=generic --enable-checking=release --
build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu
Thread model: posix
gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5)

Looking further this is odd. openCount is a unit8_t.

However I ran the following test program and found.

#include <stdio.h>
#include <stdint.h>

uint8_t openCount;

int main(void)
{
int i;

openCount = 10;

for(i=0; i<3000; i++){
uint8_t testies = openCount+1;
if(testies < openCount)
break;

openCount++;
}
printf("asexpected(%i)\n", i); // i=245 overflow detected

openCount = 10;

for(i=0; i<3000; i++){
if(openCount+1 < openCount)
break;
openCount++;
}

printf("seriously_wtf(%i)\n", i); // i=3000 overflow not detected
return(0);
}

dasfoo@vmub904-mh:~/workspace/JavascriptV8/cvv8/cvv8/addons/whio$ g++
footest.c
dasfoo@vmub904-mh:~/workspace/JavascriptV8/cvv8/cvv8/addons/whio$ ./
a.out
asexpected(245)
seriously_wtf(3000)

I found that the error occurs on my compiler (gcc version 4.4.3) when
optimized at O2, O3, Os, but not at O1. Perhaps this is fixed on 4.5
and 4.6.

My gut feel is this might be a compiler bug, the uin8_t is being
promoted to a signed int) Since an unsigned int should have defined
overflow behavior. However adding the following cast appears to fix
the issue.

if( (__typeof__(origin->inode->openCount)) (origin->inode-

[Stephan Beal]

On Wed, Feb 15, 2012 at 11:25 PM, Gibbon1 <das...@gmail.com> wrote:

           if( (__typeof__(origin->inode->openCount)) (origin->inode-

i'm not willing to use typeof, because that source is restricted (by project conventions) to ANSI C89, but i can add a cast there which should remove the warning. Unfortunately i don't have immediate access to a machine with a gcc "old" enough to test this, but i've just changed the code to:

if( (uint8_t)(origin->inode->openCount+1) < (uint8_t)origin->inode->openCount )

{ /* overflow! Extra uint8_t casts are to avoid gcc error (in some versions) for the intentional

    overflow check:

    error: assuming signed overflow does not occur when assuming that (X + c) < X is always false

    */

    WHIO_DEBUG("WARNING: continuing would overflow whio_epfs_inode::openCount!\n");

    return whio_rc.RangeError;

}

Hopefully that will work around the error. If you like, i could send you the updated whio_amalgamation.c file for you to try out. i won't be able get it into the cvv8 repository until this weekend (whio is a standalone project which is imported in full into cvv8).

On a related note: user Bionic Badger helped get whio building on msvc 2008+ this week, and those additions will be ported in this weekend.

Thanks again for the bug report, and Happy Hacking!

[Matt Harper]

Stephan,

Thanks, I'm sure that will work.

This also might work. (It's a pain since C doesn't have a portable way
to represent the max and min values for types. such as (maxof() and
minof()

> if( origin->inode->openCount == (uint8_t)( -1))

Also I'm trying to compile V8Convert to ARM. It appears that the make
files search for a compiler to use. I think these are the lines in
common.make that define the tool chain to use. Is this correct?

ShakeNMake.BINS.AR := $(call ShakeNMake.CALL.FIND_BIN,$(AR))
ShakeNMake.BINS.GCC := $(call ShakeNMake.CALL.FIND_BIN,gcc)

Matt

[Stephan Beal]

On Fri, Feb 17, 2012 at 12:07 AM, Matt Harper <mha...@tehamawireless.com> wrote:

>            if( origin->inode->openCount == (uint8_t)( -1))

That's certainly a prettier solution. i'll get that change made the next time i'm in that code.

 

ShakeNMake.BINS.AR := $(call ShakeNMake.CALL.FIND_BIN,$(AR))
ShakeNMake.BINS.GCC := $(call ShakeNMake.CALL.FIND_BIN,gcc)

You can tell it what compiler to use with, e.g.:

make CC=clang CXX=clang

i _think_ that will work (it does in a C tree i just tried it in which uses that same common.make basis).

[Matt Harper]

Stephan!

I tried setting CC and CXX to my compiler and no love. I'll poke
more. Using my hack I was able to compile but then I get this.

MySQL is enabled, so we are NOT building a static library.
make[1]: Entering directory
`/home/dasfoo/workspace/JavascriptV8/cvv8/cvv8/addons/jspdo'
/armdev/G20/factory/build_armv5l-timesys-linux-uclibcgnueabi/toolchain/bin/armv5l-timesys-linux-uclibcgnueabi-gcc
-o js2c js2c.c
./js2c jspdoInitCode < jspdo-init.js > jspdo-init.cpp
/bin/bash: ./js2c: cannot execute binary file

I beleive what is going on is that js2c is a utility program. Which
normally gets compiled then run to do a build task. Problem is here
that it gets cross compiled then the build bombs out when it runs.

I beleive this is sort of reason Python is a pain to cross compile.

Anyways, heads up. I'll look into this.

Matt

[Stephan Beal]

On Fri, Feb 24, 2012 at 10:09 AM, Matt Harper <mha...@tehamawireless.com> wrote:

./js2c jspdoInitCode < jspdo-init.js > jspdo-init.cpp
/bin/bash: ./js2c: cannot execute binary file

I beleive what is going on is that js2c is a utility program.  Which
normally gets compiled then run to do a build task.  Problem is here
that it gets cross compiled then the build bombs out when it runs.

Your analysis is correct: js2c simply creates a C string from JS code. Parts of JSPDO are much easier to implement in JS, so part of the class-binding/setup is to execute the JS code (jspdo-init.js) which gets compiled into the binary at build-time.

i unfortunately can't help much with cross-compilation problems - i have zero experience with cross-compiling. i am of course willing to make portability changes where it helps cross-compilation.

 

Anyways, heads up.  I'll look into this.

i appreciate that - solutions/workarounds are always very welcomed :)

[Stephan Beal]

On Fri, Feb 24, 2012 at 10:50 AM, Stephan Beal <sgb...@googlemail.com> wrote:

On Fri, Feb 24, 2012 at 10:09 AM, Matt Harper <mha...@tehamawireless.com> wrote:

./js2c jspdoInitCode < jspdo-init.js > jspdo-init.cpp
/bin/bash: ./js2c: cannot execute binary file

...

Your analysis is correct: js2c simply creates a C string from JS code. Parts of JSPDO are much easier to implement in JS, so part of the class-binding/setup is to execute the JS code (jspdo-init.js) which gets compiled into the binary at build-time.

Actually, i probably made this specific problem worse recently. Sometime earlier this week i change those rules to:

js2c: js2c.c Makefile

# adding $(MAKEFILE_LIST) as a dep causes a circular dep on .make.c_deps and js2c???

        $(CC) -o $@ js2c.c

jsmin: jsmin.c Makefile

        $(CC) -o $@ jsmin.c

CLEAN_FILES += js2c jsmin

$(EXT.CPP): js2c jsmin $(EXT.JS) $(ALL_MAKEFILES)

        ./jsmin < $(EXT.JS) | ./js2c jspdoInitCode > $@

i.e., there are now two utilities built/run as part of the build process.

[Matt Harper]

Stephan,

> Your analysis is correct: js2c simply creates a C string from JS code. Parts
> of JSPDO are much easier to implement in JS, so part of the
> class-binding/setup is to execute the JS code (jspdo-init.js) which gets
> compiled into the binary at build-time.

Would it be okay to use a python script instead? I'm assuming to
build v8 you need python already so it aught to be installed.

> i unfortunately can't help much with cross-compilation problems - i have
> zero experience with cross-compiling. i am of course willing to make
> portability changes where it helps cross-compilation.

I do mostly embedded stuff so almost everything is cross compiled. In
general with gcc it's exactly the same, just a different tool chain.

I'll try hacking a python script js2c.py and see what happens

Matt

[Matt Harper]

Stephan,

I wrote this little python script (attached) it assumes the data is
text and spits out a string constant. See attached. I read it in
with a test program and spit out the result and did a diff, no
changes. So I think works. I haven't be able to quite test it yet as
I need to rebuild my tool chains to support mysql.

Matt

[Stephan Beal]

On Sat, Feb 25, 2012 at 12:02 AM, Matt Harper <mha...@tehamawireless.com> wrote:

Would it be okay to use a python script instead?  I'm assuming to
build v8 you need python already so it aught to be installed.

i'm not personally a python fan (but admit that i'm in the minority), but for this purpose a python script should be fine. i see you've written one, so i'll get that integrated the first chance i get. Don't worry about diffs vs. mysql - the jspdo code is ignorant of driver-level differences (those are handled by the underlying cpdo C library). i'll answer this thread when i've got your script integrated, but i can promise that it won't be this weekend.

Thanks for the code :).