Re: [Issue 2423] New: Erroneous unreachable statement warning
[EMAIL PROTECTED] wrote:
http://d.puremagic.com/issues/show_bug.cgi?id=2423
Summary: Erroneous unreachable statement warning
Product: D
Version: 1.035
Platform: Other
OS/Version: All
Status: NEW
Keywords: diagnostic
Severity: regression
Priority: P2
Component: DMD
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
Consider the following function:
void foo() {
do {
if (false)
return 1;
} while (true);
}
Compiling with -w, results in
warning - whiletrue.d(6): Error: statement is not reachable
Minimized from a module in Tango, meaning Tango does not compile with warnings
on.
This regression was introduced in DMD 1.032.
Why is that wrong? "return 1" looks unreachable to me.
Re: [Issue 2436] New: Unexpected OPTLINK termination
[EMAIL PROTECTED] wrote: http://d.puremagic.com/issues/show_bug.cgi?id=2436 Summary: Unexpected OPTLINK termination Product: D Version: 2.020 Platform: PC OS/Version: Windows Status: NEW Keywords: link-failure Severity: normal Priority: P2 Component: DMD AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] optlink fails to link an object file compiled with dmd 2.020 with -g or -gc switch. CL: link test,,,user32+kernel32/co/noi; I don't think that's an OPTLINK bug -- that obj file seems to be defective. And it's a really complicated obj file! Provide the source code for the smallest case which reproduces the problem. Is it the same as #1439?
Re: [Issue 2436] New: Unexpected OPTLINK termination
Max Samukha wrote: On Thu, 06 Nov 2008 11:42:01 +0100, Don <[EMAIL PROTECTED]> wrote: [EMAIL PROTECTED] wrote: http://d.puremagic.com/issues/show_bug.cgi?id=2436 Summary: Unexpected OPTLINK termination Product: D Version: 2.020 Platform: PC OS/Version: Windows Status: NEW Keywords: link-failure Severity: normal Priority: P2 Component: DMD AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] optlink fails to link an object file compiled with dmd 2.020 with -g or -gc switch. CL: link test,,,user32+kernel32/co/noi; I don't think that's an OPTLINK bug -- that obj file seems to be defective. Then I think it's both dmd and optlink bug. The former is buggy because it produces invalid object file. The latter cannot gracefully recover from invalid input, so it's buggy as well. I checked again, and the obj file seems to be OK. So I'm wrong about that -- it's just an OPTLINK problem. And it's a really complicated obj file! Provide the source code for the smallest case which reproduces the problem. Changing/removing seemingly arbitrary stuff makes the error disappear. I don't have a smaller example yet. Yeah. But it probably won't get fixed unless you can simplify it. Mind you, OPTLINK is unlikely to get fixed, anyway. But maybe Walter can change DMD slightly to work around the optlink bug. Is it the same as #1439? #1439 shows that something bad happens when the symbol length is a particular length (out-by-1 error?). I think this is quite likely to be the same issue, since you have so many templates in there.
Re: [Issue 1977] integral arithmetic operation only on int?
[EMAIL PROTECTED] wrote:
http://d.puremagic.com/issues/show_bug.cgi?id=1977
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|INVALID |
--- Comment #5 from [EMAIL PROTECTED] 2008-11-22 08:44 ---
(In reply to comment #4)
It's not ridiculous at all. The compiler cannot tell what values will be
possibly passed to f, and the range of byte and short are sufficiently small to
make overflow as frequent as it is confusing and undesirable.
Why is this also flagged (no overflow possible):
short f(byte i) {
byte t = 1;
short o = t - i;
return o;
}
The community has insisted for a long time to tighten integral operations, and
now that it's happening, the tightening is reported as a bug :o).
But it's pretty inconsistent. If I add two random ints together, I will get an
overflow in 25% of cases, why is that not flagged?
I think the restriction is too tight. People expect to do math on homogeneous
types without having to cast the result, as they do with ints. And I'll say I
was not one of the people asking for this 'feature'. I'm not sure where that
came from.
Personally I think having to insert a cast makes the code more
error-prone. The cure is worse than the disease.
Consider also that with the original code, the compiler could install
debug-time asserts on any such narrowing conversion. Once you insert a
cast, that's impossible, since the language doesn't distinguish between
(a) 'I know that is OK' casts, (b) 'I want to pretend that this is a
different type' casts, and (c) 'I want you to change this into another
type' casts.
Compiler checks should only be inserted for case (a) and (c).
Re: crash D1 compiler
Simen Kjaeraas wrote:
On Sun, 01 Feb 2009 13:01:09 +0100, Zorran wrote:
This code crash D1 compiler (v1.039)
import std.stdio;
void main()
{
string ss="sample";
printf("%s", cast(char*)(ss+"\0") );
}
===
Indeed it does. Now of course, ss + "\0" makes no sense, but the
compiler still should not crash.
To correctly concatenate two strings, use the ~ operator. Also, to
convert a D string to a C string (char *), use toStringz, which
automagically adds the terminating null. Your program would then look
like this:
void main() {
string ss = "sample";
printf("%s", toStringz(ss));
}
--
Simen
I've added this as bug #2637
Re: D2 phobos BigInt bug
dsimcha wrote:
== Quote from ZHOU Zhenyu (rin...@goozo.net)'s article
BigInt b = "10";
foreach( i; 1..20 ){
b*=10;
writeln(b*b);
}
system: Windows
CPU: Intel Core2 Duo T7250 2.00GHz
result:
1
100
1
100
1
100
81553255926290448384
100
1
100
1
100
1
100
1
9981553255926290448384
1
9981553255926290448384
1
Yep, I can reproduce that on Windows on an Athlon 64 X2. You're _not_ just
going
crazy. Please file a Bugzila.
I don't think that will ever get fixed (unless you make a patch
yourself). Phobos BigInt was created by Janice, and she seems to have
completely disappeared. I'm working on Tango BigInt, which is completely
independent, and will replace Phobos BigInt eventually. ( == as soon as
we get a common namespace to put it into). I don't think anyone is
interested in debugging Phobos BigInt.
Re: D demoscene compo
BCS wrote: Hello ponce, Source code will be released soon under the WTFPL LOL, now /that's/ a license I can work with! Why isn't there a version of that with non-offensive wording There's a hundred nearly-identical software licenses out there, but that's the only one I've seen that actually tries to be public domain.
Re: D demoscene compo
Clay Smith wrote: Don wrote: BCS wrote: Hello ponce, Source code will be released soon under the WTFPL LOL, now /that's/ a license I can work with! Why isn't there a version of that with non-offensive wording There's a hundred nearly-identical software licenses out there, but that's the only one I've seen that actually tries to be public domain. You can relicense it however you want to. Yes, but that involves creating a new license. Which is the worst possible choice.
Re: D demoscene compo
Christopher Wright wrote: Don wrote: Clay Smith wrote: Don wrote: BCS wrote: Hello ponce, Source code will be released soon under the WTFPL LOL, now /that's/ a license I can work with! Why isn't there a version of that with non-offensive wording There's a hundred nearly-identical software licenses out there, but that's the only one I've seen that actually tries to be public domain. You can relicense it however you want to. Yes, but that involves creating a new license. Which is the worst possible choice. No, you can take a WTFPL work and include it in a GPL'd work without changing the license. You can't, however, sue someone for violating the GPL if they use only the WTFPL portions of the GPL'd work, because you don't own the copyright, and therefore you lack both standing in the court and the ability to restrict others' usage of the work. No, I mean I want to release code under the same conditions as the WTFPL license, but with less offensive wording. I can't do this without creating a new license. Every other license seems to have a silly "this notice may not be removed" clause. I'm only including a license for the benefit of the users, not for myself. With all the stuff people say about how there are legal ambiguities with public domain, I just find it unbelievable that there's no "formalized public domain" license.
Re: D demoscene compo
Joel C. Salomon wrote: Don wrote: Why isn't there a version of that with non-offensive wording There's a hundred nearly-identical software licenses out there, but that's the only one I've seen that actually tries to be public domain. DO AS YE WILL PUBLIC LICENSE Version 1, March 2000 Everyone is permitted to copy and distribute verbatim or modified copies of this license document, and changing it is allowed as long as the name is changed. TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION 0. Do as ye will. Satisfied? ☺ —Joel Salomon No. Googling for it produced no hits. Creating yet another license is unacceptable.
Re: [Issue 2920] New: recursive templates blow compiler stack
BCS wrote: Hello d-bugm...@puremagic.com, http://d.puremagic.com/issues/show_bug.cgi?id=2920 Summary: recursive templates blow compiler stack ReportedBy: bugzi...@digitalmars.com I was about to mark this as Invalid with a comment that Walter has said that this is not going to be fixed (the error is correct, that stack /did/ get blown)... Then I noticed Walter Reported it. Not so, the bug is that there is no error message. For the first case, there's no error message, for the other cases, there's an error message on Windows, but not on Linux. BTW, (1) the text is mine -- I forwarded it to Walter as part of a list of crashes. (2) if it were not to be fixed, it should be WONTFIX rather than INVALID.
Re: [Issue 3423] Destructor and postblit don't get copied to the header file when using -H
d-bugm...@puremagic.com wrote: http://d.puremagic.com/issues/show_bug.cgi?id=3423 Leandro Lucarella changed: What|Removed |Added CC||llu...@gmail.com Summary|The Bartosz Blocker |Destructor and postblit ||don't get copied to the ||header file when using -H --- Comment #1 from Leandro Lucarella 2009-10-20 08:45:57 PDT --- I've taken the freedom to change the title because it was very informative really. I hope you don't mind, but using a good title for the bug report help people to find the correct bug and avoids duplicates and bug maintenance overhead. Actually, the new title is NOT more informative. Your title makes it sounds like this is innocuous. If I'd used your title, you probably wouldn't have noticed it... I'm worried it'll get lost now. Thanks for the patch BTW :)
Re: [Issue 3549] Bypassing initializers with goto -- Is this a bug?
Rory McGuire wrote:
d-bugm...@puremagic.com wrote:
http://d.puremagic.com/issues/show_bug.cgi?id=3549
Don changed:
What|Removed |Added
CC||clugd...@yahoo.com.au
Summary|Is this a bug? |Bypassing initializers with
||goto -- Is this a bug?
--- Comment #1 from Don 2009-11-24 20:00:14 PST ---
I don't know. That's an interesting case for safe D. In safe D, either the
initializers must be executed, or bypassing them must be banned. The code
below
is an example of memory corruption. But as @safe isn't yet implemented (so far
it only checks for use of asm, AFAIK), it's not a bug yet.
-
class Foo { int x; }
@safe
void foo()
{
goto xxx;
Foo a = new Foo();
xxx:
a.x = 8;
}
I would say that it is definitely a bug, if D is supposed to initialize memory
to zero when it is allocated.
The assignments obviously replace the initialize to zero, which makes sense
except in this example. I can only think of goto being the problem how else
could you skip the initialization.
Perhaps the compiler should initialize to zero if there is a goto even if the
initialization is overridden except for void initialization.
This should even be allowed in D1 let alone D2 or SafeD.
:) just my two cents.
The quote that Stewart found makes it completely clear: this is an
illegal use of goto, and it should fail to compile.
Nice and simple.
Re: ieeeFlags do not work properly
Torben Hagerup wrote:
Run under D version 2.037, the program below runs through without raising any
assert exceptions. This shows an erratic behavior with respect to ieeeFlags
that is hardly intended. Other ieeeFlags also work (or, rather, do not work) in
unexpected ways.
This isn't a bug.
import std.math;
void main() {
// The execution leads to no assert errors
real a,b=3.5;
resetIeeeFlags();
assert(!ieeeFlags.divByZero); // so far no zero division
a=3.5/0.0L; // but now ...
This occurred at compile time. At runtime, this became:
a = real.infinity;
assert(a==real.infinity); // yes, exactly
assert(!ieeeFlags.divByZero); // perhaps not, after all
b/=0.0L; // once more, the same, really
It's not the same. This is a runtime division by zero.
assert(b==real.infinity); // yes, the same
assert(ieeeFlags.divByZero); // oops, not the same after all?
}
Re: [Issue 4623] Non-integer type allowed as static array size
d-bugm...@puremagic.com wrote: http://d.puremagic.com/issues/show_bug.cgi?id=4623 --- Comment #5 from Iain Buclaw 2010-10-01 11:18:20 PDT --- I haven't ran dstress using the DMD compiler. I think I stumbled upon the case somewhere from an archived message on the ML that probably got forgotten about. Ah, OK. I wouldn't go as far as saying all compiler ICE bugs are fixed just yet (I raised an issue recently with CTFE with a patch supplied, for example), though they certainly are very far and few between now. I was only referring to the ICE bugs in dstress.
Re: [Issue 5006] 'pure' unenforced in a nested function
d-bugm...@puremagic.com wrote: http://d.puremagic.com/issues/show_bug.cgi?id=5006 Stewart Gordon changed: What|Removed |Added Keywords||accepts-invalid CC||s...@iname.com --- Comment #1 from Stewart Gordon 2010-10-07 04:33:04 PDT --- Please remember to assign keywords to bug reports. To everybody reading this: Please look through issues you've reported and check for missing keywords. Thanks Stewart. There are currently 395 bugs with no keywords!! I use keywords in most of my searches, so bugs without keywords tend to get overlooked.
Re: assertion failure '!vthis->csym' on line 698 in file 'glue.c'
Benjamin Thaut wrote: Hi, when I compile the current state of my project, I get the following assertion failure: '!vthis->csym' on line 698 in file 'glue.c' I tried to reproduce this in a smaller scale, but it only appears in this very special case. The project currently contains 72 source files and it only happens when compiling all of them using a rsp file. (Using the console command VisualD produces + dmd 2.049) Should I issue a ticket and upload the complete project so that this bug can be traced down? That sounds like bug 4129.
Re: error importing std.intrinsic on linux Digital Mars D Compiler v2.008
Guillaume Chatelet wrote: Alright my first post is almost unreadable so restarting with the http version... Hope it's going to be better. Why are you using version 2.008??? It was one of the first 'proof of concept' alpha test versions. It wasn't intended for serious use. Any version prior to about 2.040 was useful only for finding the most severe compiler bugs.
Re: [Issue 3276] Recursion broken by alias template parameter
d-bugm...@puremagic.com wrote: http://d.puremagic.com/issues/show_bug.cgi?id=3276 --- Comment #3 from Shin Fujishiro 2010-11-02 22:11:39 PDT --- The patch passed dmd, druntime and phobos tests. It couldn't pass the broken test (runnable/interpret.d) though. What do you mean, the broken test? It needs to pass, unless you have modified the file from the one in svn. (It fails on Linux with -O, but that is not part of the test).
Re: [Issue 5093] improve error for importing std.c.windows.windows
d-bugm...@puremagic.com wrote: http://d.puremagic.com/issues/show_bug.cgi?id=5093 --- Comment #3 from simon 2010-11-15 11:03:49 PST --- Created an attachment (id=812) PATCH against rev 755: implement a module import backtrace for static assert Implements a module import back-trace for static asserts. This ought to be implemented for non-static asserts as well, but that probably involves mucking about in the back end and I can't be bothered diving into that at the mo. Cool! In cases where it's imported from inside a static if, this is fantastic. Ideally, it would only do the module trace starting from the last instantiated template. (Which would mean that in many cases, it wouldn't appear at all). I think this should be applied to all template instantiation back traces.
Re: [Issue 5093] improve error for importing std.c.windows.windows
Jonathan M Davis wrote: On Monday 15 November 2010 12:49:05 Don wrote: d-bugm...@puremagic.com wrote: http://d.puremagic.com/issues/show_bug.cgi?id=5093 --- Comment #3 from simon 2010-11-15 11:03:49 PST --- Created an attachment (id=812) PATCH against rev 755: implement a module import backtrace for static assert Implements a module import back-trace for static asserts. This ought to be implemented for non-static asserts as well, but that probably involves mucking about in the back end and I can't be bothered diving into that at the mo. Cool! In cases where it's imported from inside a static if, this is fantastic. Ideally, it would only do the module trace starting from the last instantiated template. (Which would mean that in many cases, it wouldn't appear at all). I think this should be applied to all template instantiation back traces. I expect that you meant to post a comment to the bug rather than post on the bug list... - Jonathan M Davis You expect wrong.
Re: [Issue 6785] New: Wrong error message from pragma(msg) of failed instantiation
On 08.10.2011 00:41, d-bugm...@puremagic.com wrote:
http://d.puremagic.com/issues/show_bug.cgi?id=6785
Summary: Wrong error message from pragma(msg) of failed
instantiation
Product: D
Version: D2
Platform: x86
OS/Version: Windows
Status: NEW
Keywords: diagnostic
Severity: minor
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc
--- Comment #0 from bearophile_h...@eml.cc 2011-10-07 15:41:00 PDT ---
This is wrong D2 code (there is no foo):
void main() {
enum int x = 1;
pragma(msg, foo!x);
}
DMD 2.056head gives a partially wrong error message, that contains a "__error":
test.d(3): Error: template instance foo!(x) template 'foo' is not defined
__error
[Replying in the ng, because bugzilla is down]
The "__error" isn't part of the error message. It's coming from the
pragma(msg): it's printing foo!x, and that's an error, so it prints
"__error".
The real bug is that the pragma msg is still displayed, even when an
error occurs while evaluating it. Maybe it should give an error
test.d(3): Error: template instance foo!(x) template 'foo' is not defined
test.d(3): Error: parameter for pragma(msg) must be a string
Re: [Issue 8660] New: Unclear semantics of array literals of char type, vs string literals
On 14/09/12 14:50, monarch_dodra wrote:
On Friday, 14 September 2012 at 11:28:04 UTC, Don wrote:
--- Comment #0 from Don 2012-09-14 04:28:17
PDT ---
Array literals of char type, have completely different semantics from
string
literals. In module scope:
char[] x = ['a']; // OK -- array literals can have an implicit .dup
char[] y = "b";// illegal
A second difference is that string literals have a trailing \0. It's
important
for compatibility with C, but is barely mentioned in the spec. The
spec does
not state if the trailing \0 is still present after operations like
concatenation.
I think this is the normal behavior actually. When you write "char[] x =
['a'];", you are not actually "newing" (or "dup"-ing) any data. You are
just letting x point to a stack allocated array of chars.
I don't think you've looked at the compiler source code...
The dup is in e2ir.c:4820.
So the
assignment is legal (but kind of unsafe actually, if you ever leak x).
Yes it's legal. In my view it is a design mistake in the language.
The issue now is how to minimize the damage from it.
On the other hand, you can't bind y to an array of immutable chars, as
that would subvert the type system.
This, on the other hand, is legal.
char[] y = "b".dup;
I do not know how to initialize a char[] on the stack though (Appart
from writing ['h', 'e', 'l', ... ]). If utf8 also gets involved, then I
don't know of any workaround.
I think a good solution would be to request the "m" prefix for literals,
which would initialize them as "mutable":
x = m"some mutable string";
A second difference is that string literals have a trailing \0. It's
important
for compatibility with C, but is barely mentioned in the spec. The
spec does
not state if the trailing \0 is still present after operations like
concatenation.
CTFE can use either, but it has to choose one. This leads to odd effects:
string foo(bool b) {
string c = ['a'];
string d = "a";
if (b)
return c ~ c;
else
return c ~ d;
}
char[] x = foo(true); // ok
char[] y = foo(false); // rejected!
This is really bizarre because at run time, there is no difference
between
foo(true) and foo(false). They both return a slice of something
allocated on
the heap. I think x = foo(true) should be rejected as well, it has an
implicit
cast from immutable to mutable.
Good point. For anybody reading though, the actual code example should be
enum char[] x = foo(true); // ok
enum char[] y = foo(false); // rejected!
No it should not.
The code example was correct. These are static variables.
I think the best way to clean up this mess would be to convert char[]
array
literals into string literals whenever possible. This would mean that
string
literals may occasionally be of *mutable* type! This would means that
whenever
they are assigned to a mutable variable, an implicit .dup gets added
(just as
happens now with array literals). The trailing zero would not be duped.
ie:
A string literal of mutable type should behaves the way a char[] array
literal
behaves now.
A char[] array literal of immutable type should behave the way a
string literal
does now.
I think this would work with my "m" suggestion
Not necessary. This is only a question about what happens with the
compiler internals.
