[Issue 17868] add pragma(crt_con/destructor[, priority])
https://issues.dlang.org/show_bug.cgi?id=17868
--- Comment #3 from Steven Schveighoffer ---
Why is it terrible? Because absolute numbers are used for ordering, with no
central determination of who should use what number. D is far more sane on this
subject.
Why is it needed? Can't you just use your local C compiler to add the
functions? If it's so different and possibly not supported, why do we want D to
get involved here?
file.d:
extern(C) void myModulector()
{
// construct
}
extern(C) void myModuledtor()
{
// destroy
}
file.c:
constructor (1) // no idea of syntax exactly.
void myModulector();
destructor(1)
void myModuledtor();
--
[Issue 17861] UTF Decode fails with exception
https://issues.dlang.org/show_bug.cgi?id=17861 --- Comment #15 from Jonathan M Davis --- (In reply to Jon Degenhardt from comment #14) > Changing the default behavior for the individual functions would cause > backward compatibility issues. Any thoughts on having run-time selectable > behavior that would override the defaults? The default behavior could be > left unchanged. > > The two issues that come to mind: > - Functions currently nothrow could lose that status if throw is an option. > - Performance: Compile-time choices are faster than run-time. > > The advantage of a run-time selectable behavior is that it would support the > need many programs have for an application specific behavior. There is no > single default appropriate for all cases. In general, Walter is against having flags that determine the behavior of the language, and that's essentially what you're suggesting, even if it's set at runtime rather than at compile time. The reality of the matter is that as much as the current behavior sucks, it's trivial to work around it by calling decode yourself. So, I really don't see any reason to make it configurable. That would just make it so that you don't know what the code is designed to do when you look at it. I think that it's far better to just be clear on how UTF decoding works in D than to try and make anything at the language level configurable. The standard library already provides the tools necessary to allow the programmer to choose how they want to handle invalid UTF, even if the defaults aren't exactly ideal. (In reply to Etienne from comment #13) > You have to choose whether it's a bug or a feature. I think everyone is > ready to live with that, but if you live up to it and consider it a feature > it'll have to be documented. Just a 1 liner somewhere saying "Foreach > (string) can throw unicode errors!" > > That'll be a good solution to this issue, because right now everyone is > forced to learn it the hard way. > > This being said, I don't see Google Chrome crashing every time it sees an > invalid code point. I'm not sure anyone would think about catching that on > the first try if they were to do an Ajax call. I'm also pretty sure they'd > be happy with the code path where it doesn't throw when the invalid code > point comes up. If you know of anyone doing software specifically for > unicode valiation, maybe they'd need to be warned but that's about it for me. > > So yeah, just wave it as a feature or squash the bug, but don't stay in > between forever. If the spec isn't clear about the fact that decoding invalid UTF with foreach will throw an exception, then the spec needs to be updated accordingly, but the current behavior is very much as designed and not a bug. I have no idea if the spec says anything about invalid UTF or not. I'd have to comb through it to know for sure. But the spec is often missing details that it should have, and sometimes, when it does say something, it's concise enough in what it says that it's easily missed. It wouldn't surprise me at all if it were stated somewhere in there, and you just missed it, and it wouldn't surprise me if it's not there. Regardless, I completely agree that the spec should be clear on the matter. --
[Issue 17861] UTF Decode fails with exception
https://issues.dlang.org/show_bug.cgi?id=17861 --- Comment #14 from Jon Degenhardt --- Changing the default behavior for the individual functions would cause backward compatibility issues. Any thoughts on having run-time selectable behavior that would override the defaults? The default behavior could be left unchanged. The two issues that come to mind: - Functions currently nothrow could lose that status if throw is an option. - Performance: Compile-time choices are faster than run-time. The advantage of a run-time selectable behavior is that it would support the need many programs have for an application specific behavior. There is no single default appropriate for all cases. --
[Issue 17861] UTF Decode fails with exception
https://issues.dlang.org/show_bug.cgi?id=17861 --- Comment #13 from Etienne --- You have to choose whether it's a bug or a feature. I think everyone is ready to live with that, but if you live up to it and consider it a feature it'll have to be documented. Just a 1 liner somewhere saying "Foreach (string) can throw unicode errors!" That'll be a good solution to this issue, because right now everyone is forced to learn it the hard way. This being said, I don't see Google Chrome crashing every time it sees an invalid code point. I'm not sure anyone would think about catching that on the first try if they were to do an Ajax call. I'm also pretty sure they'd be happy with the code path where it doesn't throw when the invalid code point comes up. If you know of anyone doing software specifically for unicode valiation, maybe they'd need to be warned but that's about it for me. So yeah, just wave it as a feature or squash the bug, but don't stay in between forever. --
[Issue 17861] UTF Decode fails with exception
https://issues.dlang.org/show_bug.cgi?id=17861 --- Comment #12 from Jonathan M Davis --- (In reply to Etienne from comment #11) > If the current idea is to not fix the bugs due to possible breakage, why > have a bug tracker for druntime in the first place? The current behavior is not a bug. The code is functioning exactly as designed. That design is arguably a bad design, and many of us would like to change it, but changing it would break existing code, so it is unlikely that it will be changed. There simply isn't a good deprecation path that would allow us to go from one behavior to the other - certainly no one has come up with one thus far. > Also, what's the point of having unit tests if you can't rely on them? What unit test are you referring to? Nothing about the current behavior of foreach and decoding code points should make it so that unit tests are unreliable. foreach is completely consistent in what it does. It's just that it's designed to do something that we wouldn't design it to do if we were doing things from scratch. You weren't previously aware that foreach threw when decoding invalid UTF. Now, you are, and you can write your code accordingly. The information about foreach throwing when decoding invalid UTF should be in the spec, but I don't know if it is or not. The spec doesn't always have the information that it should, but this is how foreach was designed and has worked ever since it was made so that it could decode code points. And it's the intended behavior until such time as we can figure out how to move to using the replacement character without breaking code in the process, which unfortunately, may very well be never. Right now, literally, our best option that would involve making the change would be to make the change and warn in the changelog that that's what we're doing, and anyone reading it would then have the opportunity to scour their code to see if they needed to change it as a result. The breakage would be silent and easy to miss even if in many cases, it wouldn't matter. And as such, thus far, that solution has been deemed unacceptable. So, if you know of a way to make it so that foreach can be changed to use the replacement character without silently breaking code, then great. We'd love to hear it. As it stands, this is one of those design decisions that we regret in retrospect but seem to be stuck with. --
[Issue 2504] Reserve for associative arrays
https://issues.dlang.org/show_bug.cgi?id=2504 Alexandru Razvan Caciulescu changed: What|Removed |Added Status|NEW |ASSIGNED CC||alexandru.razva...@gmail.co ||m Assignee|nob...@puremagic.com|alexandru.razva...@gmail.co ||m --
[Issue 17747] extern(C) shared static module constructor should be called in betterC programs
https://issues.dlang.org/show_bug.cgi?id=17747 Martin Nowak changed: What|Removed |Added Keywords||pull CC||c...@dawg.eu --- Comment #17 from Martin Nowak --- Walters take on this was to simply run `shared static ctors/dtors` in betterC. https://github.com/dlang/dmd/pull/6956 --
[Issue 17868] add pragma(crt_con/destructor[, priority])
https://issues.dlang.org/show_bug.cgi?id=17868 --- Comment #2 from Martin Nowak --- (In reply to Steven Schveighoffer from comment #1) > This looks terrible (the original feature I mean). Do we really want to add > this to D? Can't someone just use a C/C++ compiler? What's terrible about that? It's necessary for low-level integrations, and as it isn't standardized between C compilers it would be very helpful to make it at least uniformly accessible in D. It is definitely needed in any case, and obviously gdc/ldc already support it (each with their own syntax). So this enhancement is mainly about dmd and a portable syntax between D compilers. --
[Issue 17861] UTF Decode fails with exception
https://issues.dlang.org/show_bug.cgi?id=17861 --- Comment #11 from Etienne --- If the current idea is to not fix the bugs due to possible breakage, why have a bug tracker for druntime in the first place? Also, what's the point of having unit tests if you can't rely on them? --
[Issue 17861] UTF Decode fails with exception
https://issues.dlang.org/show_bug.cgi?id=17861 --- Comment #10 from Jonathan M Davis --- If you don't want foreach to throw when decoding, then don't use foreach to decode. Call std.utf.decode yourself rather than having foreach automatically call the druntime version for you. We can't change foreach right now for exactly the same reasons that we can't change front and popFront for strings. If it were decided that the breakage that would result from changing front and popFront to use the replacement character was low enough that we were willing to just change them and let things break, then we'd change foreach. But as long as it's considered too risk to change front and popFront to not throw, it's too risky to change foreach. There is nothing special about foreach that makes it any different from front and popFront for strings in terms of whether we can risk breaking code. I'm sorry that you find the current behavior surprising, but string handling in D in general requires understanding a number of quirks that we'd like to change but can't due to how much existing code would break if we did make the desired changes. --
[Issue 17861] UTF Decode fails with exception
https://issues.dlang.org/show_bug.cgi?id=17861 --- Comment #9 from Etienne --- The std.utf.decode debate is a rough one and seems to have its workarounds. On the other hand, you have this forgotten code at rt.util.utf where everything is so low-level and there is no option to use a replacement character. This is something that comes up on a foreach loop on a string. I don't know why anyone would expect foreach to throw? It's a little strange. Obviously the whole library should default to a replacement character, but rt.util.utf is a little more urgent because of how much of a surprise it is for a foreach loop to be throwing, whereas you don't really expect it to behave like a function and it can happen in edge cases on release builds where things become very difficult to debug. --
[Issue 17635] [REG 2.066.0] cannot convert unique immutable(int)** to immutable
https://issues.dlang.org/show_bug.cgi?id=17635 Walter Bright changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #2 from Walter Bright --- https://github.com/dlang/dmd/pull/7179 --
[Issue 17861] UTF Decode fails with exception
https://issues.dlang.org/show_bug.cgi?id=17861 Jonathan M Davis changed: What|Removed |Added CC||issues.dl...@jmdavisprog.co ||m Hardware|x86 |All OS|Windows |All --- Comment #8 from Jonathan M Davis --- This has been discussed before. There's a strong argument for making it so that decode uses the replacement character by default (it's even what the Unicode standard says you should do), and all string-based stuff then follows suit, at which point anyone wanting exceptions would need to call decode manually with the template argument indicating that that's what they wanted - which is the opposite of what we have now. And Walter is actually in favor of using the replacement character instead of exceptions and possibly even making the change in spite of the issues, but there have been some folks who have been strongly opposed to that. The problem is twofold: 1. Making the change risks silently breaking a ton of code. 2. Others (Vladimir in particular IIRC) have argued about how negative it is to have the contents of strings silently changed, since there are cases where it would be highly detrimental for that to happen. And on some level, all of this gets wrapped into the auto-decoding debate, because that's the main reason that this is out of the control of the user. front and popFront on strings call decode for you and call it in the way that results in exceptions on invalid UTF instead of using the replacement character. Anyone making the calls manually has the choice. So, I think that the chances are very high that we would go with the replacement character by default rather than exceptions (maybe not even have the exceptions at all) if we were starting from scratch - just like we wouldn't have auto-decoding if we were starting from scratch. But it's highly questionable that we can get away with making the change now due to the ramifications that it will have on existing code. At this point, the situation with decoding code points and not having it throw is in pretty much the same boat as using strings with range-based code and not auto-decoding: you have to use wrappers like byCodeUnit and/or special-case your code on strings. And to avoid the exceptions on bad Unicode, you either have to not be decoding code points, or you need to do so yourself with std.utf.decode. No, that's not ideal, but no one has been able to come up with a reasonable way to change the status quo with any kind of reasonable deprecation process. --
[Issue 17852] cannot compile phobos on freebsd
https://issues.dlang.org/show_bug.cgi?id=17852 Jonathan M Davis changed: What|Removed |Added Status|NEW |RESOLVED CC||issues.dl...@jmdavisprog.co ||m Resolution|--- |INVALID --- Comment #2 from Jonathan M Davis --- So, what's the bug then? dmd, phobos, etc. are written to build with GNU's make on POSIX systems, and Digital Mars' make on Windows. That means using gmake on FreeBSD rather than make. The wiki should be updated to reflect the fact that gmake is needed on FreeBSD (or probably any POSIX system that isn't Linux), but that's not a bug in Phobos or dmd or any of that. Using BSD make for FreeBSD would mean either having different makefiles for FreeBSD and Linux rather than sharing them like we do now, or it would mean forcing Linux users to install and use BSD's make. --
[Issue 17507] Associative Array range operations should be marked @safe
https://issues.dlang.org/show_bug.cgi?id=17507 Steven Schveighoffer changed: What|Removed |Added See Also||https://issues.dlang.org/sh ||ow_bug.cgi?id=17108 --
[Issue 17108] Associative array byKeyValue is unsafe
https://issues.dlang.org/show_bug.cgi?id=17108 Steven Schveighoffer changed: What|Removed |Added See Also||https://issues.dlang.org/sh ||ow_bug.cgi?id=17507 --
[Issue 17281] std.format.format should not allow nonsensical format specifiers
https://issues.dlang.org/show_bug.cgi?id=17281 Lucia Cojocaru changed: What|Removed |Added CC||lucia.mcojoc...@gmail.com Assignee|nob...@puremagic.com|lucia.mcojoc...@gmail.com --
[Issue 17333] Disallow concat of string with integer enum
https://issues.dlang.org/show_bug.cgi?id=17333 Lucia Cojocaru changed: What|Removed |Added CC||lucia.mcojoc...@gmail.com Assignee|nob...@puremagic.com|lucia.mcojoc...@gmail.com --
[Issue 17108] Associative array byKeyValue is unsafe
https://issues.dlang.org/show_bug.cgi?id=17108 Lucia Cojocaru changed: What|Removed |Added CC||lucia.mcojoc...@gmail.com Assignee|nob...@puremagic.com|lucia.mcojoc...@gmail.com --
[Issue 17769] dmd accepts conversion from shared(int)* to int* when value comes from method
https://issues.dlang.org/show_bug.cgi?id=17769 Lucia Cojocaru changed: What|Removed |Added CC||lucia.mcojoc...@gmail.com Assignee|nob...@puremagic.com|lucia.mcojoc...@gmail.com --
[Issue 16064] std.experimental.allocator.dispose can't be used in @nogc blocks
https://issues.dlang.org/show_bug.cgi?id=16064 Simen Kjaeraas changed: What|Removed |Added Status|NEW |RESOLVED CC||simen.kja...@gmail.com Resolution|--- |DUPLICATE --- Comment #1 from Simen Kjaeraas --- This is the same bug as 15246, 17297 and 17592, just in a different guise. *** This issue has been marked as a duplicate of issue 17592 *** --
[Issue 17592] destroy isn't marked @nogc when the class destructor is marked as @nogc
https://issues.dlang.org/show_bug.cgi?id=17592 Simen Kjaeraas changed: What|Removed |Added CC||b2.t...@gmx.com --- Comment #1 from Simen Kjaeraas --- *** Issue 16064 has been marked as a duplicate of this issue. *** --
[Issue 17853] Switch statement without braces only works with one case
https://issues.dlang.org/show_bug.cgi?id=17853 Lucia Cojocaru changed: What|Removed |Added CC||lucia.mcojoc...@gmail.com Assignee|nob...@puremagic.com|lucia.mcojoc...@gmail.com --
[Issue 15798] std.algorithm.mutation.copy takes target by value
https://issues.dlang.org/show_bug.cgi?id=15798 Eduard Staniloiu changed: What|Removed |Added CC||edi33...@gmail.com Assignee|nob...@puremagic.com|edi33...@gmail.com --
[Issue 17415] std.conv.emplace does not forward arguments correctly
https://issues.dlang.org/show_bug.cgi?id=17415 Eduard Staniloiu changed: What|Removed |Added CC||edi33...@gmail.com Assignee|nob...@puremagic.com|edi33...@gmail.com --
[Issue 16064] std.experimental.allocator.dispose can't be used in @nogc blocks
https://issues.dlang.org/show_bug.cgi?id=16064 Eduard Staniloiu changed: What|Removed |Added CC||edi33...@gmail.com Assignee|nob...@puremagic.com|edi33...@gmail.com --
[Issue 16285] IAllocator crash
https://issues.dlang.org/show_bug.cgi?id=16285 Eduard Staniloiu changed: What|Removed |Added CC||edi33...@gmail.com Assignee|nob...@puremagic.com|edi33...@gmail.com --
[Issue 17619] [REG2.072] Wrong debug line information with single line loops
https://issues.dlang.org/show_bug.cgi?id=17619 --- Comment #5 from Walter Bright --- > Introduced by https://github.com/dlang/dmd/pull/2867 Uh-oh! 574 lines and 21 files changed! --
[Issue 17619] [REG2.072] Wrong debug line information with single line loops
https://issues.dlang.org/show_bug.cgi?id=17619 Walter Bright changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #4 from Walter Bright --- Looking at the x86 output: :enter010h,0 0004:movdword ptr -010h[EBP],03 000b:movdword ptr -0Ch[EBP],3 0012:movEAX,-010h[EBP] 0015:cmpEAX,-0Ch[EBP] 0018:jge$+Fh 001a:movECX,-010h[EBP] 001d:mov-8[EBP],ECX 0020:incdword ptr -8[EBP]4 0023:incdword ptr -010h[EBP]6 0026:jmp short$+FFEBh 0028:xorEDX,EDX 002a:mov-4[EBP],EDX 002d:movEAX,EDX 002f:leave7 0030:ret Line 6 is the `int bad;` line. This happens also if the foreach is rewritten as a for loop. --
[Issue 17797] [REG 2.073.2] double print to stdout when reading stdin in another thread
https://issues.dlang.org/show_bug.cgi?id=17797 ag0ae...@gmail.com changed: What|Removed |Added CC||ag0ae...@gmail.com --- Comment #2 from ag0ae...@gmail.com --- (In reply to Walter Bright from comment #1) > It happens on Win32 as well, which uses the DMC runtime library, not > Microsoft's. So it is not specific to the Microsoft runtime library. It *only* happens with the DMC runtime. People are running 64-bit Windows, but they're not using 64-bit dmd. I just tested in a virtual machine with -m32mscoff and didn't see duplicated lines. --
[Issue 7957] std.functional untuple/untupleReversed too
https://issues.dlang.org/show_bug.cgi?id=7957 RazvanN changed: What|Removed |Added CC||razvan.nitu1...@gmail.com Assignee|nob...@puremagic.com|razvan.nitu1...@gmail.com --
[Issue 6156] thread mbox conditions are only notified when the mailbox is emptied.
https://issues.dlang.org/show_bug.cgi?id=6156 RazvanN changed: What|Removed |Added CC||razvan.nitu1...@gmail.com Assignee|nob...@puremagic.com|razvan.nitu1...@gmail.com --
[Issue 17781] printing "Shared libraries are not yet supported on OSX." should be optional
https://issues.dlang.org/show_bug.cgi?id=17781
--- Comment #2 from Walter Bright ---
There are two messages:
// no support for multiple images yet
// take the sections from the last static image which is the executable
if (_isRuntimeInitialized)
{
fprintf(stderr, "Loading shared libraries isn't yet supported on
Darwin.\n");
return;
}
else if (_sections.modules.ptr !is null)
{
fprintf(stderr, "Shared libraries are not yet supported on
Darwin.\n");
}
Neither match the issue subject. Which message are you referring to, or is it
both?
--
[Issue 17781] printing "Shared libraries are not yet supported on OSX." should be optional
https://issues.dlang.org/show_bug.cgi?id=17781 Walter Bright changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #1 from Walter Bright --- If they work 100%, why make the message optional, instead of just eliminating it? --
[Issue 17797] [REG 2.073.2] double print to stdout when reading stdin in another thread
https://issues.dlang.org/show_bug.cgi?id=17797 Walter Bright changed: What|Removed |Added CC||bugzi...@digitalmars.com Component|dmd |phobos Hardware|x86 |All --- Comment #1 from Walter Bright --- It happens on Win32 as well, which uses the DMC runtime library, not Microsoft's. So it is not specific to the Microsoft runtime library. I suspect it is a Phobos problem, not a compiler issue, and changed the category accordingly. --
[Issue 10131] To remove duplicates and keep order
https://issues.dlang.org/show_bug.cgi?id=10131 RazvanN changed: What|Removed |Added CC||razvan.nitu1...@gmail.com Assignee|nob...@puremagic.com|razvan.nitu1...@gmail.com --
[Issue 10240] It should be possible to check exists and isDir/isFile with a single stat call
https://issues.dlang.org/show_bug.cgi?id=10240 RazvanN changed: What|Removed |Added CC||razvan.nitu1...@gmail.com Assignee|nob...@puremagic.com|razvan.nitu1...@gmail.com --
[Issue 11135] Nullable(T, T nullValue) does not support NaN
https://issues.dlang.org/show_bug.cgi?id=11135 RazvanN changed: What|Removed |Added Status|NEW |RESOLVED CC||razvan.nitu1...@gmail.com Resolution|--- |FIXED --- Comment #4 from RazvanN --- It seems that this is a "forgot to close bug". Closing as fixed. --
[Issue 11129] multiSort doesn't work with std.container.Array
https://issues.dlang.org/show_bug.cgi?id=11129 RazvanN changed: What|Removed |Added Status|NEW |RESOLVED CC||razvan.nitu1...@gmail.com Resolution|--- |WORKSFORME --- Comment #2 from RazvanN --- Cannot reproduce on Ubuntu 16.04 64-bit, development branch git HEAD. Closing as WORKSFORME. --
[Issue 14794] Add optional position parameter to std.file.read
https://issues.dlang.org/show_bug.cgi?id=14794 RazvanN changed: What|Removed |Added CC||razvan.nitu1...@gmail.com Assignee|nob...@puremagic.com|razvan.nitu1...@gmail.com --
[Issue 6450] struct tm definition too short in std.c.linux.linux
https://issues.dlang.org/show_bug.cgi?id=6450 RazvanN changed: What|Removed |Added Status|NEW |RESOLVED CC||razvan.nitu1...@gmail.com Resolution|--- |INVALID --- Comment #1 from RazvanN --- The code in the initial bug report has been moved to druntime in src/core/stdc/time.d and it seems to implement the tm struct according to the one in glibc. After looking into the gtime_r function in glibc it looks like it does initialize the tm struct values, but it uses some other internal variables, so maybe it does fill 56 bytes of data, but not all are belonging to the tm struct. Closing as invalid. Reopen if I am missing something. --
