[Issue 12507] SysTime.init.toString should not segfault

d-bugmail at puremagic.com d-bugmail at puremagic.com
Wed Apr 2 21:55:18 PDT 2014


https://d.puremagic.com/issues/show_bug.cgi?id=12507


Jonathan M Davis <jmdavisProg at gmx.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jmdavisProg at gmx.com


--- Comment #1 from Jonathan M Davis <jmdavisProg at gmx.com> 2014-04-02 21:55:08 PDT ---
SysTime.init is supposed to be equivalent to SysTime(0, LocalTime()) - which
would be 0001-Jan-01T00:00:00. The problem is that the timezone can't be
initialized with LocalTime at compile time, so SysTime.init can't have a valid
timezone. I believe that this limitation is documented.

The only way to work around it would be to check for the timezone for null on
every operation that uses it, which would then incur constant overhead for all
SysTime objects just to try and make it so that SysTime.init is valid. I
concluded that that wasn't worth it and instead opted for documenting the
behavior.

toString is just one of SysTime's functions which is affected by the problem. I
suppose that we could add a check specifically for toString and let the
operations still segfault for SysTime.init, but that seems rather inconsistent
to me. My take on it is generally that you just shouldn't be doing much of
anything with SysTime.init except using it as a default-initialized value that
gets reassigned before you actually do anything with the object.

I'm not super-enthused with the situation, but as far as I can see, there is no
solution that results in SysTime.init being valid without adding extra
overhead.

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


More information about the Digitalmars-d-bugs mailing list