Re: [sqlite] Compiler warnings in R-Tree code under Visual StudioExpress
On Sat, 19 Feb 2011 10:37:42 -0500, Afriza N. Arief afriza...@gmail.com wrote: On Sat, Feb 19, 2011 at 6:27 AM, Samuel Adam a...@certifound.com wrote: A FAQ[2] isn’t enough, as we can see. To put it another way: Bug reporters should have probable cause before they bug others. A compiler warning is only a reasonable articulable suspicion. Note that “probable cause” doesn’t imply computer expertise; “it crashes” is probable cause. But a compiler warning only means that a dumb piece of melted sand (i.e., a computer) running a static analysis suggested there might be perhaps something wrong with it, maybe. Not that any actual misbehavior was observed. Relying on a compiler warning means abdicating wetware to kneel in thrall at the feet of silicon dioxide. It’s wrong and it’s stupid. N.b., I am not accusing hereby Mr. Black of so relying; I just happened to reply to his message, because the uninitialized-memory trick seemed apropos of his message and I think he as a C coder would duly appreciate the argument (whether or not he agrees). But the original poster, Mr. Arief, posted an apparent copy-and-paste of such warnings with aught other said but a helpful link to where we can download MSVC Express. It happens here every few months; I am sick of it, ten thousand other list readers are probably sick of it, and it peeves the SQLite team sufficiently that they have a FAQ[2,idem] on the topic. [snip] Now, I actually did read Testing Process Page[3] a few months back when I first knew about SQLite but unfortunately it was not carved into my brain since I didn't face any warning when compiling SQLite at that time. I have googled the warning I found and search the mailing list but did not find satisfying result. During my short time searching, I only found the FAQ[2] which again, I think should be revised to refer to Testing Process Page[3]. Did I mention that I actually read a bit of the code around the warning and thought of a way to fix it? Nah, I believe I haven't mention it. I gave up because I afraid my fix would actually introduce bugs. And unfortunately I didn't find/read Testing Process Page[3] during my recent search. Thank you, Afriza N. Arief Since you say you checked the sources and found something you thought might merit a change, I suggest that you post your suggested fix so someone who knows the R-Tree module insides can advise of whether it will help or hurt. Since your original post was even helpful enough to provide a link to where people could download MSVC++ Express to reproduce the warnings, and you say you had already read the FAQ on compiler warnings, may I ask why you made no mention thereby of what you had already found reading the source? SQLite bugs are relatively rare; speaking to experience, the last time I reported one on-list, I was promptly shown it had already been found and fixed in trunk. So if you found a bug, I advise you should not hesitate to stomp on it. Very truly, Samuel Adam ◊ http://certifound.com/ 763 Montgomery Road ◊ Hillsborough, NJ 08844-1304 ◊ United States Legal advice from a non-lawyer: “If you are sued, don’t do what the Supreme Court of New Jersey, its agents, and its officers did.” http://www.youtube.com/watch?v=iT2hEwBfU1g ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Compiler warnings in R-Tree code under Visual StudioExpress
Just 30 years of developing C code and too-many-to-count projects where we always had a goal of zero-warnings no matter what switch you used. It's really hard (as the SQLite guys can attest I'm sure) to make a cross-platform system. We use each compiler's capabilities as they are all different. If you're implying that the opposite of working and no warnings is not working and warnings that's not correct. The reference in the FAQ to testing is a straw-man argument against correcting warnings. So far the only real reason I've heard is it could introduce a bug which to me is a lazy way out. I'm not asking that some hundreds of hours be spent to fix warnings...I'd be surprised if it took more than a few hours from what I've seen. If the SQLite people really think the MSVC warnings are completely useless than put in the pragmas to disable them.,,,just like what's been done for Borland in sqlite3.c (and everybody uses Borland, right?) #if defined(_MSC_VER) #pragma warning(disable:4127) /* conditional expression is constant */ #pragma warning(disable:4132) /* const object should be initialized */ #pragma warning(disable:4244) /* conversion from 'int' to 'u16' */ #pragma warning(disable:4668) /* not defined as a preprocessor macro */ #pragma warning(disable:4820) /* bytes padding added after data member */ #endif I recently had to do a 64-bit port of some scientific code that had over 125,000 lines. Wanna' guess how I proceeded? Cranked up the warnings gradually and found tons of problems (even exisitng bugs they didn't know about). There was no way I could've hand-reviewed 125,000 lines in the allotted time. I did introduce one bug at one time but that was my own mistake not related directly to the warnings (I was trying to clarify the flow of one section) and, of course, got discovered immediately during testing. Now...when doing scientific code things like double to float demotions are most certainly dangerous. I was able to clear up every warning and in the process reviewed a large sample of the code (basically a random sample). Michael D. Black Senior Scientist NG Information Systems Advanced Analytics Directorate From: sqlite-users-boun...@sqlite.org [sqlite-users-boun...@sqlite.org] on behalf of Roger Binns [rog...@rogerbinns.com] Sent: Friday, February 18, 2011 7:45 PM To: General Discussion of SQLite Database Subject: Re: [sqlite] EXT :Re: Compiler warnings in R-Tree code under Visual StudioExpress -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/18/2011 06:32 AM, Black, Michael (IS) wrote: You can actually have both you know, working and no warnings...I do it all the time. And what evidence do you have it actually works? This is what the SQLite team has: http://www.sqlite.org/testing.html Roger -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1fILIACgkQmOOfHg372QR5bgCfWAnrGbqJfzNowomv3qdUC9VS y+4AnRHszeAS5Sx2kpxYvruV9uv77Fm+ =sy8h -END PGP SIGNATURE- ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Compiler warnings in R-Tree code under Visual StudioExpress
On Sat, Feb 19, 2011 at 6:27 AM, Samuel Adam a...@certifound.com wrote: A FAQ[2] isn’t enough, as we can see. To put it another way: Bug reporters should have probable cause before they bug others. A compiler warning is only a reasonable articulable suspicion. Note that “probable cause” doesn’t imply computer expertise; “it crashes” is probable cause. But a compiler warning only means that a dumb piece of melted sand (i.e., a computer) running a static analysis suggested there might be perhaps something wrong with it, maybe. Not that any actual misbehavior was observed. Relying on a compiler warning means abdicating wetware to kneel in thrall at the feet of silicon dioxide. It’s wrong and it’s stupid. N.b., I am not accusing hereby Mr. Black of so relying; I just happened to reply to his message, because the uninitialized-memory trick seemed apropos of his message and I think he as a C coder would duly appreciate the argument (whether or not he agrees). But the original poster, Mr. Arief, posted an apparent copy-and-paste of such warnings with aught other said but a helpful link to where we can download MSVC Express. It happens here every few months; I am sick of it, ten thousand other list readers are probably sick of it, and it peeves the SQLite team sufficiently that they have a FAQ[2,idem] on the topic. Please forgive me from being a beginner and I am really sorry if I peeve SQLite team and list readers. But then, I think the FAQ[2] really needs to be updated because my original post was motivated by the following sentence: Compiler warnings only arise from compilers that the developers do not have access to. The above sentence should probably be removed and replaced with For more information, please refer to our testing process[3] linked to the corresponding web page[3]. [snip] If you're going to decide to ignore it then put a comment in the code that says don't bother to use options X/Y/Z to look for warnings...we have chosen to ignore them. Much as I regularly take issue with other items therein, when both the FAQ[2,idem] and another document thereby referenced[3] explain SQLite’s position on compiler warnings, it is futile to expect that somebody who missed that would read a source code comment. Did I mention the FAQ[2,supra]? Very truly, Now, I actually did read Testing Process Page[3] a few months back when I first knew about SQLite but unfortunately it was not carved into my brain since I didn't face any warning when compiling SQLite at that time. I have googled the warning I found and search the mailing list but did not find satisfying result. During my short time searching, I only found the FAQ[2] which again, I think should be revised to refer to Testing Process Page[3]. Did I mention that I actually read a bit of the code around the warning and thought of a way to fix it? Nah, I believe I haven't mention it. I gave up because I afraid my fix would actually introduce bugs. And unfortunately I didn't find/read Testing Process Page[3] during my recent search. Thank you, Afriza N. Arief [1] http://www.mail-archive.com/sqlite-users@sqlite.org/msg56813.html [2] http://www.sqlite.org/faq.html#q17 [3] http://www.sqlite.org/testing.html#staticanalysis ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Compiler warnings in R-Tree code under Visual StudioExpress
Afriza N. Arief wrote: I tried to compile SQLite 3.7.5 with SQLITE_ENABLE_RTREE=1 and got the following warnings: sqlite3.c(120736): warning C4244: '=' : conversion from 'double' to 'float', possible loss of data sqlite3.c(120749): warning C4244: '+=' : conversion from 'double' to 'float', possible loss of data sqlite3.c(120834): warning C4244: '=' : conversion from 'double' to 'float', possible loss of data sqlite3.c(121803): warning C4244: '+=' : conversion from 'double' to 'float', possible loss of data sqlite3.c(121804): warning C4244: '+=' : conversion from 'double' to 'float', possible loss of data sqlite3.c(121808): warning C4244: '=' : conversion from 'double' to 'float', possible loss of data sqlite3.c(121815): warning C4244: 'initializing' : conversion from 'double' to 'float', possible loss of data sqlite3.c(121914): warning C4244: 'function' : conversion from 'i64' to 'int', possible loss of data sqlite3.c(121917): warning C4244: 'function' : conversion from 'i64' to 'int', possible loss of data Thank you Those are warnings, not errors, so won't prevent the build completing - You can hide the warnings with a compiler pragma: #pragma warning (disable: 4244), or you could edit the code itself and cast the doubles explicitly as floats. I don't think they're anything to be concerned about. If I compile the code in my project (without SQLITE_ENABLE_RTREE I should note) with Level 4 warnings on the file properties in Visual Studio, I get a ream of warnings, but they've yet to cause any problems at all (hence I compile with Level 3 warnings so I don't keep seeing them). Nick. ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Compiler warnings in R-Tree code under Visual StudioExpress
I'm of the opinion that all such warnings should be permanently fixed. Such warnings do point to potential problems. And not by disabling the warning but by fixing the code (explicit casts for example). How many people try this and get worried about possible problems? If you simply fix the code once all those people will feel a whole lot better when they crank up the warnings and see nothing. I went through this exercise myself for SQLite at one point and looked at each and every warning to try and determine if there was a possible error caused by all the miscasts. I don't understand the resistance to fixing these. And I'd feel a whole lot better with somebody who KNOWS the code saying yeah, explicit cast is OK here. Michael D. Black Senior Scientist NG Information Systems Advanced Analytics Directorate From: sqlite-users-boun...@sqlite.org [sqlite-users-boun...@sqlite.org] on behalf of Nick Shaw [nick.s...@citysync.co.uk] Sent: Friday, February 18, 2011 3:50 AM To: General Discussion of SQLite Database Subject: EXT :Re: [sqlite] Compiler warnings in R-Tree code under Visual StudioExpress Afriza N. Arief wrote: I tried to compile SQLite 3.7.5 with SQLITE_ENABLE_RTREE=1 and got the following warnings: sqlite3.c(120736): warning C4244: '=' : conversion from 'double' to 'float', possible loss of data sqlite3.c(120749): warning C4244: '+=' : conversion from 'double' to 'float', possible loss of data sqlite3.c(120834): warning C4244: '=' : conversion from 'double' to 'float', possible loss of data sqlite3.c(121803): warning C4244: '+=' : conversion from 'double' to 'float', possible loss of data sqlite3.c(121804): warning C4244: '+=' : conversion from 'double' to 'float', possible loss of data sqlite3.c(121808): warning C4244: '=' : conversion from 'double' to 'float', possible loss of data sqlite3.c(121815): warning C4244: 'initializing' : conversion from 'double' to 'float', possible loss of data sqlite3.c(121914): warning C4244: 'function' : conversion from 'i64' to 'int', possible loss of data sqlite3.c(121917): warning C4244: 'function' : conversion from 'i64' to 'int', possible loss of data Thank you Those are warnings, not errors, so won't prevent the build completing - You can hide the warnings with a compiler pragma: #pragma warning (disable: 4244), or you could edit the code itself and cast the doubles explicitly as floats. I don't think they're anything to be concerned about. If I compile the code in my project (without SQLITE_ENABLE_RTREE I should note) with Level 4 warnings on the file properties in Visual Studio, I get a ream of warnings, but they've yet to cause any problems at all (hence I compile with Level 3 warnings so I don't keep seeing them). Nick. ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Compiler warnings in R-Tree code under Visual StudioExpress
On Fri, Feb 18, 2011 at 8:12 AM, Black, Michael (IS) michael.bla...@ngc.com wrote: I'm of the opinion that all such warnings should be permanently fixed. Such warnings do point to potential problems. And not by disabling the warning but by fixing the code (explicit casts for example). How many people try this and get worried about possible problems? If you simply fix the code once all those people will feel a whole lot better when they crank up the warnings and see nothing. I went through this exercise myself for SQLite at one point and looked at each and every warning to try and determine if there was a possible error caused by all the miscasts. I don't understand the resistance to fixing these. And I'd feel a whole lot better with somebody who KNOWS the code saying yeah, explicit cast is OK here. I do not recall an occasion where a compiler warning has helped us find an error in a released version of SQLite. However, we have introduced errors in our efforts to fix compiler warnings. Thus, in my experience, excessive worry over compiler warnings is counter-productive to software quality. This is especially true of the warnings generated by MSVC. So, which do you prefer: Software that compiles without warning, or software that works? Michael D. Black Senior Scientist NG Information Systems Advanced Analytics Directorate From: sqlite-users-boun...@sqlite.org [sqlite-users-boun...@sqlite.org] on behalf of Nick Shaw [nick.s...@citysync.co.uk] Sent: Friday, February 18, 2011 3:50 AM To: General Discussion of SQLite Database Subject: EXT :Re: [sqlite] Compiler warnings in R-Tree code under Visual StudioExpress Afriza N. Arief wrote: I tried to compile SQLite 3.7.5 with SQLITE_ENABLE_RTREE=1 and got the following warnings: sqlite3.c(120736): warning C4244: '=' : conversion from 'double' to 'float', possible loss of data sqlite3.c(120749): warning C4244: '+=' : conversion from 'double' to 'float', possible loss of data sqlite3.c(120834): warning C4244: '=' : conversion from 'double' to 'float', possible loss of data sqlite3.c(121803): warning C4244: '+=' : conversion from 'double' to 'float', possible loss of data sqlite3.c(121804): warning C4244: '+=' : conversion from 'double' to 'float', possible loss of data sqlite3.c(121808): warning C4244: '=' : conversion from 'double' to 'float', possible loss of data sqlite3.c(121815): warning C4244: 'initializing' : conversion from 'double' to 'float', possible loss of data sqlite3.c(121914): warning C4244: 'function' : conversion from 'i64' to 'int', possible loss of data sqlite3.c(121917): warning C4244: 'function' : conversion from 'i64' to 'int', possible loss of data Thank you Those are warnings, not errors, so won't prevent the build completing - You can hide the warnings with a compiler pragma: #pragma warning (disable: 4244), or you could edit the code itself and cast the doubles explicitly as floats. I don't think they're anything to be concerned about. If I compile the code in my project (without SQLITE_ENABLE_RTREE I should note) with Level 4 warnings on the file properties in Visual Studio, I get a ream of warnings, but they've yet to cause any problems at all (hence I compile with Level 3 warnings so I don't keep seeing them). Nick. ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users -- D. Richard Hipp d...@sqlite.org ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Compiler warnings in R-Tree code under Visual StudioExpress
On 18 Feb 2011, at 13:12, Black, Michael (IS) wrote: I'm of the opinion that all such warnings should be permanently fixed. Such warnings do point to potential problems. And not by disabling the warning but by fixing the code (explicit casts for example). It's been a while since I last did multiplatform C development, but in 2005 I found that MSVC and the HP-UX compiler were always brilliant at pointing out 'problems' which almost never mattered while missing severe (crash-causing) issues which were found by IBM's xlc, GNU GCC and clang. How many people try this and get worried about possible problems? If you simply fix the code once all those people will feel a whole lot better when they crank up the warnings and see nothing. There are plenty of cases which cause a warning from one compiler but if 'fixed' in the obvious way will cause another warning from a different compiler: it becomes a case of whose warnings you want to get rid of. I went through this exercise myself for SQLite at one point and looked at each and every warning to try and determine if there was a possible error caused by all the miscasts. Adding casts to get rid of warnings is usually the wrong answer in my experience. Certainly you should never cast the return value of a function call because that hides the problems you get when it's implicitly returning int because a required header is missing. I used to see a lot of C code (usually from Windows programmers - does MSVC encourage this?) which has stuff like this all over the place: struct something *fred = (struct something *)malloc(sizeof(struct something)); Casting the return from malloc is never necessary - void * is assignable to any non-function pointer type by definition. It becomes an extremely bad idea when you're building on a platform with 64-bit pointers and a 32-bit int (such as everything I use) and you have the optimiser turned on – in this case if stdlib.h isn't included none of your allocations will work properly and your program will crash. Best Regards, Phil Willoughby -- Managing Director, StrawberryCat Limited StrawberryCat Limited is registered in England and Wales with Company No. 7234809. The registered office address of StrawberryCat Limited is: 107 Morgan Le Fay Drive Eastleigh SO53 4JH ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Compiler warnings in R-Tree code under Visual StudioExpress
On 18 févr. 2011, at 15:12, Philip Graham Willoughby wrote: Adding casts to get rid of warnings is usually the wrong answer in my experience. Certainly you should never cast the return value of a function call because that hides the problems you get when it's implicitly returning int because a required header is missing. I used to see a lot of C code (usually from Windows programmers - does MSVC encourage this?) which has stuff like this all over the place: struct something *fred = (struct something *)malloc(sizeof(struct something)); Casting the return from malloc is never necessary - void * is assignable to any non-function pointer type by definition. It becomes an extremely bad idea when you're building on a platform with 64-bit pointers and a 32-bit int (such as everything I use) and you have the optimiser turned on – in this case if stdlib.h isn't included none of your allocations will work properly and your program will crash. Best Regards, Phil Willoughby -- My pure C must be rusted. Could you please elaborate why this line breaks with 64-bit pointers and 32-bit ints? fred is a 64 bit pointer of type struct something * malloc returns a 64 bit pointer of type void * casting that pointer to struct something * makes it a 64-bit pointer of type struct something *, which is then assigned to fred. I can't see how 64-bitness of pointers can hurt. Similarly, malloc takes one argument of type size_t. On such a platform size_t is probably defined as long (or long long), but that is irrelevant, because the sizeof intrinsic is defined as returning a size_t as well. Now even if size_t is defined as int, this would only have an impact for structs larger than 2^31 bytes, which are few are far between, and that impact would be unrelated to the typecast. I can't see how 32-bitness of ints can hurt. What did I miss? JD ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Compiler warnings in R-Tree code under Visual StudioExpress
On 18 Feb 2011, at 14:25, Jean-Denis Muys wrote: On 18 févr. 2011, at 15:12, Philip Graham Willoughby wrote: Adding casts to get rid of warnings is usually the wrong answer in my experience. Certainly you should never cast the return value of a function call because that hides the problems you get when it's implicitly returning int because a required header is missing. I used to see a lot of C code (usually from Windows programmers - does MSVC encourage this?) which has stuff like this all over the place: struct something *fred = (struct something *)malloc(sizeof(struct something)); Casting the return from malloc is never necessary - void * is assignable to any non-function pointer type by definition. It becomes an extremely bad idea when you're building on a platform with 64-bit pointers and a 32-bit int (such as everything I use) and you have the optimiser turned on – in this case if stdlib.h isn't included none of your allocations will work properly and your program will crash. Best Regards, Phil Willoughby -- My pure C must be rusted. Could you please elaborate why this line breaks with 64-bit pointers and 32-bit ints? Sure. fred is a 64 bit pointer of type struct something * Yes. malloc returns a 64 bit pointer of type void * No, from the caller's point of view it returns an int if you haven't included stdlib.h. When this 32-bit signed integer is cast to a 64-bit struct something * sometimes with some compilers/options you get away with it but more often you get a pointer with the high 32-bits zeroed and the low 32-bits whatever malloc allocated for you. Worst case for this is a platform with 64-bit pointers where malloc preferentially gives you storage addresses below 2^32 because fewer translation tables are required (IIRC z/OS Unix is often set up to do this, but it might be another platform). This is worst because it works whenever you look at a simple test and falls over when you run it as part of a complex memory-hungry system. To pre-empt the obvious objection that the compiler will warn you if you haven't pre-declared malloc: not all compilers will. The problem occurs when you do not include stdlib.h explicitly but you include someother.h which on the platforms which do whinge about such things (gcc for instance) pulls in stdlib.h for you and on a less-well-equipped platform it isn't implicitly included. Practically all compilers will moan if you assign an int to a struct something *, certainly more than will whine about a missing prototype by default. Best Regards, Phil Willoughby -- Managing Director, StrawberryCat Limited StrawberryCat Limited is registered in England and Wales with Company No. 7234809. The registered office address of StrawberryCat Limited is: 107 Morgan Le Fay Drive Eastleigh SO53 4JH ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Compiler warnings in R-Tree code under Visual StudioExpress
On 18 févr. 2011, at 16:51, Philip Graham Willoughby wrote: malloc returns a 64 bit pointer of type void * No, from the caller's point of view it returns an int if you haven't included stdlib.h. Indeed. I assumed the programmer had included the standard headers. On my system, any implicit declaration is punished by a warning, or even an error depending on the strictness of the settings. Since we were in the context of casting to shut up one warning, I assumed no implicit declaration warning, so no implicit declaration at all. I guess that's where my assumption fails: I suppose implicit declarations elicit no warning on your system. Thanks for the clarification. Jean-Denis ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Compiler warnings in R-Tree code under Visual StudioExpress
On Fri, Feb 18, 2011 at 03:25:46PM +0100, Jean-Denis Muys scratched on the wall: On 18 f?vr. 2011, at 15:12, Philip Graham Willoughby wrote: Adding casts to get rid of warnings is usually the wrong answer in my experience. Certainly you should never cast the return value of a function call because that hides the problems you get when it's implicitly returning int because a required header is missing. I used to see a lot of C code (usually from Windows programmers - does MSVC encourage this?) which has stuff like this all over the place: Yes, MSVC does encourage it. Or, rather, MS Visual Studio makes you jump through many, many hoops to treat a .c file as a C file, and compile it with a C compiler. It assumes you'll always be working in C++. The standard templates in our setup don't even allow you to create a .c file-- you're only choice is .cpp. Even if you add a .c file, you need to dig deep into the Advanced settings to tell Studio to actually use the C compiler, and not the C++ compiler. This is likely because their C compiler doesn't seem to support the Common Language Runtime, which limits the ability to mix C and C#, for example. So they just assume you want to use the C++ compiler for everything. Most people don't know enough about the two language to think this matters. However, since C++ doesn't implicitly cast void* pointers, it will throw warnings for properly written C code, and the code monkeys of the world will just paste in a hard cast and hit recompile, thinking they fixed the warning when all they really did was cover up deeper problems. Forcing casts of void* in C++ was one of the less insightful language changes, and seems to have totally missed most of the the point of void* pointers. I suppose they thought they were making up for it with all the C++ style casts, but I rarely see people use those. About the only one I do see is dynamic_cast, and 99% of the time when you're using that, your doing something very anti-OOP, and your class design is broken. struct something *fred = (struct something *)malloc(sizeof(struct something)); Casting the return from malloc is never necessary - void * is assignable to any non-function pointer type by definition. It becomes an extremely bad idea when you're building on a platform with 64-bit pointers and a 32-bit int (such as everything I use) and you have the optimiser turned on ? in this case if stdlib.h isn't included none of your allocations will work properly and your program will crash. My pure C must be rusted. Could you please elaborate why this line breaks with 64-bit pointers and 32-bit ints? Undefined functions in C are assumed to return int. Many people think functions like malloc() are pre-defined by the compiler, but this is usually not true. However, to make things much worse, many compilers** *will* suppress function not defined warnings for libc functions like malloc(), because the compiler knows the linker will pick it up and deal with it later. ** I have no idea if the latest versions of the Studio compilers do this or not. I would actually guess they *do* throw the warning. Hence, if the header is there, and malloc() is defined, it all works. If the header is not there, it will still compile, sometimes without warning, but the cast will hide the mismatched-type warning of assigning a 32-bit int to a 64-bit pointer, and the code will crash. The original code (without the cast) likely triggered a warning, but someone fixed the warning (or, rather, made it go away) by putting the cast in there. In the argument of getting rid of warnings, it is worth remembering that warnings are there for a reason, and just because you got the warning to go away doesn't mean you actually fixed the problem-- it just means you got rid of the warning. Putting in casts are a big example of this, especially to/from void* when you're working in a C code base. They're rarely the answer. While I strive for clean code, I've also given up on warnings. I have a pure-C code base that I need to maintain on Win32 (Visual Studio C (NOT C++!)), Win64, Xbox (Visual Studio), PS3 (PPC-only, gcc-derived), Mac OS X 32 64 (gcc), iOS, Linux, and will likely be moving to other platforms. Given the wide array of compilers and their roots, it is nearly impossible to get code that will compile warning-free on every platform without resorting to #if defined() branches to support three different lines of what is essentially the same statement. Not going there. -j -- Jay A. Kreibich J A Y @ K R E I B I.C H Intelligence is like underwear: it is important that you have it, but showing it to the wrong people has the tendency to make them feel uncomfortable. -- Angela Johnson ___ sqlite-users mailing list sqlite-users@sqlite.org
