[Issue 24358] New: std.digest on array of arrays surprisingly shallow
https://issues.dlang.org/show_bug.cgi?id=24358 Issue ID: 24358 Summary: std.digest on array of arrays surprisingly shallow Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P1 Component: phobos Assignee: nob...@puremagic.com Reporter: schvei...@gmail.com std.digest when run on an array of arrays uses a blunt cast to ubyte[], which means it digests the pointer/lengths, not the contents of the subarrays. This can be surprising, and in some cases, leave a time bomb for future uses, because strings are interned. For example: `assert (md5Of(["hello", "world"]) == md5Of(["hello", "world"]));` passes `assert (md5Of(["hello", "world"]) == md5Of(["hello".dup, "world"]));` fails. - I propose that digest on an array of items which contain pointers does not just cast to ubyte[], but rather uses the (slower) range mechanism of applying digest to each item individually. --
[Issue 24349] object noreturn link is missing
https://issues.dlang.org/show_bug.cgi?id=24349 --- Comment #3 from Jim Balter --- I guess I should have been more explicit. It isn't just that the link is missing ... this is also wrong: alias noreturn = Nn; I doubt that the fix for the link fixed this ... is there some way to look at the docs for master? --
[Issue 24345] Issue with `alias this = xyz` inside structs.
https://issues.dlang.org/show_bug.cgi?id=24345 timon.g...@gmx.ch changed: What|Removed |Added CC||timon.g...@gmx.ch --- Comment #1 from timon.g...@gmx.ch --- This works with `-preview=fixAliasThis`. Maybe we can close this as WORKSFORME? --
[Issue 23868] Compiler-generated opAssign has very high stack frame usage
https://issues.dlang.org/show_bug.cgi?id=23868
Walter Bright changed:
What|Removed |Added
Status|NEW |RESOLVED
CC||bugzi...@digitalmars.com
Resolution|--- |WONTFIX
--- Comment #2 from Walter Bright ---
(In reply to johanengelen from comment #0)
> I believe this implemention of opAssign would solve the problem, as I am 99%
> sure that the semantic difference (dtor call before the assignment) is
> allowed by the spec:
> ```
>ref @system S opAssign(ref S p) return // note I added `ref`
>{
> this.S.~this();
> this = p;
> return this;
>}
> ```
This does not work in the general case. The canonical example is if S is a
ref-counting wrapper around some other object. If the ref count is 1, and p
wraps the same object as `this`, then the wrapped object will get deleted
before it gets copied.
Adding:
@disable ref S opAssign(ref S);
will disable the automatic generation of the assignment operator for S. Note
use of `ref` for both the return and the parameter.
I'm going to close this as WONTFIX because the existing algorithm is the
pedantically correct one, writing a custom one will override the standard
algorithm, and the generating the standard one can be disabled with @disable.
Another solution would be to make `arr` a pointer to the data rather than the
data itself. Which solution to pick depends, of course, on the application.
--
[Issue 23414] Import order emits "Error: no size because of forward references"
https://issues.dlang.org/show_bug.cgi?id=23414 --- Comment #5 from Richard Cattermole --- My assumption has been that this isn't fixable, but worth documenting. Each module has one public declaration a struct. Which in turn uses similar structs in other modules. ASCII, UTF-8, UTF-16, UTF-32 each having a read only slice and a builder. Then there are the raw slices too. Not much you can do to break that up, except for using something like implicitly constructed sum types at the declaration level to break up the dependency. Right now the package module is ensuring the imports are all in the right order and every module goes through that which works. Not ideal, however, I haven't had any further issues so not a bad workaround. --
[Issue 23414] Import order emits "Error: no size because of forward references"
https://issues.dlang.org/show_bug.cgi?id=23414
--- Comment #4 from Walter Bright ---
I would like to fix this, once a smallish test case can be devised. But keep in
mind some things cannot be fixed. At least the compiler issues an error for
those cases. An example:
struct S
{
static if (S.sizeof == 0)
{
int x;
}
}
It's impossible for the compiler to resolve it. While the example looks trivial
and ridiculous, sometimes these cases are hidden behind a thicket of complex
templates.
When module A imports module B, and B also imports A, there's always the
potential for an ordering issue. I try to solve as many as possible, but they
cannot always be fixed. These are commonly the result of two declarations with
a mutual dependence. A solution that works is to refactor A and B so that the
mutually dependent portions are extracted and placed into module C. Then, A and
B import C.
--
[Issue 11080] assert(`string`) should be forbidden
https://issues.dlang.org/show_bug.cgi?id=11080 Nick Treleaven changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |DUPLICATE --- Comment #30 from Nick Treleaven --- Issue 14387 was filed later but that got the PR, so marking this as a duplicate. *** This issue has been marked as a duplicate of issue 14387 *** --
[Issue 14387] Disallow string literals as assert conditions
https://issues.dlang.org/show_bug.cgi?id=14387 Nick Treleaven changed: What|Removed |Added CC||temta...@gmail.com --- Comment #7 from Nick Treleaven --- *** Issue 11080 has been marked as a duplicate of this issue. *** --
[Issue 18788] static arrays with a length specified at runtime should dynamically allocate on the stack
https://issues.dlang.org/show_bug.cgi?id=18788 Nick Treleaven changed: What|Removed |Added CC||n...@geany.org --- Comment #9 from Nick Treleaven --- (In reply to Mike Franklin from comment #5) > Another way of achieving the same result would be to make a `scope`d dynamic > array allocate on the stack For the record, this got implemented in Issue 22306. Probably this can be closed now. --
[Issue 24357] String spec needs updating
https://issues.dlang.org/show_bug.cgi?id=24357 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #1 from Dlang Bot --- @ntrel created dlang/dlang.org pull request #3761 " [spec/arrays] Improve string docs" fixing this issue: - Fix Bugzilla Issue 24357 - String spec needs updating https://github.com/dlang/dlang.org/pull/3761 --
[Issue 24357] New: String spec needs updating
https://issues.dlang.org/show_bug.cgi?id=24357 Issue ID: 24357 Summary: String spec needs updating Product: D Version: D2 Hardware: x86_64 OS: Linux Status: NEW Severity: normal Priority: P1 Component: dlang.org Assignee: nob...@puremagic.com Reporter: n...@geany.org This section needs a general clean up, fixing typos and more links: https://dlang.org/spec/arrays.html#strings > char[] strings are in UTF-8 format. wchar[] strings are in UTF-16 format. > dchar[] strings are in UTF-32 format. The above is a bit confusing as strings always have immutable elements. > Since strings, however, are not 0 terminated in D This should be moved to the zero-terminated literals section. char* p = [3]; // pointer to 4th element char* p = str; // pointer to 1st element The second declaration no longer compiles. PR incoming. --
[Issue 24355] Slice copy with static arrays incorrect bounds checking
https://issues.dlang.org/show_bug.cgi?id=24355 --- Comment #5 from Nick Treleaven --- Spec for above: > A string literal converts to a static array rvalue of the same or longer > length https://dlang.org/spec/expression.html#string_literals --
[Issue 24355] Slice copy with static arrays incorrect bounds checking
https://issues.dlang.org/show_bug.cgi?id=24355 --- Comment #4 from Nick Treleaven --- > An array *initializer* is allowed to have fewer elements. Actually that only seems to apply when the initializer is a string literal. char[4] s = [1]; // error char[4] s = "a"; // OK --
[Issue 24355] Slice copy with static arrays incorrect bounds checking
https://issues.dlang.org/show_bug.cgi?id=24355 Nick Treleaven changed: What|Removed |Added CC||n...@geany.org --- Comment #3 from Nick Treleaven --- char[32] id = 0; const(char)* str = "hello"; id = str[0 .. 6]; The error is correct by the spec: > A static array can be assigned from a dynamic array - the data is copied. The > lengths must match https://dlang.org/spec/arrays.html#assignment char[4] id; id = "hello asdad"; This causes a runtime error. You're right it could be caught at compile-time. Assigning an array literal with excess elements is a compile error. char[32] id = "hello"; An array *initializer* is allowed to have fewer elements. If there are excess elements, for an array literal it's a compile error, for a string literal, it's a runtime error as above. --
