On 4 Dec 2014, at 12:26am, James K. Lowden <jklow...@schemamania.org> wrote:
> What to do is another question. SQLite can surely ignore it. If I > felt strongly about it, I'd submit a bug report to GCC because IIUC > the nonnull attribute syntax provides no way to express the constraint > defined by the standard, i.e. "__n > 0 || __nonnull ((1, 2))". But that's not what the standard says. My understanding of the standard is that both source and destination must be legitimate memory locations. It says nothing about the value of n. In other words memcpy() may well look at the source and destination locations before discovering that n == 0 so it doesn't have to do anything. [1] It's clear even in the first standard Clemens quoted. In this it appears I agree with Clemens' interpretation, and with the notation in the function definitions: source and dest . I don't know what this says about SQLite's code. Is it the custom these days to include clear and visible null checks in C code even if the programmer(s) know they can never be triggered ? Simon. [1] A naïve view of optimization is that memcpy() should check for (n == 0) first so it can return quickly, but this check slows down (n != 0) use of the function and that makes me ask why your code keeps calling memcpy() for zero bytes often enough for the check to give a significant advantage. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
