Bug 12387 – Mark stdlib malloc and friends as weakly pure

I don't know what goes on under the hood, but I think these can be marked as pure? On the same grounds that most GC.malloc functions are also weekly pure. It would help a lot, since there is currently no way to mark something as "trusted pure" without jumping though massive hoops.

malloc and friends affect global state and therefore are not pure. The gc is special in that it is allowed to modify global state and yet remain pure. malloc is not special.

Could you please explain what makes GC "special", but not "malloc" ? What does one need to verify to be "special". Also related: If malloc is not pure, then there is *0* chance of seeing much use of it outside the IO module. We have gone through great lengths to keep most range/algorithm/string functions pure and CTFE-able. Breaking that purity is *NOT* acceptable. This includes functions that do path concatenation, that *could* use your ScopeBuffer, or similar "local memory management" approaches. It is a major blocker in terms of "preventing Phobos from leaking". Please reconsider. Or please try to explain why "malloc" isn't special. It will help me understand, and stop me from pressing on the issue.

> Or please try to explain why "malloc" isn't special. It will help me > understand, and stop me from pressing on the issue. I guess you could consider a malloc leak as an observable side effect... eg duplicate calls to a pure function that calls malloc can't be removed even if they return an immutable pointer. > malloc and friends affect global state and therefore are not pure. > > The gc is special in that it is allowed to modify global state and yet remain > pure. malloc is not special. This is a convoluted way to say 'no' without giving any reasons...

(In reply to comment #2) > Could you please explain what makes GC "special", but not "malloc" ? What does > one need to verify to be "special". C malloc is not any less special than GC.malloc. it could technically be marked weak-pure. I think Walter is confusing purity with strong purity. Malloc is not strong-pure, and would not be considered as such (it returns mutable pointer). It is the classic example of weak purity. > Also related: If malloc is not pure, then there is *0* chance of seeing much > use of it outside the IO module. We have gone through great lengths to keep > most range/algorithm/string functions pure and CTFE-able. Breaking that purity > is *NOT* acceptable. I agree, I think this enhancement should be reconsidered. Any allocation scheme that globally stores "unused" blocks should be considered logically pure, and therefore can be forced pure. You treat the storage area as not really existing before it's requested, so accessing that global pool isn't technically accessing global state. It isn't any different than asking the OS to supply the blocks, which should also be considered pure.