[Issue 16193] opApply() doesn't heap allocate closure

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16193

--- Comment #6 from Walter Bright  ---
Not a fix for this bug, but Phobos should be fixed:

https://github.com/dlang/phobos/pull/4787

--

[Issue 15857] incorrect checkimports mismatch for overload sets

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15857

--- Comment #12 from Martin Nowak  ---
Looks like the caching fails for imports because of this
https://github.com/dlang/dmd/blob/82c5682edbd876767d3853bd6fdd2cc70ebfa73b/src/dsymbol.d#L1283
condition.

--

[Issue 15413] Foreach over range with @disable this(this) doesn't work

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15413

Ali Cehreli  changed:

   What|Removed |Added

 CC||acehr...@yahoo.com
Summary|Foreach over range with |Foreach over range with
   |@disable this doesn't work  |@disable this(this) doesn't
   ||work

--

[Issue 16494] cannot find source code for runtime library after brew install in custom directory

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16494

Timothee Cour  changed:

   What|Removed |Added

 CC||timothee.co...@gmail.com

--- Comment #1 from Timothee Cour  ---
was caused by installing linuxbrew on a mounted directory, except that the
$HOME variable was ran on another machine when installed the first time, and
had a different value from the $HOME on the machine where it was run a 2nd
time.

What's weird is that the dmd.conf file existed at the correct location but
DFLAGS defined there were wrong (pointing to old home); not sure why dmd
-v|grep Config would return Config file: (null) in that case

cat $HOMEBREW_PREFIX/etc/dmd.conf
[Environment]
DFLAGS=-I/home/old_name/.linuxbrew/Cellar/dmd/2.071.1/include/dlang/dmd
-L-L/home/old_name/.linuxbrew/Cellar/dmd/2.07
1.1/lib

--

[Issue 16494] New: cannot find source code for runtime library after brew install in custom directory

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16494

  Issue ID: 16494
   Summary: cannot find source code for runtime library after brew
install in custom directory
   Product: D
   Version: D2
  Hardware: x86
OS: Linux
Status: NEW
  Severity: major
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: timothee.co...@gmail.com

When installing brew (via linuxbrew) in a nonstandard directory, dmd can't find
it's config file.

Would be nice if error message pointed out the algorithm to search for
dmd.conf, and the best way to fix this

install_dmd_custom.sh:
```
HOME_temp=/tmp/somedir/
HOME_old=$HOME
mkdir -p $HOME_temp

install_linuxbrew(){
  HOME=$HOME_temp
  ruby -e "$(curl -fsSL
https://raw.githubusercontent.com/Linuxbrew/install/master/install)"
  HOME=$HOME_old
}

export HOMEBREW_PREFIX=$HOME_temp/.linuxbrew/
PATH="$HOMEBREW_PREFIX/bin:$PATH"

ls $HOMEBREW_PREFIX/bin/brew || install_linuxbrew
brew install dmd

rdmd some_file.d
#cannot find source code for runtime library after brew install in custom
directory
```

dmd -v|grep Config: Config file: (null)

--

[Issue 14125] @trusted nested helper functions in std.file

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=14125

--- Comment #79 from Walter Bright  ---
This pull request:

https://github.com/dlang/phobos/pull/4786

will help simplify things in std.file by making some of the machinations to
work with both arrays and ranges unnecessary.

--

[Issue 16493] New: Request for an OS-independent interface to access cryptographically secure pseudo random number generators

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16493

  Issue ID: 16493
   Summary: Request for an OS-independent interface to access
cryptographically secure pseudo random number
generators
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: ajid...@gmail.com

Currently, phobos provides no way to gain platform-independent access to the
operating system's cryptographically secure random number generator.

Such generators are fed with entropy stemming from random hardware events such
as interrupt timing that only the kernel has access to, so most operating
systems implement an API to get random numbers from it.

The current lack of easy CSPRNG access means that developers may make poor
security choices out of either laziness or portability concerns.[1]

CSPRNGs are needed in any function where there is a need for sufficiently
random data in the face of an attacker willing to invest time and effort into
predicting RNG states. This includes uses such as generating password reset
tokens, or generating cryptographic keys. If one does not use a CSPRNG for
password reset tokens, a malicious third party could predict a password reset
token it triggered by sending itself a couple and thus figuring out what the
PRNG state is using off-the-shelf tools.

The implementation varies from platform to platform.

On Linux:
-

For kernel versions below Linux 3.17, random data can be read from
/dev/urandom. However, /dev/urandom is not guaranteed to be initialised with
sufficient entropy early during the boot process. While many distributions
restore the previous RNG state into it and architectures such as x86 usually
provide enough entropy during boot for this to not be a big problem, embedded
platforms might not do so.

