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 -----Original Message----- From: sqlite-users-boun...@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>; 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> 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 > > -----Original Message----- > From: 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> > Subject: Re: [sqlite] Compile warnings > > On Thu, Aug 20, 2015 at 10:46 AM, Scott Doctor <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 > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > > > _______________________________________________ > sqlite-users mailing list > 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 http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
