Of course that is the aim, as always.
In this particular case, maximally portable code (that will compile and execute correctly on all conforming compilers) must (a) ensure that the pointer argument is valid (b) ensure that the length is valid, or zero. Where reasonably possible both should be done statically. If conditional code is introduced then it must be tested with all branches covered. As always, it may be the case that one or more compilers may issue warnings for code that is fully compliant with the standard and fully tested. Sadly there may even be compilers that compile the code incorrectly (a compiler bug). The question of how to handle undesired warnings or compiler bugs on code that is known to be correct and compliant is always a judgement call. In my opinion the solution chosen should always be as fine-grained as possible (such as a compiler-specific conditional), but the downside is that the code can become littered with references to specific problems in specific compilers and thus become harder to work with. In my opinion changes that are visible to other compilers should be avoided unless the changed code is an equally valid solution to the problem at hand and/or the problem affects multiple compilers. In this light adding an if-test would be an incorrect choice (and would require an additional set of tests). Suppressing the warning specifically for this compiler would be a preferable solution. [Disclosure: I have just over 30 years of trying to write portable C code across 30 or so compilers. That doesn?t mean I?m right, but it does mean I?ve thought a lot about the problem and made most of the usual mistakes.] Regards David M Bennett FACS _____ Andl - A New Database Language - andl.org From: Scott Robison [mailto:sc...@casaderobison.com] Sent: Sunday, 23 August 2015 2:22 AM To: General Discussion of SQLite Database <sqlite-users at mailinglists.sqlite.org>; davidb at pfxcorp.com Subject: Re: [sqlite] Compile warnings Unless of course your objective is to write maximally portable code. It's not perfect, and certainly things have been done to accommodate more recent standards, but C89 compilers (including compilers that claim to support it through a switch) are more common than even full C99 implementations. Don't get me wrong, I don't object to a change to accommodate C99 null pointer requirements or even (necessarily) a change to suppress warnings, even if both requirements are needlessly strict in some situations. I just don't think that C99 or some compilers warning setup should mandate a change. On Aug 22, 2015 8:36 AM, "David Bennett" <davidb at pfxcorp.com <mailto:davidb at pfxcorp.com> > wrote: True. The C89/90 standard has of course been withdrawn and I don't have a copy. However, based on the drafts I have available the entirety of the text I quoted was added after the last correction to C89/90 and first appears in C99. In my opinion it would be unwise to rely on the omission of material from the earlier version of the standard to justify code that would be non-compliant with C99 and all later standards. Regards David M Bennett FACS Andl - A New Database Language - andl.org <http://andl.org> -----Original Message----- From: sqlite-users-bounces at mailinglists.sqlite.org <mailto:sqlite-users-boun...@mailinglists.sqlite.org> [mailto:sqlite-users-bounces at mailinglists.sqlite.org <mailto:sqlite-users-bounces at mailinglists.sqlite.org> ] On Behalf Of Scott Robison Sent: Saturday, 22 August 2015 2:05 AM To: General Discussion of SQLite Database <sqlite-users at mailinglists.sqlite.org <mailto:sqlite-users at mailinglists.sqlite.org> >; davidb at pfxcorp.com <mailto:davidb at pfxcorp.com> Subject: Re: [sqlite] Compile warnings And C89 doesn't have the valid pointer requirement On Aug 21, 2015 7:03 AM, "David Bennett" <davidb at pfxcorp.com <mailto:davidb at pfxcorp.com> > wrote: > Addressing only standards compliance, the C99 (n1256) standard says as > follows. > > 7.21.1 /2 > Where an argument declared as size_t n specifies the length of the > array for a function, n can have the value zero on a call to that > function. Unless explicitly stated otherwise in the description of a > particular function in this subclause, pointer arguments on such a > call shall still have valid values, as described in 7.1.4. On such a > call, a function that locates a character finds no occurrence, a > function that compares two character sequences returns zero, and a > function that copies characters copies zero characters. > > Later versions of the standard contain similar wording. > > A zero value for the third argument of memset() is standards > compliant. Any warning by any compiler is for the convenience of > developers and may be safely disabled or ignored while remaining standards compliant. > > In my opinion, disabling or simply ignoring the warning are both > legitimate choices. Modifying the code to suppress the warning is NOT. > > Regards > David M Bennett FACS > > Andl - A New Database Language - andl.org <http://andl.org> > > -----Original Message----- > From: sqlite-users-bounces at mailinglists.sqlite.org > <mailto:sqlite-users-bounces at mailinglists.sqlite.org> > [mailto:sqlite-users-bounces at mailinglists.sqlite.org > <mailto:sqlite-users-bounces at mailinglists.sqlite.org> ] On Behalf Of > Scott Robison > Sent: Friday, 21 August 2015 3:05 AM > To: General Discussion of SQLite Database > <sqlite-users at mailinglists.sqlite.org <mailto:sqlite-users at > mailinglists.sqlite.org> > > Subject: Re: [sqlite] Compile warnings > > On Thu, Aug 20, 2015 at 10:46 AM, Scott Doctor <scott at scottdoctor.com > <mailto:scott at scottdoctor.com> > > wrote: > > > My opinion is to keep it portable. The warning is there for a reason. > > you are worried about performance yet are calling a function that > > does nothing, which will take more memory cycles than a simple check for zero. > > > > I didn't say don't make a change. I'm observing there are things to > consider. In particular the optimization strategies that the SQLite > team have pursued for several years now have been *tiny* little > optimizations that would never be justifiable on their own but that > really add up, particularly for small devices probably running on batteries. > > > > Trying to memset a zero length is a bug, not the warning. Add an if > > statement around it. If the variable is local, it will probably be > > optimized as a register variable and a zero check of a register is a > > single op-code. > > > > Trying to memset a zero length buffer is not a bug if the length of > the sequence of bytes that needs to be set is zero. C89 in particular > does not disallow this use. > > > > the problem with disabling warnings is that even if this instance is > > not an error, some other part of the code may end up with the same > > situation but is an error in the coding. I would prefer code that > > can be compiled with all warnings turned on that gives no warnings > > than have a potential problem because of a glitch in the code. > > > > I don't think anyone called for disabling the warning. I think it > should just be ignored in this case, just as I ignore warnings that > are generated by Visual C++ when I compile SQLite there. > > -- > Scott Robison > _______________________________________________ > sqlite-users mailing list > sqlite-users at mailinglists.sqlite.org <mailto:sqlite-users at > mailinglists.sqlite.org> > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > > > _______________________________________________ > sqlite-users mailing list > sqlite-users at mailinglists.sqlite.org <mailto:sqlite-users at > mailinglists.sqlite.org> > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ sqlite-users mailing list sqlite-users at mailinglists.sqlite.org <mailto:sqlite-users at mailinglists.sqlite.org> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users _______________________________________________ sqlite-users mailing list sqlite-users at mailinglists.sqlite.org <mailto:sqlite-users at mailinglists.sqlite.org> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