However, with kernel 3.17, a new syscall getrandom[2] was added. It allows to
block until at least 128 bits of entropy have been collected. It also does not
require to use a file descriptor, so random data can be acquired even if the
system is running out of fds (such as if an application doing encryption is on
a system that is under attack to try and starve it of fds).

The use of /dev/random on Linux is not needed (I'd link the talk about it if I
could find it at the moment). Essentially, /dev/random's wacky entropy-counting
and blocking is not what most (if not all) applications want, and does not add
any security unless you're talking about early boot (in which case it would do
the same as getentropy if getentropy was to block for initial seeding).

On Windows:
---

Windows offers an API to request CSPRNG data with CryptGenRandom[3]. First, a
CSP needs to be acquired, and the CSP needs to be destroyed after we're done
with it.

On OpenBSD:
---

OpenBSD has a syscall called getentropy[4], which inspired the Linux getrandom
syscall. getentropy does not allow requests for more than 256 bytes of data at
a time. However, it might also be sensible to use arc4random[5], it seems.
Python has a os.urandom module, maybe check what they do.

On other POSIX:
---

Reading from /dev/random is probably a good fallback for systems such as OS X.
I'm not sure what FreeBSD provides, but apparently it also has a /dev/urandom.
Someone please investigate.

Other OSes:
---

Fail loud and proud.

[1] https://github.com/brendanmckenzie/scrypt/issues/1
[2] https://lwn.net/Articles/605828/
[3]
https://msdn.microsoft.com/en-us/library/windows/desktop/aa379942(v=vs.85).aspx
[4] http://man.openbsd.org/getentropy.2
[5] http://man.openbsd.org/arc4random.3

--

[Issue 14414] allow to set hash seed

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=14414

--- Comment #1 from Sobirari Muhomori  ---
Another possibility is to change the hash algorithm adaptively by counting
collisions.

--

[Issue 16492] support @nogc in debug{} blocks

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16492

--- Comment #2 from Manu  ---
It already does that... no?

--

[Issue 13615] stable sort not usable in @safe code

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=13615

Walter Bright  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #4 from Walter Bright  ---
This is working in the latest master.

--

[Issue 15907] Unjustified "is not visible from module" deprecation warning when using getMember trait

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15907

--- Comment #10 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/dlang/phobos

https://github.com/dlang/phobos/commit/b2d0226d4845d69b60ea26f54c1edec36ad08b11
supplemental change for Issue 15907 fix

https://github.com/dlang/phobos/commit/d10780f19544f73907540e98aeee0039807e4578
Merge pull request #4747 from MartinNowak/fix15907

--

[Issue 16492] support @nogc in debug{} blocks

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16492

Gary Willoughby  changed:

   What|Removed |Added

 CC||d...@nomad.so

--- Comment #1 from Gary Willoughby  ---
Perhaps take a look at ignoring `pure` in debug blocks too.

--

[Issue 16139] Attributes of functions inside templates should be inferred

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16139

Walter Bright  changed:

   What|Removed |Added

   Keywords||pull

--- Comment #1 from Walter Bright  ---
https://github.com/dlang/dmd/pull/6130

--

[Issue 13615] stable sort not usable in @safe code

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=13615

Walter Bright  changed:

   What|Removed |Added

   See Also||https://issues.dlang.org/sh
   ||ow_bug.cgi?id=16139

--

[Issue 16139] Attributes of functions inside templates should be inferred

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16139

Walter Bright  changed:

   What|Removed |Added

   See Also||https://issues.dlang.org/sh
   ||ow_bug.cgi?id=13615

--

[Issue 16031] [REG2.071] stale DW.ref.name EH symbol used with -lib and -fPIC

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16031

github-bugzi...@puremagic.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--

[Issue 16031] [REG2.071] stale DW.ref.name EH symbol used with -lib and -fPIC

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16031

--- Comment #4 from github-bugzi...@puremagic.com ---
Commits pushed to stable at https://github.com/dlang/dmd

https://github.com/dlang/dmd/commit/253b94371378a1acdaca26b515366be74b4f35bd
fix Issue 16031 - symbol idx out of bounds w/ multilib and PIC

- the types in the catch handler type tables can reoccur and would use a
  cached DW.ref.name symbol from an older object file
- reset DW.ref.name symbol idx before generating next object file
- fixes EH for .a archives with PIC

https://github.com/dlang/dmd/commit/b551db57c275a58c93745b5d62ca956caca15010
Merge pull request #6129 from MartinNowak/fix16031

fix Issue 16031 - symbol idx out of bounds w/ multilib and PIC

--