From: <jer...@gm...> - 2005-05-19 13:57:15
|
Hello ! I just found something strange : Following lines work differently on gumstix and my x86 : char c=3D-1; printf("char value : %d\n",(int)c); =20 my gumstix says : char value : 255 =20 my computer says : char value : -1 =20 Doesn't anybody know where does this difference comes from ? =20 Thanks, Jerome =20 here are my compilers versions : ********************* for x86 g++ -v Lecture des sp=E9cification =E0 partir de /usr/lib/gcc-lib/i486-linux/3.3.= 5/specs Configur=E9 avec: ../src/configure -v --enable-languages=3Dc,c++,java,f77,pascal,objc,ada,treelang --prefix=3D/usr --mandir=3D/usr/share/man --infodir=3D/usr/share/info --with-gxx-include-dir=3D/usr/include/c++/3.3 --enable-shared --enable-__cxa_atexit --with-system-zlib --enable-nls --without-included-gettext --enable-clocale=3Dgnu --enable-debug --enable-java-gc=3Dboehm --enable-java-awt=3Dxlib --enable-objc-gc i486-linux Mod=E8le de thread: posix version gcc 3.3.5 (Debian 1:3.3.5-12) ********************* for arm /.../build_arm_nofpu/staging_dir/bin/arm-linux-g++ -v Reading specs from /.../build_arm_nofpu/.../gcc/arm-linux-uclibc/3.4.2/spe= cs Configured with: /.../toolchain_build_arm_nofpu/gcc-3.4.2/configure --prefix=3D/.../build_arm_nofpu/staging_dir --build=3Di386-pc-linux-gnu --host=3Di386-pc-linux-gnu --target=3Darm-linux-uclibc --enable-languages=3Dc,c++ --enable-shared --disable-__cxa_atexit --enable-target-optspace --with-gnu-ld --disable-nls --with-float=3Dsoft --enable-sjlj-exceptions Thread model: posix gcc version 3.4.2 |
From: Kirk M. <km...@ec...> - 2005-05-19 14:26:45
|
255 is -1 as a signed char Kirk At 14:57 19/05/2005, you wrote: >Hello ! > I just found something strange : >Following lines work differently on gumstix and my x86 : > char c=3D-1; > printf("char value : %d\n",(int)c); > > my gumstix says : > char value : 255 > > my computer says : > char value : -1 > > Doesn't anybody know where does this difference comes from ? > > Thanks, >Jerome > > >here are my compilers versions : >********************* for x86 > g++ -v > Lecture des sp=E9cification =E0 partir de=20 > /usr/lib/gcc-lib/i486-linux/3.3.5/specs > Configur=E9 avec: ../src/configure -v >--enable-languages=3Dc,c++,java,f77,pascal,objc,ada,treelang >--prefix=3D/usr --mandir=3D/usr/share/man --infodir=3D/usr/share/info >--with-gxx-include-dir=3D/usr/include/c++/3.3 --enable-shared >--enable-__cxa_atexit --with-system-zlib --enable-nls >--without-included-gettext --enable-clocale=3Dgnu --enable-debug >--enable-java-gc=3Dboehm --enable-java-awt=3Dxlib --enable-objc-gc >i486-linux > Mod=E8le de thread: posix > version gcc 3.3.5 (Debian 1:3.3.5-12) > > ********************* for arm > /.../build_arm_nofpu/staging_dir/bin/arm-linux-g++ -v > Reading specs from= /.../build_arm_nofpu/.../gcc/arm-linux-uclibc/3.4.2/specs > Configured with: /.../toolchain_build_arm_nofpu/gcc-3.4.2/configure >--prefix=3D/.../build_arm_nofpu/staging_dir --build=3Di386-pc-linux-gnu >--host=3Di386-pc-linux-gnu --target=3Darm-linux-uclibc >--enable-languages=3Dc,c++ --enable-shared --disable-__cxa_atexit >--enable-target-optspace --with-gnu-ld --disable-nls --with-float=3Dsoft >--enable-sjlj-exceptions > Thread model: posix > gcc version 3.4.2 > > >------------------------------------------------------- >This SF.Net email is sponsored by Oracle Space Sweepstakes >Want to be the first software developer in space? >Enter now for the Oracle Space Sweepstakes! >http://ads.osdn.com/?ad_idt12&alloc_id344&op=CCk >_______________________________________________ >gumstix-users mailing list >gum...@li... >https://lists.sourceforge.net/lists/listinfo/gumstix-users - http://www.ecs.soton.ac.uk/~km=20 |
From: David I S M. <da...@th...> - 2005-05-19 14:28:54
|
The gumstix is treating the char as unsigned and the x86 is treating it as signed. You made a very typical mistake of coding for cross platforms, that being not specific enough and making an assumption what the compiler is going to do. Either change your declaration line to signed char or unsigned char in both tests and they will be the same. On Thu, 2005-05-19 at 15:57 +0200, Jérôme Multrier wrote: > Hello ! > I just found something strange : > Following lines work differently on gumstix and my x86 : > char c=-1; > printf("char value : %d\n",(int)c); > > my gumstix says : > char value : 255 > > my computer says : > char value : -1 > > Doesn't anybody know where does this difference comes from ? > > Thanks, > Jerome > > > here are my compilers versions : > ********************* for x86 > g++ -v > Lecture des spécification à partir de /usr/lib/gcc-lib/i486-linux/3.3.5/specs > Configuré avec: ../src/configure -v > --enable-languages=c,c++,java,f77,pascal,objc,ada,treelang > --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info > --with-gxx-include-dir=/usr/include/c++/3.3 --enable-shared > --enable-__cxa_atexit --with-system-zlib --enable-nls > --without-included-gettext --enable-clocale=gnu --enable-debug > --enable-java-gc=boehm --enable-java-awt=xlib --enable-objc-gc > i486-linux > Modèle de thread: posix > version gcc 3.3.5 (Debian 1:3.3.5-12) > > ********************* for arm > /.../build_arm_nofpu/staging_dir/bin/arm-linux-g++ -v > Reading specs from /.../build_arm_nofpu/.../gcc/arm-linux-uclibc/3.4.2/specs > Configured with: /.../toolchain_build_arm_nofpu/gcc-3.4.2/configure > --prefix=/.../build_arm_nofpu/staging_dir --build=i386-pc-linux-gnu > --host=i386-pc-linux-gnu --target=arm-linux-uclibc > --enable-languages=c,c++ --enable-shared --disable-__cxa_atexit > --enable-target-optspace --with-gnu-ld --disable-nls --with-float=soft > --enable-sjlj-exceptions > Thread model: posix > gcc version 3.4.2 > > > ------------------------------------------------------- > This SF.Net email is sponsored by Oracle Space Sweepstakes > Want to be the first software developer in space? > Enter now for the Oracle Space Sweepstakes! > http://ads.osdn.com/?ad_idt12&alloc_id344&op=click > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > -- David Mandala <davidm at them dot com> www.them.com/~davidm Public Key id: 45B2D952 Murphy TX, 75094 214.774.2569 HO 972.693.4007 C |
From: Brad M. <bmi...@xm...> - 2005-05-19 14:30:08
|
isn't this the result of a more strict interpretation of char? it was never supposed to be signed by default iirc. Jérôme Multrier wrote: > Hello ! > I just found something strange : > Following lines work differently on gumstix and my x86 : > char c=-1; > printf("char value : %d\n",(int)c); > > my gumstix says : > char value : 255 > > my computer says : > char value : -1 > > Doesn't anybody know where does this difference comes from ? > > Thanks, > Jerome > > > here are my compilers versions : > ********************* for x86 > g++ -v > Lecture des spécification à partir de /usr/lib/gcc-lib/i486-linux/3.3.5/specs > Configuré avec: ../src/configure -v > --enable-languages=c,c++,java,f77,pascal,objc,ada,treelang > --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info > --with-gxx-include-dir=/usr/include/c++/3.3 --enable-shared > --enable-__cxa_atexit --with-system-zlib --enable-nls > --without-included-gettext --enable-clocale=gnu --enable-debug > --enable-java-gc=boehm --enable-java-awt=xlib --enable-objc-gc > i486-linux > Modèle de thread: posix > version gcc 3.3.5 (Debian 1:3.3.5-12) > > ********************* for arm > /.../build_arm_nofpu/staging_dir/bin/arm-linux-g++ -v > Reading specs from /.../build_arm_nofpu/.../gcc/arm-linux-uclibc/3.4.2/specs > Configured with: /.../toolchain_build_arm_nofpu/gcc-3.4.2/configure > --prefix=/.../build_arm_nofpu/staging_dir --build=i386-pc-linux-gnu > --host=i386-pc-linux-gnu --target=arm-linux-uclibc > --enable-languages=c,c++ --enable-shared --disable-__cxa_atexit > --enable-target-optspace --with-gnu-ld --disable-nls --with-float=soft > --enable-sjlj-exceptions > Thread model: posix > gcc version 3.4.2 > > > ------------------------------------------------------- > This SF.Net email is sponsored by Oracle Space Sweepstakes > Want to be the first software developer in space? > Enter now for the Oracle Space Sweepstakes! > http://ads.osdn.com/?ad_idt12&alloc_id344&op=click > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users |
From: Kirk M. <km...@ec...> - 2005-05-19 14:36:32
|
I think it is meant to be signed - its the bane of image processing= students... the gumstix version of GCC must have a naughty printf - was gcc used on the= PC? Kirk At 15:29 19/05/2005, Brad Midgley wrote: >isn't this the result of a more strict interpretation of char? it was=20 >never supposed to be signed by default iirc. > >J=E9r=F4me Multrier wrote: >>Hello ! >> I just found something strange : >>Following lines work differently on gumstix and my x86 : >> char c=3D-1; >> printf("char value : %d\n",(int)c); >> >> my gumstix says : >> char value : 255 >> >> my computer says : >> char value : -1 >> >> Doesn't anybody know where does this difference comes from ? >> >> Thanks, >>Jerome >> >>here are my compilers versions : >>********************* for x86 >> g++ -v >> Lecture des sp=E9cification =E0 partir de=20 >> /usr/lib/gcc-lib/i486-linux/3.3.5/specs >> Configur=E9 avec: ../src/configure -v >>--enable-languages=3Dc,c++,java,f77,pascal,objc,ada,treelang >>--prefix=3D/usr --mandir=3D/usr/share/man --infodir=3D/usr/share/info >>--with-gxx-include-dir=3D/usr/include/c++/3.3 --enable-shared >>--enable-__cxa_atexit --with-system-zlib --enable-nls >>--without-included-gettext --enable-clocale=3Dgnu --enable-debug >>--enable-java-gc=3Dboehm --enable-java-awt=3Dxlib --enable-objc-gc >>i486-linux >> Mod=E8le de thread: posix >> version gcc 3.3.5 (Debian 1:3.3.5-12) >> ********************* for arm >> /.../build_arm_nofpu/staging_dir/bin/arm-linux-g++ -v >> Reading specs from=20 >> /.../build_arm_nofpu/.../gcc/arm-linux-uclibc/3.4.2/specs >> Configured with: /.../toolchain_build_arm_nofpu/gcc-3.4.2/configure >>--prefix=3D/.../build_arm_nofpu/staging_dir --build=3Di386-pc-linux-gnu >>--host=3Di386-pc-linux-gnu --target=3Darm-linux-uclibc >>--enable-languages=3Dc,c++ --enable-shared --disable-__cxa_atexit >>--enable-target-optspace --with-gnu-ld --disable-nls --with-float=3Dsoft >>--enable-sjlj-exceptions >> Thread model: posix >> gcc version 3.4.2 >> >>------------------------------------------------------- >>This SF.Net email is sponsored by Oracle Space Sweepstakes >>Want to be the first software developer in space? >>Enter now for the Oracle Space Sweepstakes! >>http://ads.osdn.com/?ad_idt12&alloc_id344&op=3Dclick >>_______________________________________________ >>gumstix-users mailing list >>gum...@li... >>https://lists.sourceforge.net/lists/listinfo/gumstix-users > > >------------------------------------------------------- >This SF.Net email is sponsored by Oracle Space Sweepstakes >Want to be the first software developer in space? >Enter now for the Oracle Space Sweepstakes! >http://ads.osdn.com/?ad_id=3D7412&alloc_id=3D16344&op=3Dclick >_______________________________________________ >gumstix-users mailing list >gum...@li... >https://lists.sourceforge.net/lists/listinfo/gumstix-users - http://www.ecs.soton.ac.uk/~km=20 |
From: Dave H. <dhy...@gm...> - 2005-05-19 16:39:33
|
Hi guys, On 5/19/05, Kirk Martinez <km...@ec...> wrote: > I think it is meant to be signed - its the bane of image processing stude= nts... > the gumstix version of GCC must have a naughty printf - was gcc used on t= he PC? printf is behaving exactly correctly. The C language specifically leaves the signedness of char up to the the implementor. Some implementations have char as signed, others have it as unsigned. They're both correct. The %d used with printf will attempt to print a signed number. Use %u if you want to print an unsigned number. short is really a modifier for int and short by itself is equivalent to "short int" long is really a modifier for int and long by itself is equivalent to "long= int" short and long make no changes to the signedness of the int. int is signed by definition. Use unsigned short, unsigned long, and unsigned int to get unsigned version= s. double and float are always signed. char is really the only issue. There are 3 types of char's: signed char unsigned char char The last one is compiler dependant and may be either signed or unsigned. --=20 Dave Hylands Vancouver, BC, Canada http://www.DaveHylands.com/ |
From: David I S M. <da...@th...> - 2005-05-19 17:00:15
|
Dave, You make some good points, however as a manager of teams of programmers over the years I've always made the point that one should declare exactly what they expect, even on ints and longs, etc. Not to mention the endian issues, though you don't usually hit them too much unless you are playing with bits and/or binary data uploads. Too many times I've seen people just assume and later pay a big price when porting to a new compiler or new platform, or new CPU family. So for safety, I strongly suggest if signed or unsigned matters in the code, type it in the definition, don't rely on the compiler, depending upon platforms you port to the compiler may not follow the standards, I've seen that many times in the embedded world. Cheers, David On Thu, 2005-05-19 at 09:38 -0700, Dave Hylands wrote: > Hi guys, > > On 5/19/05, Kirk Martinez <km...@ec...> wrote: > > I think it is meant to be signed - its the bane of image processing students... > > the gumstix version of GCC must have a naughty printf - was gcc used on the PC? > > printf is behaving exactly correctly. The C language specifically > leaves the signedness of char up to the the implementor. Some > implementations have char as signed, others have it as unsigned. > They're both correct. > > The %d used with printf will attempt to print a signed number. Use %u > if you want to print an unsigned number. > > short is really a modifier for int and short by itself is equivalent > to "short int" > long is really a modifier for int and long by itself is equivalent to "long int" > > short and long make no changes to the signedness of the int. int is > signed by definition. > > Use unsigned short, unsigned long, and unsigned int to get unsigned versions. > > double and float are always signed. > > char is really the only issue. There are 3 types of char's: > > signed char > unsigned char > char > > The last one is compiler dependant and may be either signed or unsigned. > -- David Mandala <davidm at them dot com> www.them.com/~davidm Public Key id: 45B2D952 Murphy TX, 75094 214.774.2569 HO 972.693.4007 C |
From: Dave H. <dhy...@gm...> - 2005-05-19 17:31:10
|
Hi David, > You make some good points, however as a manager of teams of programmers > over the years I've always made the point that one should declare > exactly what they expect, even on ints and longs, etc. Not to mention > the endian issues, though you don't usually hit them too much unless you > are playing with bits and/or binary data uploads. Actually I prefer not using plain types. If I want sized types then there is a new set of header files included <inttypes.h> which defines types like: int8_t uint8_t int16_t uint16_t int32_t uint32_t For most other things I prefer to create types which have some semantic val= ue: typedef uin16_t DB_RecNum_t; Using a DB_RecNum_t tells you more about the item than just saying its a uin16_t. And by having custom types you can change your definitions much easier. --=20 Dave Hylands Vancouver, BC, Canada http://www.DaveHylands.com/ |
From: David I S M. <da...@th...> - 2005-05-19 18:40:27
|
Dave, I agree with you and do like using things like int8_t uint8_t etc. I very much don't allow anyone on my teams to use things like "typedef uin16_t DB_RecNum_t" since they don't tell you the size of the data unit without finding the typedef that made the data type. At 3 AM in a debugging crush it's way to easy to mess up and not notice that you just truncated a number. That is too much obscurity. Now if they did something like: typedef uint16_t DB_RecNum_uint16_t I'd laugh but allow it. Cheers, David On Thu, 2005-05-19 at 10:31 -0700, Dave Hylands wrote: > Hi David, > > > You make some good points, however as a manager of teams of programmers > > over the years I've always made the point that one should declare > > exactly what they expect, even on ints and longs, etc. Not to mention > > the endian issues, though you don't usually hit them too much unless you > > are playing with bits and/or binary data uploads. > > Actually I prefer not using plain types. If I want sized types then > there is a new set of header files included <inttypes.h> which defines > types like: > > int8_t uint8_t int16_t uint16_t int32_t uint32_t > > For most other things I prefer to create types which have some semantic value: > > typedef uin16_t DB_RecNum_t; > > Using a DB_RecNum_t tells you more about the item than just saying its > a uin16_t. And by having custom types you can change your definitions > much easier. > -- David Mandala <davidm at them dot com> www.them.com/~davidm Public Key id: 45B2D952 Murphy TX, 75094 214.774.2569 HO 972.693.4007 C |
From: Dave H. <dhy...@gm...> - 2005-05-19 22:00:21
|
Hi David, > I very much don't allow anyone on my teams to use things like "typedef > uin16_t DB_RecNum_t" since they don't tell you the size of the data unit > without finding the typedef that made the data type. At 3 AM in a > debugging crush it's way to easy to mess up and not notice that you just > truncated a number. Then we'll have to agree to disagree :) My opinion is that I shouldn't have to know the size, and that it should be easy to change the size on a whim without having to fix a bazillion source files. All constants and stuff that I need to work with a type should be provided. This particular way of doing things has come from many years of C++/object oriented programming (I started programming in C++ in 87). I've also done many years of embedded programming too, and I can appreciate some people wanting to know the exact size of things. As you may of guessed I'm not in favor of the whole hungarian notation thing either :) Incidently, it's been many many years since I've ever done any work-related programming at 3AM. Hmmm. --=20 Dave Hylands Vancouver, BC, Canada http://www.DaveHylands.com/ |
From: Craig H. <cr...@gu...> - 2005-05-20 04:04:50
|
On May 19, 2005, at 10:31 AM, Dave Hylands wrote: > there is a new set of header files included <inttypes.h> which defines > types like: > > int8_t uint8_t int16_t uint16_t int32_t uint32_t Aha! Excellent -- I've been looking for ages for where those are defined! It seems on some platforms that inttypes.h is included from something "standard" like stdio or types.h and on other platforms it's not, which has led to me spending endless hours sticking in stupid things like #ifndef uint32_t #define uint32_t u32; #endif and such, which is a really ugly hack. I knew there was a header somewhere which had what I needed, but fgrep and google for something like uint32_t just leads to no help at all. It's like googling for "breasts" when you want a chicken recipe. C |
From: <jer...@gm...> - 2005-05-19 14:41:53
|
Thank you for your answers ! effectively, the code i'm trying to cross-compil uses chars everywhere :(. So, I think i'll pass my next three days to paste "signed" before every "char" ... Thank you again ! PS : is there the same problem for other types like short,int, long ; double,etc ? 2005/5/19, Brad Midgley <bmi...@xm...>: > isn't this the result of a more strict interpretation of char? it was > never supposed to be signed by default iirc. >=20 > J=E9r=F4me Multrier wrote: > > Hello ! > > I just found something strange : > > Following lines work differently on gumstix and my x86 : > > char c=3D-1; > > printf("char value : %d\n",(int)c); > > > > my gumstix says : > > char value : 255 > > > > my computer says : > > char value : -1 > > > > Doesn't anybody know where does this difference comes from ? > > > > Thanks, > > Jerome > > > > > > here are my compilers versions : > > ********************* for x86 > > g++ -v > > Lecture des sp=E9cification =E0 partir de /usr/lib/gcc-lib/i486-linux/= 3.3.5/specs > > Configur=E9 avec: ../src/configure -v > > --enable-languages=3Dc,c++,java,f77,pascal,objc,ada,treelang > > --prefix=3D/usr --mandir=3D/usr/share/man --infodir=3D/usr/share/info > > --with-gxx-include-dir=3D/usr/include/c++/3.3 --enable-shared > > --enable-__cxa_atexit --with-system-zlib --enable-nls > > --without-included-gettext --enable-clocale=3Dgnu --enable-debug > > --enable-java-gc=3Dboehm --enable-java-awt=3Dxlib --enable-objc-gc > > i486-linux > > Mod=E8le de thread: posix > > version gcc 3.3.5 (Debian 1:3.3.5-12) > > > > ********************* for arm > > /.../build_arm_nofpu/staging_dir/bin/arm-linux-g++ -v > > Reading specs from /.../build_arm_nofpu/.../gcc/arm-linux-uclibc/3.4.2= /specs > > Configured with: /.../toolchain_build_arm_nofpu/gcc-3.4.2/configure > > --prefix=3D/.../build_arm_nofpu/staging_dir --build=3Di386-pc-linux-gnu > > --host=3Di386-pc-linux-gnu --target=3Darm-linux-uclibc > > --enable-languages=3Dc,c++ --enable-shared --disable-__cxa_atexit > > --enable-target-optspace --with-gnu-ld --disable-nls --with-float=3Dsof= t > > --enable-sjlj-exceptions > > Thread model: posix > > gcc version 3.4.2 > > > > > > ------------------------------------------------------- > > This SF.Net email is sponsored by Oracle Space Sweepstakes > > Want to be the first software developer in space? > > Enter now for the Oracle Space Sweepstakes! > > http://ads.osdn.com/?ad_idt12&alloc_id=16344&op=3Dclick > > _______________________________________________ > > gumstix-users mailing list > > gum...@li... > > https://lists.sourceforge.net/lists/listinfo/gumstix-users >=20 > ------------------------------------------------------- > This SF.Net email is sponsored by Oracle Space Sweepstakes > Want to be the first software developer in space? > Enter now for the Oracle Space Sweepstakes! > http://ads.osdn.com/?ad_id=3D7412&alloc_id=3D16344&op=3Dclick > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users >=20 --=20 Jerome |
From: Florian L. <gu...@fl...> - 2005-05-19 14:53:54
|
On Thursday 19 May 2005 16:17, David I S Mandala wrote: > The gumstix is treating the char as unsigned and the x86 is treating it > as signed. You made a very typical mistake of coding for cross > platforms, that being not specific enough and making an assumption what > the compiler is going to do. Either change your declaration line to > signed char or unsigned char in both tests and they will be the same. you could also pass the flag -fsigned-char to your arm-gcc (which is probab= ly=20 easier, than searching through all files). // florian > > On Thu, 2005-05-19 at 15:57 +0200, J=C3=A9r=C3=B4me Multrier wrote: > > Hello ! > > I just found something strange : > > Following lines work differently on gumstix and my x86 : > > char c=3D-1; > > printf("char value : %d\n",(int)c); > > > > my gumstix says : > > char value : 255 > > > > my computer says : > > char value : -1 > > > > Doesn't anybody know where does this difference comes from ? > > > > Thanks, > > Jerome > > > > > > here are my compilers versions : > > ********************* for x86 > > g++ -v > > Lecture des sp=C3=A9cification =C3=A0 partir de > > /usr/lib/gcc-lib/i486-linux/3.3.5/specs Configur=C3=A9 avec: ../src/con= figure > > -v > > --enable-languages=3Dc,c++,java,f77,pascal,objc,ada,treelang > > --prefix=3D/usr --mandir=3D/usr/share/man --infodir=3D/usr/share/info > > --with-gxx-include-dir=3D/usr/include/c++/3.3 --enable-shared > > --enable-__cxa_atexit --with-system-zlib --enable-nls > > --without-included-gettext --enable-clocale=3Dgnu --enable-debug > > --enable-java-gc=3Dboehm --enable-java-awt=3Dxlib --enable-objc-gc > > i486-linux > > Mod=C3=A8le de thread: posix > > version gcc 3.3.5 (Debian 1:3.3.5-12) > > > > ********************* for arm > > /.../build_arm_nofpu/staging_dir/bin/arm-linux-g++ -v > > Reading specs from > > /.../build_arm_nofpu/.../gcc/arm-linux-uclibc/3.4.2/specs Configured > > with: /.../toolchain_build_arm_nofpu/gcc-3.4.2/configure > > --prefix=3D/.../build_arm_nofpu/staging_dir --build=3Di386-pc-linux-gnu > > --host=3Di386-pc-linux-gnu --target=3Darm-linux-uclibc > > --enable-languages=3Dc,c++ --enable-shared --disable-__cxa_atexit > > --enable-target-optspace --with-gnu-ld --disable-nls --with-float=3Dsoft > > --enable-sjlj-exceptions > > Thread model: posix > > gcc version 3.4.2 > > > > > > ------------------------------------------------------- > > This SF.Net email is sponsored by Oracle Space Sweepstakes > > Want to be the first software developer in space? > > Enter now for the Oracle Space Sweepstakes! > > http://ads.osdn.com/?ad_idt12&alloc_id=16344&op=3Dclick > > _______________________________________________ > > gumstix-users mailing list > > gum...@li... > > https://lists.sourceforge.net/lists/listinfo/gumstix-users =2D-=20 This function will terminate, if run infinitely. void f() { while (random() !=3D 0); } |
From: <jer...@gm...> - 2005-05-19 15:11:34
|
Thanks a lot ! -fsigned-char works well for now !!! :) 2005/5/19, Florian Loitsch <gu...@fl...>: >=20 > On Thursday 19 May 2005 16:17, David I S Mandala wrote: > > The gumstix is treating the char as unsigned and the x86 is treating it > > as signed. You made a very typical mistake of coding for cross > > platforms, that being not specific enough and making an assumption what > > the compiler is going to do. Either change your declaration line to > > signed char or unsigned char in both tests and they will be the same. > you could also pass the flag -fsigned-char to your arm-gcc (which is=20 > probably > easier, than searching through all files). > // florian >=20 > > > > On Thu, 2005-05-19 at 15:57 +0200, J=E9r=F4me Multrier wrote: > > > Hello ! > > > I just found something strange : > > > Following lines work differently on gumstix and my x86 : > > > char c=3D-1; > > > printf("char value : %d\n",(int)c); > > > > > > my gumstix says : > > > char value : 255 > > > > > > my computer says : > > > char value : -1 > > > > > > Doesn't anybody know where does this difference comes from ? > > > > > > Thanks, > > > Jerome > > > > > > > > > here are my compilers versions : > > > ********************* for x86 > > > g++ -v > > > Lecture des sp=E9cification =E0 partir de > > > /usr/lib/gcc-lib/i486-linux/3.3.5/specs Configur=E9 avec:=20 > ../src/configure > > > -v > > > --enable-languages=3Dc,c++,java,f77,pascal,objc,ada,treelang > > > --prefix=3D/usr --mandir=3D/usr/share/man --infodir=3D/usr/share/info > > > --with-gxx-include-dir=3D/usr/include/c++/3.3 --enable-shared > > > --enable-__cxa_atexit --with-system-zlib --enable-nls > > > --without-included-gettext --enable-clocale=3Dgnu --enable-debug > > > --enable-java-gc=3Dboehm --enable-java-awt=3Dxlib --enable-objc-gc > > > i486-linux > > > Mod=E8le de thread: posix > > > version gcc 3.3.5 (Debian 1:3.3.5-12) > > > > > > ********************* for arm > > > /.../build_arm_nofpu/staging_dir/bin/arm-linux-g++ -v > > > Reading specs from > > > /.../build_arm_nofpu/.../gcc/arm-linux-uclibc/3.4.2/specs Configured > > > with: /.../toolchain_build_arm_nofpu/gcc-3.4.2/configure > > > --prefix=3D/.../build_arm_nofpu/staging_dir --build=3Di386-pc-linux-g= nu > > > --host=3Di386-pc-linux-gnu --target=3Darm-linux-uclibc > > > --enable-languages=3Dc,c++ --enable-shared --disable-__cxa_atexit > > > --enable-target-optspace --with-gnu-ld --disable-nls --with-float=3Ds= oft > > > --enable-sjlj-exceptions > > > Thread model: posix > > > gcc version 3.4.2 > > > > > > > > > ------------------------------------------------------- > > > This SF.Net <http://SF.Net> email is sponsored by Oracle Space=20 > Sweepstakes > > > Want to be the first software developer in space? > > > Enter now for the Oracle Space Sweepstakes! > > > http://ads.osdn.com/?ad_idt12&alloc_id=16344&op=3Dclick > > > _______________________________________________ > > > gumstix-users mailing list > > > gum...@li... > > > https://lists.sourceforge.net/lists/listinfo/gumstix-users >=20 > -- > This function will terminate, if run infinitely. > void f() { while (random() !=3D 0); } >=20 >=20 > ------------------------------------------------------- > This SF.Net <http://SF.Net> email is sponsored by Oracle Space Sweepstake= s > Want to be the first software developer in space? > Enter now for the Oracle Space Sweepstakes! > http://ads.osdn.com/?ad_idt12&alloc_id=16344&opclick > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users >=20 --=20 Jerome |
From: David I S M. <da...@th...> - 2005-05-19 15:27:35
|
That will work, until someone changes the flag by mistake and suddenly the code is all broken again until someone figures out what they did to break everything. I'd strongly recommend making a note in a README file or something like it so that it's documented that you require the flag. Also it's a single quick sed script with a regex to fix all occurrences of the issue. Less the a half hours work all told. Cheers, David On Thu, 2005-05-19 at 16:53 +0200, Florian Loitsch wrote: > On Thursday 19 May 2005 16:17, David I S Mandala wrote: > > The gumstix is treating the char as unsigned and the x86 is treating it > > as signed. You made a very typical mistake of coding for cross > > platforms, that being not specific enough and making an assumption what > > the compiler is going to do. Either change your declaration line to > > signed char or unsigned char in both tests and they will be the same. > you could also pass the flag -fsigned-char to your arm-gcc (which is probably > easier, than searching through all files). > // florian > > > > > On Thu, 2005-05-19 at 15:57 +0200, Jérôme Multrier wrote: > > > Hello ! > > > I just found something strange : > > > Following lines work differently on gumstix and my x86 : > > > char c=-1; > > > printf("char value : %d\n",(int)c); > > > > > > my gumstix says : > > > char value : 255 > > > > > > my computer says : > > > char value : -1 > > > > > > Doesn't anybody know where does this difference comes from ? > > > > > > Thanks, > > > Jerome > > > > > > > > > here are my compilers versions : > > > ********************* for x86 > > > g++ -v > > > Lecture des spécification à partir de > > > /usr/lib/gcc-lib/i486-linux/3.3.5/specs Configuré avec: ../src/configure > > > -v > > > --enable-languages=c,c++,java,f77,pascal,objc,ada,treelang > > > --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info > > > --with-gxx-include-dir=/usr/include/c++/3.3 --enable-shared > > > --enable-__cxa_atexit --with-system-zlib --enable-nls > > > --without-included-gettext --enable-clocale=gnu --enable-debug > > > --enable-java-gc=boehm --enable-java-awt=xlib --enable-objc-gc > > > i486-linux > > > Modèle de thread: posix > > > version gcc 3.3.5 (Debian 1:3.3.5-12) > > > > > > ********************* for arm > > > /.../build_arm_nofpu/staging_dir/bin/arm-linux-g++ -v > > > Reading specs from > > > /.../build_arm_nofpu/.../gcc/arm-linux-uclibc/3.4.2/specs Configured > > > with: /.../toolchain_build_arm_nofpu/gcc-3.4.2/configure > > > --prefix=/.../build_arm_nofpu/staging_dir --build=i386-pc-linux-gnu > > > --host=i386-pc-linux-gnu --target=arm-linux-uclibc > > > --enable-languages=c,c++ --enable-shared --disable-__cxa_atexit > > > --enable-target-optspace --with-gnu-ld --disable-nls --with-float=soft > > > --enable-sjlj-exceptions > > > Thread model: posix > > > gcc version 3.4.2 > > > > > > > > > ------------------------------------------------------- > > > This SF.Net email is sponsored by Oracle Space Sweepstakes > > > Want to be the first software developer in space? > > > Enter now for the Oracle Space Sweepstakes! > > > http://ads.osdn.com/?ad_idt12&alloc_id344&op=click > > > _______________________________________________ > > > gumstix-users mailing list > > > gum...@li... > > > https://lists.sourceforge.net/lists/listinfo/gumstix-users > -- David Mandala <davidm at them dot com> www.them.com/~davidm Public Key id: 45B2D952 Murphy TX, 75094 214.774.2569 HO 972.693.4007 C |
From: <jer...@gm...> - 2005-05-19 15:35:07
|
OK, I'll tell the programmer to manage this problem in its makefiles and in= =20 its README ! :) 2005/5/19, David I S Mandala <da...@th...>: >=20 > That will work, until someone changes the flag by mistake and suddenly > the code is all broken again until someone figures out what they did to > break everything. >=20 > I'd strongly recommend making a note in a README file or something like > it so that it's documented that you require the flag. >=20 > Also it's a single quick sed script with a regex to fix all occurrences > of the issue. Less the a half hours work all told. >=20 > Cheers, >=20 > David >=20 > On Thu, 2005-05-19 at 16:53 +0200, Florian Loitsch wrote: > > On Thursday 19 May 2005 16:17, David I S Mandala wrote: > > > The gumstix is treating the char as unsigned and the x86 is treating= =20 > it > > > as signed. You made a very typical mistake of coding for cross > > > platforms, that being not specific enough and making an assumption=20 > what > > > the compiler is going to do. Either change your declaration line to > > > signed char or unsigned char in both tests and they will be the same. > > you could also pass the flag -fsigned-char to your arm-gcc (which is=20 > probably > > easier, than searching through all files). > > // florian > > > > > > > > On Thu, 2005-05-19 at 15:57 +0200, J=E9r=F4me Multrier wrote: > > > > Hello ! > > > > I just found something strange : > > > > Following lines work differently on gumstix and my x86 : > > > > char c=3D-1; > > > > printf("char value : %d\n",(int)c); > > > > > > > > my gumstix says : > > > > char value : 255 > > > > > > > > my computer says : > > > > char value : -1 > > > > > > > > Doesn't anybody know where does this difference comes from ? > > > > > > > > Thanks, > > > > Jerome > > > > > > > > > > > > here are my compilers versions : > > > > ********************* for x86 > > > > g++ -v > > > > Lecture des sp=E9cification =E0 partir de > > > > /usr/lib/gcc-lib/i486-linux/3.3.5/specs Configur=E9 avec:=20 > ../src/configure > > > > -v > > > > --enable-languages=3Dc,c++,java,f77,pascal,objc,ada,treelang > > > > --prefix=3D/usr --mandir=3D/usr/share/man --infodir=3D/usr/share/in= fo > > > > --with-gxx-include-dir=3D/usr/include/c++/3.3 --enable-shared > > > > --enable-__cxa_atexit --with-system-zlib --enable-nls > > > > --without-included-gettext --enable-clocale=3Dgnu --enable-debug > > > > --enable-java-gc=3Dboehm --enable-java-awt=3Dxlib --enable-objc-gc > > > > i486-linux > > > > Mod=E8le de thread: posix > > > > version gcc 3.3.5 (Debian 1:3.3.5-12) > > > > > > > > ********************* for arm > > > > /.../build_arm_nofpu/staging_dir/bin/arm-linux-g++ -v > > > > Reading specs from > > > > /.../build_arm_nofpu/.../gcc/arm-linux-uclibc/3.4.2/specs Configure= d > > > > with: /.../toolchain_build_arm_nofpu/gcc-3.4.2/configure > > > > --prefix=3D/.../build_arm_nofpu/staging_dir --build=3Di386-pc-linux= -gnu > > > > --host=3Di386-pc-linux-gnu --target=3Darm-linux-uclibc > > > > --enable-languages=3Dc,c++ --enable-shared --disable-__cxa_atexit > > > > --enable-target-optspace --with-gnu-ld --disable-nls=20 > --with-float=3Dsoft > > > > --enable-sjlj-exceptions > > > > Thread model: posix > > > > gcc version 3.4.2 > > > > > > > > > > > > ------------------------------------------------------- > > > > This SF.Net <http://SF.Net> email is sponsored by Oracle Space=20 > Sweepstakes > > > > Want to be the first software developer in space? > > > > Enter now for the Oracle Space Sweepstakes! > > > > http://ads.osdn.com/?ad_idt12&alloc_id=16344&op=3Dclick > > > > _______________________________________________ > > > > gumstix-users mailing list > > > > gum...@li... > > > > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > > -- > David Mandala <davidm at them dot com> > www.them.com/~davidm <http://www.them.com/~davidm> Public Key id: 45B2D95= 2 > Murphy TX, 75094 214.774.2569 HO 972.693.4007 C >=20 > ------------------------------------------------------- > This SF.Net <http://SF.Net> email is sponsored by Oracle Space Sweepstake= s > Want to be the first software developer in space? > Enter now for the Oracle Space Sweepstakes! > http://ads.osdn.com/?ad_id=3D7412&alloc_id=3D16344&op=3Dclick > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users >=20 --=20 Jerome |
From: Nava W. <N.E...@so...> - 2005-05-19 17:55:46
|
is inttypes.h part of ANSI C? On Thursday 19 May 2005 18:31, Dave Hylands wrote: > Hi David, > > > You make some good points, however as a manager of teams of programmers > > over the years I've always made the point that one should declare > > exactly what they expect, even on ints and longs, etc. Not to mention > > the endian issues, though you don't usually hit them too much unless you > > are playing with bits and/or binary data uploads. > > Actually I prefer not using plain types. If I want sized types then > there is a new set of header files included <inttypes.h> which defines > types like: > > int8_t uint8_t int16_t uint16_t int32_t uint32_t > > For most other things I prefer to create types which have some semantic > value: > > typedef uin16_t DB_RecNum_t; > > Using a DB_RecNum_t tells you more about the item than just saying its > a uin16_t. And by having custom types you can change your definitions > much easier. -- Nava Whiteford Chemistry Department, University of Southampton, SO17 1BJ Office: 02380 594132 Mob: 0796 8647512 |
From: Jonathan B. <jbr...@ea...> - 2005-05-19 18:33:22
|
On Thu, 2005-05-19 at 18:55 +0100, Nava Whiteford wrote: > is inttypes.h part of ANSI C? ISO C99. -Jonathan > > On Thursday 19 May 2005 18:31, Dave Hylands wrote: > > Hi David, > > > > > You make some good points, however as a manager of teams of programmers > > > over the years I've always made the point that one should declare > > > exactly what they expect, even on ints and longs, etc. Not to mention > > > the endian issues, though you don't usually hit them too much unless you > > > are playing with bits and/or binary data uploads. > > > > Actually I prefer not using plain types. If I want sized types then > > there is a new set of header files included <inttypes.h> which defines > > types like: > > > > int8_t uint8_t int16_t uint16_t int32_t uint32_t > > > > For most other things I prefer to create types which have some semantic > > value: > > > > typedef uin16_t DB_RecNum_t; > > > > Using a DB_RecNum_t tells you more about the item than just saying its > > a uin16_t. And by having custom types you can change your definitions > > much easier. > |
From: David I S M. <da...@th...> - 2005-05-19 23:05:40
|
On Thu, 2005-05-19 at 15:00 -0700, Dave Hylands wrote: > Hi David, > > > I very much don't allow anyone on my teams to use things like "typedef > > uin16_t DB_RecNum_t" since they don't tell you the size of the data unit > > without finding the typedef that made the data type. At 3 AM in a > > debugging crush it's way to easy to mess up and not notice that you just > > truncated a number. > > Then we'll have to agree to disagree :) > We can do that, I've been programming since the mid 70's and started in the 8bit world so I may be more sensative to size then most younger programmers. I'm not a fan of C++ for the most part :) too bloated. I'm stuck in the C world for most things, asm for others. Though Idon't use asm much any more at all, I don't think I've used asm in the last 3 years. :-P > My opinion is that I shouldn't have to know the size, and that it > should be easy to change the size on a whim without having to fix a > bazillion source files. All constants and stuff that I need to work > with a type should be provided. This particular way of doing things > has come from many years of C++/object oriented programming (I started > programming in C++ in 87). Yes, I could/can see your point if you are willing to suffer the overhead of C++ most things are hidden from you. But when working with an embedded device where I'm jamming an entire OS and applications in 4 Meg of flash I again start counting size, though no where near as close as I did/do in the 8 bit embedded world. I learned C++ around the same time you did, used it for a bit then dropped it in favor of going back to C. Drove me nuts not knowing what was going on, and far too many bugs cropped up because of things that were hidden and were just supposed to "work" and did not. Yes I know C++ has improved but for me if it's not borken (and C is not) then I'll not fix it. > I've also done many years of embedded programming too, and I can > appreciate some people wanting to know the exact size of things. As > you may of guessed I'm not in favor of the whole hungarian notation > thing either :) Hungarian notation is a pain, helpful sometimes but a pain none the less. The embedded space > > Incidently, it's been many many years since I've ever done any > work-related programming at 3AM. Hmmm. I still get calls at odd times, a customer decides to do something new with a device that it was never meant to do, or they make a big order and say oh we what x done, we quote y time for X and they say OK and then several weeks into change the deadline. You have got to love that little trick. Cheers, David > -- David Mandala <davidm at them dot com> www.them.com/~davidm Public Key id: 45B2D952 Murphy TX, 75094 214.774.2569 HO 972.693.4007 C |
From: Dave H. <dhy...@gm...> - 2005-05-19 23:21:49
|
Hi David, > Yes, I could/can see your point if you are willing to suffer the > overhead of C++ most things are hidden from you.=20 The real secret is understanding exactly what is and isn't hidden from you. Most of the C++ stuff I do in the embedded world has no more overhead than C. I typically use classes for its ability to create abstract data types (i.e. a Motor) and have the functions that operate on it. I use the same philosophies when I'm forced to program in C. Embedded C++ also takes away a whole bunch of stuff (namespaces, templates, exceptions, and multiple inheritance all disappear). I use C++ on my AVR's with 8K of flash :) Admittedly, the C++ doesn't quite look the same as what I use for a full blown GUI app. > Yes I know C++ has improved but for me if it's not > borken (and C is not) then I'll not fix it. That's one of my philosophies too. --=20 Dave Hylands Vancouver, BC, Canada http://www.DaveHylands.com/ |
From: Craig H. <cr...@gu...> - 2005-05-20 04:08:42
|
On May 19, 2005, at 3:00 PM, Dave Hylands wrote: > As > you may of guessed I'm not in favor of the whole hungarian notation > thing either :) Heading a bit OT now, but don't know if y'all saw the discussion on Joel on Software re: apps hungarian vs system hungarian http://www.joelonsoftware.com/articles/Wrong.html C |
From: Dave H. <dhy...@gm...> - 2005-05-20 04:31:46
|
Hi Craig, > Heading a bit OT now, but don't know if y'all saw the discussion on > Joel on Software re: apps hungarian vs system hungarian >=20 > http://www.joelonsoftware.com/articles/Wrong.html That was a very interesting read. The apps hungarion stuff looks useful... :) --=20 Dave Hylands Vancouver, BC, Canada http://www.DaveHylands.com/ |