[Issue 18953] Win32: extern(C++) struct destructor not called correctly through runtime
https://issues.dlang.org/show_bug.cgi?id=18953 --- Comment #1 from Rainer Schuetze --- Probalby happens because TypeInfo_Struct.destroy doesn't use the expected __thiscall calling convention: https://github.com/dlang/druntime/blob/master/src/object.d#L2010 --
[Issue 18953] New: Win32: extern(C++) struct destructor not called correctly through runtime
https://issues.dlang.org/show_bug.cgi?id=18953
Issue ID: 18953
Summary: Win32: extern(C++) struct destructor not called
correctly through runtime
Product: D
Version: D2
Hardware: x86
OS: Windows
Status: NEW
Severity: normal
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: r.sagita...@gmx.de
import core.stdc.stdio;
extern(C++)
struct S
{
int x;
~this() { printf("~S %x\n", x); }
}
void main()
{
S[] arr = new S[3];
arr[1].x = 1;
arr[2].x = 2;
arr.length = 1;
assumeSafeAppend(arr); // destroys arr[1] and arr[2]
printf("done\n"); // arr[0] destroyed by final GC later
}
The expected output is:
~S 2
~S 1
done
~S 0
Works for win64, but for win32 (both -m32 and -m32mscoff) I get
~S c0b831ff
~S c0b831ff
done
~S c0b831ff
--
[Issue 8161] give an error for invalid property functions
https://issues.dlang.org/show_bug.cgi?id=8161 --- Comment #12 from Jonathan M Davis --- I'd advise against relying on @property for any kind of metaprogramming at this point given that it doesn't actually have anything to do with whether the function can be or is used as a property and that its future in the language is uncertain. I don't think that there's any question that we _could_ do something more with @property, and it may yet be salvaged to do something useful related to properties, but whatever that may be really needs to be designed and then gotten past Walter and Andrei - and that means a DIP. Certainly, the idea that @property defines what can and can't be used as a property function is dead at this point. --
[Issue 8161] give an error for invalid property functions
https://issues.dlang.org/show_bug.cgi?id=8161
--- Comment #11 from bitwise ---
I think @property could be useful in metaprogramming as a means of saying "This
function acts like a field". Rather than going through all kinds of checks to
see if the symbol was useable as such, it would suffice to check if it's
@property, and then possibly which overloads are present to determine whether
it's read/write/both.
I think a good library implementation could do the same thing though:
enum Accessibility { Read, Write, ReadWrite }
template isUseableAsFieldOf(T, F, Accessibility access = Accessibility.Both)(F
fun) {...}
I would use something like that as a quick way to verify the target symbol of a
serialization function.
--
[Issue 18922] dmd doesn't do substitutions for C++ namespaces in different module/file
https://issues.dlang.org/show_bug.cgi?id=18922 --- Comment #1 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/dmd https://github.com/dlang/dmd/commit/9a1b4467cc175881c5d07f468437a27d5875449f Fix issue 18922: No substitutions for C++ namespaces in different module/file DMD was just comparing the object by their reference instead of their string value. Obviously when a namespace is declared in another module, the reference is different. https://github.com/dlang/dmd/commit/7518facf971ddf0dd2dd5bd8031db5d0782e1fa6 Merge pull request #8332 from Geod24/fix18922 Fix issue 18922: No substitutions for C++ namespaces in different module/file merged-on-behalf-of: Razvan Nitu --
[Issue 18922] dmd doesn't do substitutions for C++ namespaces in different module/file
https://issues.dlang.org/show_bug.cgi?id=18922 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 8161] give an error for invalid property functions
https://issues.dlang.org/show_bug.cgi?id=8161 --- Comment #10 from Jonathan M Davis --- -property was dropped precisely because it was decided to not enforce @property, and the future of @property is very uncertain. The odds are very high that when Walter and Andrei finally get around to deciding what to do with @property that they will simply decide to deprecate it and remove it from the language. It makes no sense to add any kind of enforcement to something that's almost certainly going to be removed from the language. The fact that @property is even still used like it is is a combination of folks using it as documentation about what they intend to be used as a property and the fact that many folks mistakingly think that @property indicates which functions can be used as a property. Enforcing anything about @property at this point risks breaking existing code for something that we're probably not even keeping. If we're going to do anything with @property, it needs to be sorted out in a DIP that then gets official approval from Walter and Andrei. With a good enough argument, maybe they could be convinced to add some sort of enforcement to @property that doesn't affect non-@property functions, but without that, you're talking about potentially breaking code over something that's probably not even going to be staying in the language. That breakage could easily be worth it if we decide that @property is actually going to mean something, but the odds are much higher that it will be removed from the language than that it will be made to mean something useful. --
[Issue 18024] checkedint.Abort should be @safe
https://issues.dlang.org/show_bug.cgi?id=18024 --- Comment #7 from Seb --- See also https://github.com/dlang/phobos/pull/6550 for yet another PR on this problem --
[Issue 18952] std.experimental.checkedint.Saturate prints integral promotion deprecation message
https://issues.dlang.org/show_bug.cgi?id=18952 --- Comment #1 from Seb --- PR https://github.com/dlang/phobos/pull/6549 --
[Issue 18952] New: std.experimental.checkedint.Saturate prints integral promotion deprecation message
https://issues.dlang.org/show_bug.cgi?id=18952
Issue ID: 18952
Summary: std.experimental.checkedint.Saturate prints integral
promotion deprecation message
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P1
Component: phobos
Assignee: nob...@puremagic.com
Reporter: greensunn...@gmail.com
---
/dlang/dmd/linux/bin64/../../src/phobos/std/experimental/checkedint.d(2184):
Deprecation: integral promotion not done for ~cast(byte)0, use
'-transition=intpromote' switch or ~cast(int)(cast(byte)0)
---
---
import std.experimental.checkedint;
void main()
{
auto x = (cast(byte) 127).checked!Saturate;
assert(x == 127);
x++;
assert(x == 127);
}
---
https://run.dlang.io/is/8QMIT5
--
[Issue 8161] give an error for invalid property functions
https://issues.dlang.org/show_bug.cgi?id=8161 --- Comment #9 from Nick Treleaven --- 1. The text of this issue mentions -property, but I don't see why we shouldn't reject the cases it describes *regardless* of the -property switch. (This is why I removed the switch from the issue title). 2. This is about the *declaration* of nonsensical @property functions, it is not about optional parentheses in calls. --
[Issue 18949] Array literals don't work with betterc
https://issues.dlang.org/show_bug.cgi?id=18949
anonymous4 changed:
What|Removed |Added
Keywords||betterC
Hardware|x86 |All
OS|Windows |All
--- Comment #1 from anonymous4 ---
Technically it needs `in` attribute:
---
void takeArray(in int[] array)
{
}
void bar()
{
takeArray([1, 2, 3]);
}
---
--
[Issue 16037] assigning delegate to a scope variable shouldn't allocate closure
https://issues.dlang.org/show_bug.cgi?id=16037 anonymous4 changed: What|Removed |Added Keywords||betterC Status|RESOLVED|REOPENED See Also||https://issues.dlang.org/sh ||ow_bug.cgi?id=18949 Resolution|FIXED |--- --- Comment #12 from anonymous4 --- Another use case is betterC, which is unlikely to be safe. --
[Issue 18949] Array literals don't work with betterc
https://issues.dlang.org/show_bug.cgi?id=18949 anonymous4 changed: What|Removed |Added See Also||https://issues.dlang.org/sh ||ow_bug.cgi?id=16037 --
[Issue 18951] package static method masked by public static method in class
https://issues.dlang.org/show_bug.cgi?id=18951 Mike Franklin changed: What|Removed |Added Keywords||pull CC||slavo5...@yahoo.com --- Comment #1 from Mike Franklin --- PR: https://github.com/dlang/dmd/pull/8338 --
[Issue 18558] Template alias spec incomplete
https://issues.dlang.org/show_bug.cgi?id=18558 Nick Treleaven changed: What|Removed |Added Keywords||pull URL||https://github.com/dlang/dl ||ang.org/pull/2382 CC||n...@geany.org --
[Issue 8161] give an error for invalid property functions
https://issues.dlang.org/show_bug.cgi?id=8161 --- Comment #8 from Jonathan M Davis --- (In reply to Nick Treleaven from comment #7) > Updated the title. Please give a reason why dmd shouldn't reject invalid > @property functions. The rules for using functions as properties currently have nothing to do with @property, and it's not clear that @property is even going to stay in the language. The plans for @property were dropped in that there are zero plans to enforce it (which includes the removal of -property), and it's not at all clear what's going to happen to it. It currently does very little, and adding any kind of enforcement to it at this point when it's not clear what (if anything) we're going to do with it really doesn't make sense. At this point, Walter and Andrei need to make a decision on what we're going to do with @property - be that on their own or as the result of a DIP. As it stands, @property does almost nothing. Off the top of my head, the list is: 1. It affects the result of typeof (the result is the type of the return value if @property is used, whereas it's the type of the function if @property isn't used). 2. It affects the mangling of the function (including affecting std.traits.functionAttributes). 3. It's not legal to overload a @property function with a non-@property function or vice versa. None of that involves enforcing that @property acts like a property function or that it is used as one, and none of it involves enforcing anything about non-@property functions. When UFCS was introduced, it became _extremely_ popular to leave off parens on function calls, and that killed any plans to enforce @property. That does not mean that we couldn't end up with some kind of enforcement that doesn't restrict what happens with non-@property functions, and maybe some kind of enforcement could be added to restrict the use of the assignment syntax to @property setters in order to make stuff like assigning to writeln illegal, but a DIP is required to sort all of that out, and as I understand it, at this point, Andrei and Walter consider @property to be a serious misstep. So, it really doesn't make sense to try and do anything to @property right now unless that involves writing a DIP with a full plan of what we're going to do with @property. --
[Issue 8161] give an error for invalid property functions
https://issues.dlang.org/show_bug.cgi?id=8161 Nick Treleaven changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|WONTFIX |--- Summary|-property should give an|give an error for invalid |error for invalid property |property functions |functions | --- Comment #7 from Nick Treleaven --- Updated the title. Please give a reason why dmd shouldn't reject invalid @property functions. --
[Issue 8161] -property should give an error for invalid property functions
https://issues.dlang.org/show_bug.cgi?id=8161 Jonathan M Davis changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #6 from Jonathan M Davis --- -property is dead, and anything revolving around changing what @property does (which is almost nothing) really needs a DIP. --
[Issue 8161] -property should give an error for invalid property functions
https://issues.dlang.org/show_bug.cgi?id=8161 Nick Treleaven changed: What|Removed |Added Keywords||pull URL||https://github.com/dlang/dm ||d/pull/8320 --
[Issue 18951] package static method masked by public static method in class
https://issues.dlang.org/show_bug.cgi?id=18951 FeepingCreature changed: What|Removed |Added Summary|static package masked by|package static method |static public in class |masked by public static ||method in class --
[Issue 18951] static package masked by static public in class
https://issues.dlang.org/show_bug.cgi?id=18951 FeepingCreature changed: What|Removed |Added Severity|enhancement |normal --
[Issue 12511] static overloaded function is not accessible
https://issues.dlang.org/show_bug.cgi?id=12511 --- Comment #6 from FeepingCreature --- Filed as https://issues.dlang.org/show_bug.cgi?id=18951 --
[Issue 18951] New: static package masked by static public in class
https://issues.dlang.org/show_bug.cgi?id=18951
Issue ID: 18951
Summary: static package masked by static public in class
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Severity: enhancement
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: default_357-l...@yahoo.de
This issue arises as a result of the fix for issue 12511.
test/A.d:
module test.A;
public class Class
{
package static void foo(Object) {}
public static void foo() {}
}
test/B.d:
import test.A;
void main()
{
Class.foo(new Object);
}
test/B.d(4): Error: function test.A.Class.foo() is not callable using argument
types (Object)
What happens is that the 12511 fix pulls up the public foo() because it's the
most visible foo in Class. package foo, which is also perfectly visible from
test.B, has a lower visibility and is thus ignored.
--
[Issue 18950] New: Std.zip vulnerable to arbitrary file write
https://issues.dlang.org/show_bug.cgi?id=18950
Issue ID: 18950
Summary: Std.zip vulnerable to arbitrary file write
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Severity: major
Priority: P1
Component: phobos
Assignee: nob...@puremagic.com
Reporter: cpic...@openmailbox.org
Created attachment 1702
--> https://issues.dlang.org/attachment.cgi?id=1702=edit
POC ZIP file to test path traversal on a POSIX system
Researchers from Snyk have recently disclosed a wide-spread vulnerability they
call "Zip Slip" which affects many libraries in many languages.
The original blog here: https://snyk.io/research/zip-slip-vulnerability
The issue is two-fold:
- Many ZIP libraries do not check for path traversal in file names (things like
../../../../../../../tmp/test for example.
- Many applications using those libraries decompress the files to the disk
without checking the names either.
Zip files typically cannot contain those names normally, but they can be easily
hand-crafted. This allows an attacker to leverage an application's use of
std.zip to create or overwrite arbitrary files using the application's rights.
This typically results in arbitrary code execution.
Phobos std.zip authorizes such path traversal by default and doesn't provide
any facility to do the right thing easily.
Arguably this is a consummer issue: it is possible to use Phobos right by
checking the name before writting the file, but requiring conciousness of the
issue is asking a lot on the user. As Snyk's research shows, most vulnerable
applications they found were written in Java and they attribute that to the
lack of primitives doing the right thing in Java libraries.
To demonstrate the issue here is a test script written at 99% using the example
from std.zip that is the baseline for a good use of the library. In attachment
you will find a zip file that will try to create an empty file to
../../../../../../../../../../tmp/not-good.
```D
import std.digest.crc;
import std.file;
import std.stdio;
import std.zip;
void main(string[] args) {
// read a zip file into memory
auto zip = new ZipArchive(read(args[1]));
writeln("Archive: ", args[1]);
writefln("%-10s %-8s Name", "Length", "CRC-32");
// iterate over all zip members
foreach (name, am; zip.directory)
{
// print some data about each member
writefln("%10s %08x %s", am.expandedSize, am.crc32, name);
assert(am.expandedData.length == 0);
// decompress the archive member
zip.expand(am);
assert(am.expandedData.length == am.expandedSize);
std.file.write(name, am.expandedData);
}
}
```
```SH
sh-4.4$ dmd --version
DMD64 D Compiler v2.080.0-dirty
Copyright (C) 1999-2018 by The D Language Foundation, All Rights Reserved
written by Walter Bright
sh-4.4$ ls /tmp/not-good
ls: cannot access '/tmp/not-good': No such file or directory
sh-4.4$ ls
test.d test.zip
sh-4.4$ rdmd test.d test.zip
Archive: test.zip
Length CRC-32Name
0 ../../../../../../../../../../tmp/not-good
sh-4.4$ ls /tmp/not-good
/tmp/not-good
```
I think std.zip should do at least one of the following:
- Refuse files with names resulting in path traversal by default (a flag to
enable that behaviour could be used if projects actually use that, but it seems
dubious);
- Provide a function to decompress a file to the disk and not in memory which
also checks for path traversal.
--
[Issue 18945] immutable variable is used as if it's an enum
https://issues.dlang.org/show_bug.cgi?id=18945 --- Comment #11 from David Bennett --- (In reply to Simen Kjaeraas from comment #10) > (In reply to David Bennett from comment #9) > > https://run.dlang.io/is/zZWdIQ > > > > Only works currently with static immutable > > What do you mean? It works perfectly with enum: > https://run.dlang.io/is/3Xy5pI So it does... I'm sure I tried that a while back (years maybe) and it didn't so I had been avoiding it. --
[Issue 12511] static overloaded function is not accessible
https://issues.dlang.org/show_bug.cgi?id=12511
FeepingCreature changed:
What|Removed |Added
CC||default_357-l...@yahoo.de
--- Comment #5 from FeepingCreature ---
This PR has created a new problem.
test/Foo.d:
module test.Foo;
class Foo {
package static void foo(Object) { }
public static void foo() { }
}
test/test.d:
module test.test;
import test.Foo;
void fun() { Foo.foo(new Object); }
Expected: a call to foo
Outcome: test/test.d(7): Error: function test.Foo.Foo.foo() is not callable
using argument types (Object)
Bisect points at the PR.
--
[Issue 18945] immutable variable is used as if it's an enum
https://issues.dlang.org/show_bug.cgi?id=18945 --- Comment #10 from Simen Kjaeraas --- (In reply to David Bennett from comment #9) > https://run.dlang.io/is/zZWdIQ > > Only works currently with static immutable What do you mean? It works perfectly with enum: https://run.dlang.io/is/3Xy5pI --
[Issue 16692] New debug experience: possible to execute pure functions during expression evaluation?
https://issues.dlang.org/show_bug.cgi?id=16692 --- Comment #11 from Rainer Schuetze --- I'm currently still trying to figure out how to deal with slices and delegates, because they are returned in a way incompatible with any C++ ABI. There is currently no annotation of pure or const in the debug info, and I have so far avoided adding a demangler. Not sure about automatically showing them for any class or struct, maybe I should have a look how it works in C#. I'm currently leaning towards making them available for explicit use in some kind of visualizer, so you can also avoid repeating the same information by property functions and private members when showing the struct. --
