https://issues.dlang.org/show_bug.cgi?id=17102

Jack Stouffer <jack@jackstouffer.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jack@jackstouffer.com
           Hardware|x86                         |All
                 OS|Mac OS X                    |All
           Severity|enhancement                 |normal

--

https://issues.dlang.org/show_bug.cgi?id=17102

--- Comment #1 from anonymous4 <dfj1esp02@sneakemail.com> ---
It depends on what you want. If we treat the default string value as null, it gets passed as null to C API, and the crash is expected.

--

https://issues.dlang.org/show_bug.cgi?id=17102

--- Comment #2 from donte5379@comcast.net ---
I think that std.file.write should throw an exception before the null gets passed to the C API. Even if I add a try-catch block all I see is a message "Segmentation fault" on the terminal.

  std.file.write(file_name, the_text);
  } catch (Exception e){
    writeln(e);
  }


As an added frustration the redirection is corrupted in bash (and tcsh) and so it is difficult to run dustmite. I ended up reducing the failing case by hand.

--

https://issues.dlang.org/show_bug.cgi?id=17102

Vladimir Panteleev <thecybershadow@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |thecybershadow@gmail.com
         Resolution|---                         |WONTFIX

--- Comment #3 from Vladimir Panteleev <thecybershadow@gmail.com> ---
(In reply to donte5379 from comment #2)
> I think that std.file.write should throw an exception before the null gets passed to the C API.

I don't think it's the job of the standard library to validate that the input parameter is valid before passing it to a C API.

> Even if I add a try-catch block all I see is a message "Segmentation fault" on the terminal.
> 
>   std.file.write(file_name, the_text);
>   } catch (Exception e){
>     writeln(e);
>   }

Writing to a file whose file name is unset is a logic error in the user's code, so if such a check would be present in std.file.write, its correct behavior would be to throw an Error, which would also bypass your try/catch block (as you only catch an Exception), so the program would behave similarly.

The main difference would be that on POSIX, by default the D runtime doesn't attempt to handle and print a stack trace on unhandled signals (which would otherwise terminate the program). On Linux, there exists etc.linux.memoryerror, which translates segmentation faults to D exceptions. On Windows, access violations are already translated to D exceptions through D's support for Windows structured exception handling.

Either way, finding the cause of the segmentation fault would have been as simple as running your program under a debugger.

> As an added frustration the redirection is corrupted in bash (and tcsh) and so it is difficult to run dustmite.

The DustMite documentation contains examples on correctly reducing segmentation faults. I've also created a page to explain the basics: https://github.com/CyberShadow/DustMite/wiki/Reducing-a-segmentation-fault

--

https://issues.dlang.org/show_bug.cgi?id=17102

Jack Stouffer <jack@jackstouffer.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|WONTFIX                     |---

--- Comment #4 from Jack Stouffer <jack@jackstouffer.com> ---
(In reply to Vladimir Panteleev from comment #3)
> I don't think it's the job of the standard library to validate that the input parameter is valid before passing it to a C API.

We can at least add an assert with an error message.

> Either way, finding the cause of the segmentation fault would have been as simple as running your program under a debugger.

Impossible with macOS.

--

https://issues.dlang.org/show_bug.cgi?id=17102

--- Comment #5 from Vladimir Panteleev <thecybershadow@gmail.com> ---
(In reply to Jack Stouffer from comment #4)
> Impossible with macOS.

How so?

--

https://issues.dlang.org/show_bug.cgi?id=17102

--- Comment #6 from Jack Stouffer <jack@jackstouffer.com> ---
(In reply to Vladimir Panteleev from comment #5)
> (In reply to Jack Stouffer from comment #4)
> > Impossible with macOS.
> 
> How so?

https://issues.dlang.org/show_bug.cgi?id=14927 and https://issues.dlang.org/show_bug.cgi?id=8172

--

https://issues.dlang.org/show_bug.cgi?id=17102

--- Comment #7 from Vladimir Panteleev <thecybershadow@gmail.com> ---
(In reply to Jack Stouffer from comment #6)
> (In reply to Vladimir Panteleev from comment #5)
> > (In reply to Jack Stouffer from comment #4)
> > > Impossible with macOS.
> > 
> > How so?
> 
> https://issues.dlang.org/show_bug.cgi?id=14927 and https://issues.dlang.org/show_bug.cgi?id=8172

Those are implementation issues orthogonal to this one.

(In reply to Jack Stouffer from comment #4)
> We can at least add an assert with an error message.

- Adding an assert won't work, because the Phobos static library is compiled
with -release.
- Adding an explicit if (...) throw new Error(...) will not throw an exception
that would have been caught in #2.
- I still think it's not Phobos' job to validate parameters passed from the
user to the C runtime. It is illogical. Consider:
  - Explicit checks for parameters that will get dereferenced anyway will be
redundant and will add overhead in all cases except when the program is buggy.
  - D functions in the runtime and standard library which accept reference
types do not perform explicit checks whether a parameter that should never be
null is non-null - dereferencing implicitly does that.
  - I don't see a meaningful distinction in whether null checks should be
present depending on whether the dereference occurs in D or C code.

--

https://issues.dlang.org/show_bug.cgi?id=17102

Nemanja Boric <4burgos@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |4burgos@gmail.com

--- Comment #8 from Nemanja Boric <4burgos@gmail.com> ---
https://github.com/dlang/phobos/pull/5049

--

https://issues.dlang.org/show_bug.cgi?id=17102

--- Comment #9 from github-bugzilla@puremagic.com ---
Commits pushed to master at https://github.com/dlang/phobos

https://github.com/dlang/phobos/commit/e80d3b5745e7875980f6c69a2c09cccb647fa9a6
Fix Issue 17102: std.write.file generates a segmentation fault when the
file name is a string with a default value

While trying to build the file name for exception
from 0terminated namez, don't pass null to strlen

https://github.com/dlang/phobos/commit/c6d33505dc5be6c2e47ebdbd653876eb2ac566e9 Merge pull request #5049 from Burgos/fix-17102

fix issue 17102 - Don't pass null to strlen in std.file.cenforce merged-on-behalf-of: Jack Stouffer <jack@jackstouffer.com>

--