www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 3407] New: [tdpl] Compiling with -safe -release must keep all bound checks

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

           Summary: [tdpl] Compiling with -safe -release must keep all
                    bound checks
           Product: D
           Version: unspecified
          Platform: Other
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: DMD
        AssignedTo: nobody puremagic.com
        ReportedBy: andrei metalanguage.com



17:30:43 PDT ---
The following program completes successfully when compiled with -safe -release:

void main() {
    auto a = new int[2];
    auto b = a[3];
}

When the -safe flag is present, all bound checks must be present.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Oct 15 2009
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3407


Don <clugdbug yahoo.com.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |clugdbug yahoo.com.au



I don't understand the reasoning behind this. The primary reason you use
-release is to turn off bounds checking, because bounds checking is *really*
slow.
This change would basically make -safe and -release incompatible in practice:
why on earth would you use both?
Up to now, -safe has been entirely about compile-time checks. Here, you're
making it insert runtime checks as well, so that compile-time safety incurs a
run-time penalty. I don't like that at all.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Oct 30 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3407




07:55:56 PDT ---


 I don't understand the reasoning behind this. The primary reason you use
 -release is to turn off bounds checking, because bounds checking is *really*
 slow.
 This change would basically make -safe and -release incompatible in practice:
 why on earth would you use both?
 Up to now, -safe has been entirely about compile-time checks. Here, you're
 making it insert runtime checks as well, so that compile-time safety incurs a
 run-time penalty. I don't like that at all.


To me the charters of -safe and -release are different:

-safe: "Do whatever the hell it takes to make sure my program never has a
memory error"

-release: "I've tested and debugged my programs, eliminate runtime design
checks"

Compiling with -safe implies array bounds checks stay, come hell or high water.
Compiling with -release means the contracts and assert are removed. Those can't
cause memory errors. Only non-safe builds will remove array bounds checks.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Oct 30 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3407





 -safe: "Do whatever the hell it takes to make sure my program never has a
 memory error"
 
 -release: "I've tested and debugged my programs, eliminate runtime design
 checks"
 
 Compiling with -safe implies array bounds checks stay, come hell or high water.
 Compiling with -release means the contracts and assert are removed. Those can't
 cause memory errors. Only non-safe builds will remove array bounds checks.


The current -safe guarantees that you never have to debug memory corruption
problems, which can be notoriously difficult to track down. I would use it 100%
of the time. But I'd always have bounds checking off in production code, it
hurts performance too much.

Actually, I think what this issue is, is that you need an option to have
contracts and asserts turned off, while leaving bounds checking on.

  compile   runtime
   safe    bounds contracts
    Y       Y          Y
    Y       N          N   <---- I want to keep this option
    Y       Y          N   <---- You're saying we need this option

I think -release is a misnomer, and should be split in two.
(Actually I think since we have module(system), we'll probably be able make
-safe mandatory, eventually).

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Oct 30 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3407




08:51:31 PDT ---


 -safe: "Do whatever the hell it takes to make sure my program never has a
 memory error"
 
 -release: "I've tested and debugged my programs, eliminate runtime design
 checks"
 
 Compiling with -safe implies array bounds checks stay, come hell or high water.
 Compiling with -release means the contracts and assert are removed. Those can't
 cause memory errors. Only non-safe builds will remove array bounds checks.


 
 The current -safe guarantees that you never have to debug memory corruption
 problems, which can be notoriously difficult to track down.


Yes. Well, that's the intent - the feature is not finished.


 I would use it 100%
 of the time. But I'd always have bounds checking off in production code, it
 hurts performance too much.


What you want is impossible as far as we know. Safety and no bounds checking
cannot be done with the current technology, or at least not in a way that's not
onerous (e.g. a 12-hour analysis of a 10,000 lines program).


 Actually, I think what this issue is, is that you need an option to have
 contracts and asserts turned off, while leaving bounds checking on.
 
   compile   runtime
    safe    bounds contracts
     Y       Y          Y
     Y       N          N   <---- I want to keep this option
     Y       Y          N   <---- You're saying we need this option
 
 I think -release is a misnomer, and should be split in two.


I agree. You may want to make a proposal, and quick. At any rate, today "-safe"
is the best-defined notion we have and I think it would be difficult to
convince people that -safe and no bounds checking make sense together. 

BTW, there's nothing special about compile-time vs. run-time in "safe". Memory
safety asks for a combo solution. Oftentimes a runtime check could be hoisted
to compilation time.


 (Actually I think since we have module(system), we'll probably be able make
 -safe mandatory, eventually).


That would be great!

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Oct 30 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3407


