From: Ramiro P. <ra...@li...> - 2008-05-01 18:12:28
|
Hello, According to [0], strtod() should be able to parse hexadecimal numbers. But in Windows[1], it doesn't. This simple test program: #include <stdlib.h> #include <stdio.h> int main() { const char *string = "0x00800000"; char *end; double value; value = strtod(string, &end); printf("string \"%s\"\n", string); printf("end \"%s\"\n", end); printf("value %f\n", value); return 0; } should print: string "0x00800000" end "" value 8388608.000000 but instead it prints: string "0x00800000" end "x00800000" value 0.000000 Is it possible that a function to replace strtod() with a C99-compliant implementation be made the same way it was done with snprintf? And then one would have to call _strtod to get the original MSVCRT version. Ramiro Polla [0] http://www.opengroup.org/onlinepubs/000095399/functions/strtod.html [1] http://msdn.microsoft.com/en-us/library/kxsfc1ab(vs.71).aspx |
From: Brian D. <br...@de...> - 2008-05-01 18:22:13
|
Ramiro Polla wrote: > Is it possible that a function to replace strtod() with a C99-compliant > implementation be made the same way it was done with snprintf? And then > one would have to call _strtod to get the original MSVCRT version. This is really the kind of thing that gnulib excels at. You just add the strtod module to your project and you get a working replacement strtod() that is guaranteed standards-compliant, on any of many dozens of platforms, with fallback to the native target's underlying strtod() if it is non-broken. Brian |
From: Charles W. <cwi...@us...> - 2008-05-01 18:55:56
|
Brian Dessent wrote: > Ramiro Polla wrote: > >> Is it possible that a function to replace strtod() with a C99-compliant >> implementation be made the same way it was done with snprintf? And then >> one would have to call _strtod to get the original MSVCRT version. > > This is really the kind of thing that gnulib excels at. You just add > the strtod module to your project and you get a working replacement > strtod() that is guaranteed standards-compliant, on any of many dozens > of platforms, with fallback to the native target's underlying strtod() > if it is non-broken. Only if you're happy with the licensing terms of gnulib, which often are GPL -- or possibly LGPL (the gnulib strtod module is LGPL). Depending on legal advice, sometimes not even LGPL is acceptable (my employer bans the use of LGPL libraries, unless dynamically linked. For gnulib, it's always a static link, so no-go). Mingw(-runtime) provides viral free implementations of (certain) functions in libmingwex, for precisely these reasons. And the purpose of libmingwex itself is to improve C99 compliance of the mingw compile system -- not tell users "go use this [L]GPL module from this other library". Don't get me wrong, I'm a fan of copyleft. But avoiding copyleft seems to be a theme for mingw and the related runtimes, for several good reasons. -- Chuck |
From: Brian D. <br...@de...> - 2008-05-01 19:25:29
|
Charles Wilson wrote: > Only if you're happy with the licensing terms of gnulib, which often are > GPL -- or possibly LGPL (the gnulib strtod module is LGPL). Depending > on legal advice, sometimes not even LGPL is acceptable (my employer bans > the use of LGPL libraries, unless dynamically linked. For gnulib, it's > always a static link, so no-go). > > Mingw(-runtime) provides viral free implementations of (certain) > functions in libmingwex, for precisely these reasons. And the purpose > of libmingwex itself is to improve C99 compliance of the mingw compile > system -- not tell users "go use this [L]GPL module from this other > library". > > Don't get me wrong, I'm a fan of copyleft. But avoiding copyleft seems > to be a theme for mingw and the related runtimes, for several good reasons. Yes, gnulib's strtod is LGPL. Yes, that doesn't jive with every project. But where do you draw the line? There are countless areas where the Microsoft runtime's conformity to standards could be improved. As I understand it the reason for allowing a sprintf replacement was a tradeoff: adding long double support in that one place made it much easier to enable working long double support in gcc and libgfortran. And there was already a precendent for adding code to support long double in the form of libmingwex. Is strtod() really the same tradeoff, or is this going to open the door to rewriting substantial parts of MSVCRT? If the precedent becomes "it's fine to reimplement things in libmingw as long as it's an unrestrictive license and it improves standards conformity" then I don't see how you aren't going to eventually end up with a big bloated library that gets statically linked to every single app, which is really not along the lines of a project that calls itself Minimalistic. On the other hand, you have gnulib, which has a similar philosophy (write replacements that are enabled only on systems where the provided implementations are broken such that users can simply write code that assumes a conformant implementation) but instead of only fixing one function on one platform, you fix numerous functions on countless platforms. And since it's a separate project, people that don't want or need the bloat don't get it. That is why I suggested gnulib, because philosopically it just seems to be a better solution to the problem, modulo issues of licensing and m4-foo. Brian |
From: Ramiro P. <ra...@li...> - 2008-05-01 18:49:54
|
Hello, Brian Dessent wrote: > Ramiro Polla wrote: > >> Is it possible that a function to replace strtod() with a C99-compliant >> implementation be made the same way it was done with snprintf? And then >> one would have to call _strtod to get the original MSVCRT version. > > This is really the kind of thing that gnulib excels at. You just add > the strtod module to your project and you get a working replacement > strtod() that is guaranteed standards-compliant, on any of many dozens > of platforms, with fallback to the native target's underlying strtod() > if it is non-broken. FFmpeg doesn't use autotools, and gnulib seems to have some license implications (GPL might have to be used. I haven't checked though). I think the same reasoning used to implment _mingw_snprintf() should be used for a _mingw_strtod(). And I volunteer to implement it. Ramiro Polla |
From: Ramiro P. <ra...@li...> - 2008-05-01 22:22:48
Attachments:
strtod.mingw.diff
|
Hello, >>> Is it possible that a function to replace strtod() with a C99-compliant >>> implementation be made the same way it was done with snprintf? And then >>> one would have to call _strtod to get the original MSVCRT version. >> This is really the kind of thing that gnulib excels at. You just add >> the strtod module to your project and you get a working replacement >> strtod() that is guaranteed standards-compliant, on any of many dozens >> of platforms, with fallback to the native target's underlying strtod() >> if it is non-broken. > > FFmpeg doesn't use autotools, and gnulib seems to have some license > implications (GPL might have to be used. I haven't checked though). > > I think the same reasoning used to implment _mingw_snprintf() should be > used for a _mingw_strtod(). And I volunteer to implement it. There already is one implementation in libmingwex, it's just not exported. Attached (untested) patch should be alright. Ramiro Polla |
From: Keith M. <kei...@us...> - 2008-05-02 10:39:28
|
On Thursday 01 May 2008 22:22, Ramiro Polla wrote: > There already is one implementation in libmingwex, it's just not > exported. Attached (untested) patch should be alright. Patches posted here will likely be lost; for possible inclusion in the distribution, they need to go to the patch tracker: http://sourceforge.net/tracker/?atid=302435&group_id=2435&func=browse You should also provide a ChangeLog entry, in the format specified by the GNU Coding Standards: http://www.gnu.org/prep/standards/html_node/Change-Logs.html Also, it would be advisable to test your patch before submission, (and better still, attach a minimal test case with the patch). We also need to consider how we document such deviations from standard MSVCRT behaviour. A manpage for the augmented function, included in the patch, would be nice; at the very least, a page on MinGWiki, where we collectively document *all* such enhancements is needed, (in addition to any provided manpages), IMO. Regards, Keith. |
From: Ramiro P. <ra...@li...> - 2008-05-02 17:28:08
|
Keith Marshall wrote: > On Thursday 01 May 2008 22:22, Ramiro Polla wrote: >> There already is one implementation in libmingwex, it's just not >> exported. Attached (untested) patch should be alright. > > Patches posted here will likely be lost; for possible inclusion in the > distribution, they need to go to the patch tracker: > http://sourceforge.net/tracker/?atid=302435&group_id=2435&func=browse > > You should also provide a ChangeLog entry, in the format specified by > the GNU Coding Standards: > http://www.gnu.org/prep/standards/html_node/Change-Logs.html Done. > Also, it would be advisable to test your patch before submission, (and > better still, attach a minimal test case with the patch). Tested. > We also need to consider how we document such deviations from standard > MSVCRT behaviour. A manpage for the augmented function, included in > the patch, would be nice; at the very least, a page on MinGWiki, where > we collectively document *all* such enhancements is needed, (in > addition to any provided manpages), IMO. Maybe something like a README.NON_PORTABLE that pthreads-win32 uses? Ramiro Polla |
From: Keith M. <kei...@us...> - 2008-05-02 21:47:00
|
On Friday 02 May 2008 17:28, Ramiro Polla wrote: > Keith Marshall wrote: > > Patches posted here will likely be lost; for possible inclusion in > > the distribution, they need to go to the patch tracker: > > http://sourceforge.net/tracker/?atid=302435&group_id=2435&func=brow > >se > > > > You should also provide a ChangeLog entry, in the format specified > > by the GNU Coding Standards: > > http://www.gnu.org/prep/standards/html_node/Change-Logs.html > > Done. Thanks. Unless there are any contentious issues, Chris will likely include it in the next release. > > We also need to consider how we document such deviations from > > standard MSVCRT behaviour. A manpage for the augmented function, > > included in the patch, would be nice; at the very least, a page on > > MinGWiki, where we collectively document *all* such enhancements is > > needed, (in addition to any provided manpages), IMO. > > Maybe something like a README.NON_PORTABLE that pthreads-win32 uses? The problem with README files is that few users do. I prefer something the community can peruse, and help to maintain--give them a degree of ownership, and they'll be more likely to use it. The suggestion of a manpage, of course, was rather tongue-in-cheek; it would still be nice though, to give my `man' package some additional fodder--note that I *did* provide manpages for the basename(3) and dirname(3) functions which I added to libmingwex.a, and also for the gencat(1), catopen(3), catgets(3) and catclose(3) components of the catgets library which I recently provided. Regards, Keith. |
From: Chris S. <ir0...@gm...> - 2008-05-03 02:24:08
|
> > > Patches posted here will likely be lost; for possible inclusion in > > > the distribution, they need to go to the patch tracker: > > > http://sourceforge.net/tracker/?atid=302435&group_id=2435&func=brow > > >se > > > > > > You should also provide a ChangeLog entry, in the format specified > > > by the GNU Coding Standards: > > > http://www.gnu.org/prep/standards/html_node/Change-Logs.html > > > > Done. > > Thanks. Unless there are any contentious issues, Chris will likely > include it in the next release. Committed to CVS, will be included in the next release. Cheers! Chris -- Chris Sutcliffe http://emergedesktop.org |
From: Danny S. <dan...@cl...> - 2008-05-04 05:33:49
|
> > Committed to CVS, will be included in the next release. +_CRTIMP double __cdecl __MINGW_NOTHROW _strtod (const char*, char**); Does MSVCRT.dll export this name? MSDN documents strtod and wcstod as ANSI (presumably meaning ISO C90) compliant. Danny |
From: fiveight <fiv...@to...> - 2008-05-05 02:16:23
|
Hi All: First of all, I have to admit that my English is poor. However, I will try my best to explain my problem. Pardon me. I am debugging a win32 program, I want to disassemble a stack frame.If the stack frame has debug info (means have source code), I can use the pc value directly with "disas" command of GDB. This command will dump the function surrounding the program counter of the selected frame. But if the stack frame does not have debug info, using pc value is not safe, because maybe there is no function limits surrounding the pc value(for example, in kernel32.dll). In this condition I can dump a rang address surrounding the pc value. For instance, the pc value is 0x40100, I can disassemble from 0x40000 to 0x40100, and disassemble from 0x40100 to 0x40200. The serious problem is that maybe 0x40000 is not a start of a instruction, because of the instructions of intel x86 can change their length, and in worst condition this will make the instructions from 0x40000 to 0x40100 are all wrong. If I disassemble from code section beginning to pc value, it may take me a long time. How can I get the correct context(disassembly) in this condition rapidly. Thanks. Fiveight |
From: fiveight <fiv...@to...> - 2008-05-13 05:06:07
|
Hi All: I compile "test.cpp" with: gcc -c test.cpp -o test.o and then link with: g++ test.o -o test.exe It works well. But in my firm's project there are too many object files, so I put these object files path in a response file, for example "proj.rsp". Then I link with: g++ -o proj.exe -Wl,@"proj.rsp" This command does not link with libstdc++. If I link with: g++ -o proj.exe -Wl,@"proj.rsp" -lstdc++ It works well. I remember that g++ will automatic link libstdc++. Why does the first command not work? Thanks Fiveight |
From: Dave K. <dav...@ar...> - 2008-05-13 08:41:36
|
fiveight wrote on 13 May 2008 06:06: > But in my firm's project there are too many object files, so I put these > object files path in a response file, for example "proj.rsp". Then I link > with: g++ -o proj.exe -Wl,@"proj.rsp" > This command does not link with libstdc++. > If I link with: > g++ -o proj.exe -Wl,@"proj.rsp" -lstdc++ > It works well. > > I remember that g++ will automatic link libstdc++. Why does the first > command not work? Guessing: compile doesn't add -lstdc++ because you're passing all the .o files straight to the linker (-Wl), so it doesn't know you have any object files at all. Try passing it at least one, or maybe the mingw gcc.exe understands "@" files itself? cheers, DaveK -- Can't think of a witty .sigline today.... |
From: fiveight <fiv...@to...> - 2008-05-13 09:51:03
|
> fiveight wrote on 13 May 2008 06:06: > >> But in my firm's project there are too many object files, so I put these >> object files path in a response file, for example "proj.rsp". Then I link >> with: g++ -o proj.exe -Wl,@"proj.rsp" >> This command does not link with libstdc++. >> If I link with: >> g++ -o proj.exe -Wl,@"proj.rsp" -lstdc++ >> It works well. >> >> I remember that g++ will automatic link libstdc++. Why does the first >> command not work? > > Guessing: compile doesn't add -lstdc++ because you're passing all the .o > files straight to the linker (-Wl), so it doesn't know you have any object Yes, I think so. The g++ doesn't know the object files. > files at all. Try passing it at least one, or maybe the mingw gcc.exe I am afraid that I can not pass g++ one object file, because another program will use the response file too. I must keep the response file integral. > understands "@" files itself? Neither gcc.exe nor g++.exe understand "@" option. So, I am in big trouble! Thank you very mush. |
From: Dave K. <dav...@ar...> - 2008-05-13 13:26:23
|
fiveight wrote on 13 May 2008 10:51: > I am afraid that I can not pass g++ one object file, because another > program will use the response file too. I must keep the response file > integral. > Neither gcc.exe nor g++.exe understand "@" option. > > So, I am in big trouble! Well, or you could just manually add '-lstdc++' to your link lines (or perhaps even to the response file, depending what else uses it - I think ld will be happy with -l options in there) or maybe you could just have a completely empty dummy .o file (try "gcc -c -xc - < /dev/null -o dummy.o" to see what I mean) that you give to g++ but it doesn't get used so it doesn't matter if it's not in the response file? cheers, DaveK -- Can't think of a witty .sigline today.... |
From: fiveight <fiv...@to...> - 2008-05-14 07:00:55
|
Thank you very much, DaveK. I decide to add "-lstdc++" manually with g++.exe. I think g++.exe should automatic link with stdc++ library whether there are object files in command line. Is this a bug? > Well, or you could just manually add '-lstdc++' to your link lines (or > perhaps even to the response file, depending what else uses it - I think ld > will be happy with -l options in there) or maybe you could just have a > completely empty dummy .o file (try "gcc -c -xc - < /dev/null -o dummy.o" to > see what I mean) that you give to g++ but it doesn't get used so it doesn't > matter if it's not in the response file? |
From: Earnie B. <ea...@us...> - 2008-05-14 13:54:41
|
Quoting fiveight <fiv...@to...>: >> Well, or you could just manually add '-lstdc++' to your link lines (or >> perhaps even to the response file, depending what else uses it - I think ld >> will be happy with -l options in there) or maybe you could just have a >> completely empty dummy .o file (try "gcc -c -xc - < /dev/null -o dummy.o" to >> see what I mean) that you give to g++ but it doesn't get used so it doesn't >> matter if it's not in the response file? > > Thank you very much, DaveK. > > I decide to add "-lstdc++" manually with g++.exe. > > I think g++.exe should automatic link with stdc++ library whether > there are object files in command line. Is this a bug? > Please do not TOP POST. Yes it is a bug for g++ not to add the required libraries. Earnie |
From: Keith M. <kei...@us...> - 2008-05-14 20:57:51
|
On Wednesday 14 May 2008 14:54, Earnie Boyd wrote: > Please do not TOP POST. That's the least of his sins; he has also hijacked a totally unrelated thread, to ask his question. This is:-- 1) Incredibly bad manners. 2) Extremely irritating. for those who were following the hijacked thread, and... 3) Grossly stupid, since he has excluded from his potential audience any list member who was not following the original thread, and has chosen to kill it. So... Please DO NOT TOP POST. Please DO NOT HIJACK existing threads, to ask unrelated questions. Regards, Keith. |
From: Dave K. <dav...@ar...> - 2008-05-14 13:59:48
|
fiveight wrote on 14 May 2008 08:01: > Thank you very much, DaveK. > > I decide to add "-lstdc++" manually with g++.exe. > > I think g++.exe should automatic link with stdc++ library whether there > are object files in command line. Is this a bug? Yes, you have rediscovered it, and it's fixed in newer versions: http://gcc.gnu.org/ml/gcc-patches/2004-08/msg00344.html In fact, I've just discovered another solution for you. I tried a few experiments: ~ $ g++ -o proj.exe g++: no input files ~ $ g++ -o proj.exe -Wl,-foo /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../i686-pc-cygwin/bin/ld: -f may not be used without -shared collect2: ld returned 1 exit status So, that shows that the presence of -Wl is indeed the only thing causing the linker to even be invoked. Now, add -v to see the command-line being used: ~ $ g++ -o proj.exe -Wl,-foobar -v Reading specs from /usr/lib/gcc/i686-pc-cygwin/3.4.4/specs Configured with: /managed/gcc-spin-4/gcc-3.4.4-4/configure --verbose --prefix=/usr --exec-prefix=/usr --sysconfdir=/etc --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --enable-languages=c,ada,c++,d,f77,pascal,java,objc --enable-nls --without-included-gettext --enable-version-specific-runtime-libs --without-x --enable-libgcj --disable-java-awt --with-system-zlib --enable-interpreter --disable-libgcj-debug --enable-threads=posix --enable-java-gc=boehm --disable-win32-registry --enable-sjlj-exceptions --enable-hash-synchronization --enable-libstdcxx-debug Thread model: posix gcc version 3.4.4 (cygming special, gdc 0.12, using dmd 0.125) /usr/lib/gcc/i686-pc-cygwin/3.4.4/collect2.exe -Bdynamic --dll-search-prefix=cyg -o proj.exe /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../crt0.o -L/usr/lib/gcc/i686-pc-cygwin/3.4.4 -L/usr/lib/gcc/i686-pc-cygwin/3.4.4 -L/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../.. -foobar -lgcc -lcygwin -luser32 -lkernel32 -ladvapi32 -lshell32 -lgcc /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../i686-pc-cygwin/bin/ld: -f may not be used without -shared collect2: ld returned 1 exit status Notice how it /did/ add the standard C libraries (I'm using a cygwin compiler here, but the principle is the same for mingw, only the list of -l options would be slightly different). So, that made me thing that maybe g++.exe is defaulting to assume a plain old C compilation, because there are no *.cpp or *.cc source files it can see in the command line to tell it otherwise. And in *that* case, maybe we can use the -x option that specifies the default input langauage: ~ $ g++ -o proj.exe -Wl,-foobar -v -x c++ Reading specs from /usr/lib/gcc/i686-pc-cygwin/3.4.4/specs Configured with: /managed/gcc-spin-4/gcc-3.4.4-4/configure --verbose --prefix=/usr --exec-prefix=/usr --sysconfdir=/etc --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --enable-languages=c,ada,c++,d,f77,pascal,java,objc --enable-nls --without-included-gettext --enable-version-specific-runtime-libs --without-x --enable-libgcj --disable-java-awt --with-system-zlib --enable-interpreter --disable-libgcj-debug --enable-threads=posix --enable-java-gc=boehm --disable-win32-registry --enable-sjlj-exceptions --enable-hash-synchronization --enable-libstdcxx-debug Thread model: posix gcc version 3.4.4 (cygming special, gdc 0.12, using dmd 0.125) /usr/lib/gcc/i686-pc-cygwin/3.4.4/collect2.exe -Bdynamic --dll-search-prefix=cyg -o proj.exe /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../crt0.o -L/usr/lib/gcc/i686-pc-cygwin/3.4.4 -L/usr/lib/gcc/i686-pc-cygwin/3.4.4 -L/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../.. -foobar -lstdc++ -lgcc -lcygwin -luser32 -lkernel32 -ladvapi32 -lshell32 -lgcc /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../i686-pc-cygwin/bin/ld: -f may not be used without -shared collect2: ld returned 1 exit status And look! We got our lstdc++! So, you could add "-x c++" to your command line. That's a bit better than adding -lstdc++ manually because it will always "do the right thing", in the face of perhaps different multilib or static-vs-shared versions of the library, and it will also take care of any other options apart from -lstdc++ that might be required when linking c++ executables. I've also tried this with a more recent (4.3.0) gcc build I had lying around, and with that version, using g++ instead of gcc /does/ make it add -lstdc++. cheers, DaveK -- Can't think of a witty .sigline today.... |
From: fiveight <fiv...@to...> - 2008-05-15 00:59:11
|
Hi All: I'm using gdb/mi(MinGW) to debug my program.In my program,.There is a file named "a b.c"(there is a space between character 'a' and 'b').I want to insert a breakpoint in line 5 of this file. But when I enter command: -break-insert a b.c:5 the output is: &"mi_cmd_break_insert: Garbage following <location>\n" ^error,msg="mi_cmd_break_insert: Garbage following <location>" enter command: -break-insert "a b.c:5" the output is: &"Function \"a\" not defined in loaded symbols.\n" ^error,msg="Function \"a\" not defined in loaded symbols." How can I use -break-insert command with a file which name contains space? Thanks Fiveight |
From: Eran I. <era...@gm...> - 2008-05-15 01:17:54
|
You cant, the GDB MI does not allow using names with spaces inside them - even when you enclose them with double quotes. Only "break" command does. Eran On Thu, May 15, 2008 at 3:59 AM, fiveight <fiv...@to...> wrote: > Hi All: > > I'm using gdb/mi(MinGW) to debug my program.In my program,.There is a file > named "a b.c"(there is a space between character 'a' and 'b').I want to > insert a breakpoint in line 5 of this file. But when I enter command: > > -break-insert a b.c:5 > > the output is: > > &"mi_cmd_break_insert: Garbage following <location>\n" > ^error,msg="mi_cmd_break_insert: Garbage following <location>" > > enter command: > > -break-insert "a b.c:5" > > the output is: > > &"Function \"a\" not defined in loaded symbols.\n" > ^error,msg="Function \"a\" not defined in loaded symbols." > > How can I use -break-insert command with a file which name contains space? > > Thanks > Fiveight > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > MinGW-users mailing list > Min...@li... > > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users > -- Eran Ifrah era...@gm... |
From: Fiveight <fiv...@to...> - 2008-05-15 14:59:19
|
I have tried your method, it works perfect.This method is better than manually add stdc++ library indeed. Thank you very much and your time. BYW, I am using GCC 3.4.5. Fiveight |
From: Ramiro P. <ra...@li...> - 2008-05-06 01:52:15
|
Hello, Danny Smith wrote: >> Committed to CVS, will be included in the next release. > > +_CRTIMP double __cdecl __MINGW_NOTHROW _strtod (const char*, char**); > > Does MSVCRT.dll export this name? No, it doesn't. I reopened the issue on the patch tracker and sent a new patch to reflect this. > MSDN documents strtod and wcstod as ANSI (presumably > meaning ISO C90) compliant. With the patch I sent, you can see the difference: ramiro@FOUND /usrc/smalls $ cat strtod.c #include <stdlib.h> #include <stdio.h> int main() { char *string = "0x00000001"; char *end; double d; d = strtod(string, &end); printf("end %s\n", end); printf("%f\n", d); return 0; } ramiro@FOUND /usrc/smalls $ gcc -o strtod.exe strtod.c ramiro@FOUND /usrc/smalls $ ./strtod.exe end 1.000000 ramiro@FOUND /usrc/smalls $ gcc -D__NO_ISOCEXT -o strtod.exe strtod.c ramiro@FOUND /usrc/smalls $ ./strtod.exe end x00000001 0.000000 Sorry for yet another wrong patch (I should be more careful). Ramiro Polla |
From: Fiveight <fiv...@to...> - 2008-05-15 14:58:50
|
I am sorry for posting my mail on the TOP. I am using Outlook Express, there is no thread in mail list in Outlook Express, so I did not notice my mistake. I think if you can teach me how to use OE to avoid this mistake, I will really appreciate your help.And that will save your time from typing these trash words, like "sins, hijack, bad manner, irritating, stupid", and so on, because I am a Chinese, my English is very poor, I can not understand these words. BTW, if you can translate these trash words into Chinese, maybe we can talk better. Fiveight |