Bug 3057 – Add pure annotations to core.stdc.*

Created attachment 395 Add pure annotations throughout std.core.* I did a quick pass through core.stdc.* to annotate the functions I believe should be pure. I added some comments for several that could be stretched to be pure if we're a little looser with the definition of pure. I skipped over the floating point areas as there's been a good amount of debate that I haven't followed over what to do with them. I defer to Don and Walter on those.

Comment on attachment 395 Add pure annotations throughout std.core.* note: I varied the style used to annotate some parts to get a feel for how they looked. A second pass should be done to choose a common style.

Created attachment 397 same set of changes with pure as after the declaration annotation

(In reply to comment #0) > Created an attachment (id=395) [details] > Add pure annotations throughout std.core.* > > I did a quick pass through core.stdc.* to annotate the functions I believe > should be pure. I added some comments for several that could be stretched to > be pure if we're a little looser with the definition of pure. I skipped over > the floating point areas as there's been a good amount of debate that I haven't > followed over what to do with them. I defer to Don and Walter on those. Almost all functions in stdc.math cannot possibly be pure, because they set the global 'errno'. (This is part of the reason why it has been worthwhile to re-implement most C math functions in D). There are a few functions (like fpclassify() and the trivial functions which use it) which _could_ legally be marked as pure, but I really don't think that use of stdc.math should be encouraged in any way in D code. So the math stuff is not a TODO list thing, it should stay as impure.

Don, Works for me.. core.stdc.math stays impure. I'll put your response in there as a comment to help prevent re-addressing this issue. How about core.stdc.complex? A quick scan of some of the man pages suggest that they don't touch errno. ---- Sean, Any thoughts on the several I added comments to, like all the ones that use the external LC_CTYPE??

I'd consider environment variables to be global state, and so no function using them could be pure. As for some of the ones you'd specifically marked, strftime() uses the LC_TIME category of the current locale, which is global mutable state as well.

String functions are also impure because their arguments can be mutable.

(In reply to comment #6) > String functions are also impure because their arguments can be mutable. Please be specific. The string functions I marked pure in the attached diffs should be fine. They're taking const non-shared char pointers, which is safe.

char* str1=obj.str1; const char* str2=obj.str2; auto len1=strlen(str2); str1[0]=0; auto len2=strlen(str2); assert(str1==str2,"pwnd"); GCC has stricter definition of pure function - a function whose arguments are contained in the stack (no reference types), in D this definition is extended to include immutable reference types, because they effectively behave as value types.

assert(str1!=str2,"pwnd"); *fixed

(In reply to comment #8) > char* str1=obj.str1; > const char* str2=obj.str2; > auto len1=strlen(str2); > str1[0]=0; > auto len2=strlen(str2); > assert(str1!=str2,"pwnd"); > > GCC has stricter definition of pure function - a function whose arguments are > contained in the stack (no reference types), in D this definition is extended > to include immutable reference types, because they effectively behave as value > types. That's fine. That's not a violation of purity as D has defined it. Purity is defined, roughly, as: 1) does not mutate global state 2) does not depend on global state or: Depends only on it's inputs and mutates only its output. strlen is a classic example of a pure function.

Reference type is an example of global state in the sense that it can change unexpectedly. Dependency on global state is impure because it prevents reordering of function calls and caching function results. My example demonstrates, why strlen calls can't be reordered or cached, which proves its impurity.

strlen is a classic example of a pure function because classic strings are immutable which is not the case for C strings and strlen.

I sent a pull request a while back that added safety, purity, and nothrow annotations throughout core.stdc (not having noticed the patch here). I'll close this, but if it turns out I forgot some annotations, please reopen.