David Simcha <dsimcha yahoo.com> changed:

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



http://en.wikipedia.org/wiki/Bounds-checking_elimination

Not sure if DMD does any of this yet, or if the implementation of bounds
checking is naive.  It may eventually be possible to optimize bounds checking
enough that it can be left on in all but the most performance critical code. 
After all, Java gets away w/ this somehow.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Oct 30 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3407


Leandro Lucarella <llucax gmail.com> changed:

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



PDT ---
LDC already have all the checks splat in different options:

$ ldc --help
[...]
  -enable-asserts                              - (*) Enable assertions
  -enable-boundscheck                          - (*) Enable array bounds checks
  -enable-contracts                            - (*) Enable function pre- and
post-conditions
  -enable-invariants                           - (*) Enable invariants
  -enable-postconditions                       - (*) Enable function
postconditions
  -enable-preconditions                        - (*) Enable function
preconditions
  -enable-inlining                             - (*) Enable function inlining
in -O<N>
[...]
Options marked with (*) also have a -disable-FOO variant with inverted
meaning.
$ 

It will be very nice if this switches are included in the reference
implementation too.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Oct 30 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3407




17:21:41 PDT ---


 LDC already have all the checks splat in different options:
 
 $ ldc --help
 [...]
   -enable-asserts                              - (*) Enable assertions
   -enable-boundscheck                          - (*) Enable array bounds checks
   -enable-contracts                            - (*) Enable function pre- and
 post-conditions
   -enable-invariants                           - (*) Enable invariants
   -enable-postconditions                       - (*) Enable function
 postconditions
   -enable-preconditions                        - (*) Enable function
 preconditions
   -enable-inlining                             - (*) Enable function inlining
 in -O<N>
 [...]
 Options marked with (*) also have a -disable-FOO variant with inverted
 meaning.
 $ 
 
 It will be very nice if this switches are included in the reference
 implementation too.


I think this is too much configurability that does not reflect principles, only
mechanism.

DbC means assert, precondition, postcondition, and invariant are enabled. I
don't think it's wise to enable or disable those independently.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Oct 30 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3407




PDT ---




 LDC already have all the checks splat in different options:
 
 $ ldc --help
 [...]
   -enable-asserts                              - (*) Enable assertions
   -enable-boundscheck                          - (*) Enable array bounds checks
   -enable-contracts                            - (*) Enable function pre- and
 post-conditions
   -enable-invariants                           - (*) Enable invariants
   -enable-postconditions                       - (*) Enable function
 postconditions
   -enable-preconditions                        - (*) Enable function
 preconditions
   -enable-inlining                             - (*) Enable function inlining
 in -O<N>
 [...]
 Options marked with (*) also have a -disable-FOO variant with inverted
 meaning.
 $ 
 
 It will be very nice if this switches are included in the reference
 implementation too.


 
 I think this is too much configurability that does not reflect principles, only
 mechanism.
 
 DbC means assert, precondition, postcondition, and invariant are enabled. I
 don't think it's wise to enable or disable those independently.


I don't agree about not providing the option because "it's not wise". Let the
user decide what is wise or not.

That said, I can agree about having that kind of granularity might be not very
useful (there are very very few situations where you might want to enable
preconditions and not postconditions, for example).

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Oct 30 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3407




03:09:21 PST ---
I usually do (unimportant) debug asserts as debug asserts so they disappear if
no -debug switch was supplied... well I don't use contracts. And use simple
asserts for critical sequrity checks, I basically see no point in -release
switch. "I tested and debugged my programs" is too brave assertion for a
programmer.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Nov 06 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3407


Walter Bright <bugzilla digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bugzilla digitalmars.com



02:53:58 PST ---
Will remove -safe switch and add -noboundscheck switch.  safe functions always
get bounds checked unless -noboundscheck is on.  trusted and  system functions
only get bounds checked when -release and -noboundscheck are off.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Nov 21 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3407




PST ---
Related SVN commit: http://www.dsource.org/projects/dmd/changeset/258

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Nov 21 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3407




17:33:37 PST ---


 Will remove -safe switch and add -noboundscheck switch.  safe functions always
 get bounds checked unless -noboundscheck is on.  trusted and  system functions
 only get bounds checked when -release and -noboundscheck are off.


Would -no-bounds-check be more readable? Just asking.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Nov 22 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3407




19:21:29 PST ---
To me that always looks like a mistake where there are multiple switches
someone forgot to put spaces in between.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Nov 22 2009
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3407


Walter Bright <bugzilla digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED



00:53:25 PST ---
Fixed dmd 2.037

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Dec 06 2009