www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 12387] New: Mark stdlib malloc and friends as weekly pure

reply d-bugmail puremagic.com writes:
https://d.puremagic.com/issues/show_bug.cgi?id=12387

           Summary: Mark stdlib malloc and friends as weekly pure
           Product: D
           Version: D2
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: druntime
        AssignedTo: nobody puremagic.com
        ReportedBy: monarchdodra gmail.com


--- Comment #0 from monarchdodra gmail.com 2014-03-17 03:28:30 PDT ---
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.

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Mar 17 2014
next sibling parent d-bugmail puremagic.com writes:
https://d.puremagic.com/issues/show_bug.cgi?id=12387


Walter Bright <bugzilla digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |bugzilla digitalmars.com
         Resolution|                            |WONTFIX


--- Comment #1 from Walter Bright <bugzilla digitalmars.com> 2014-03-17
04:02:00 PDT ---
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.

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Mar 17 2014
prev sibling next sibling parent d-bugmail puremagic.com writes:
https://d.puremagic.com/issues/show_bug.cgi?id=12387



--- Comment #2 from monarchdodra gmail.com 2014-03-17 04:09:43 PDT ---
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.

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Mar 17 2014
prev sibling next sibling parent d-bugmail puremagic.com writes:
https://d.puremagic.com/issues/show_bug.cgi?id=12387


yebblies <yebblies gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |yebblies gmail.com


--- Comment #3 from yebblies <yebblies gmail.com> 2014-03-21 00:42:37 EST ---
 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... -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Mar 20 2014
prev sibling parent d-bugmail puremagic.com writes:
https://d.puremagic.com/issues/show_bug.cgi?id=12387


Steven Schveighoffer <schveiguy yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |schveiguy yahoo.com


--- Comment #4 from Steven Schveighoffer <schveiguy yahoo.com> 2014-03-20
08:06:18 PDT ---
(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. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Mar 20 2014