[Issue 14617] PTHREAD_MUTEX_INITIALIZER does not work on OSX
https://issues.dlang.org/show_bug.cgi?id=14617 --- Comment #3 from Steven Schveighoffer schvei...@yahoo.com --- A neat advantage over C is that we can define the .init value so we don't need such an initializer. In fact, core.posix.pthread defines PTHREAD_MUTEX_INITIALIZER as pthread_mutex_t.init. However, there is an issue, because core/sys/posix/sys/types.d is not included in the build. So if I define a new init, it won't be found (tried it). I also tried updating the PTHREAD_MUTEX_INITIALIZER in pthread.d, and that also is not found. So we need some Makefile updates in order to fix this. And I'm not sure we want to do that. Thoughts? --
[Issue 14616] ddoc shows std.socket.UnixAddress as abstract
https://issues.dlang.org/show_bug.cgi?id=14616 Steven Schveighoffer schvei...@yahoo.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Steven Schveighoffer schvei...@yahoo.com --- PR has been pulled. --
[Issue 14617] PTHREAD_MUTEX_INITIALIZER does not work on OSX
https://issues.dlang.org/show_bug.cgi?id=14617
--- Comment #4 from Andrei Alexandrescu and...@erdani.com ---
Thanks for all this, folks! Steve, can't you just insert the proper defaults
where the struct is defined? I.e. we have in src/core/sys/posix/sys/types.d the
following definition at line 594:
struct pthread_mutex_t
{
c_long __sig;
byte[__PTHREAD_MUTEX_SIZE__]__opaque;
}
Changing it to the following makes at least my tests pass:
struct pthread_mutex_t
{
c_long __sig = 0x32AAABA7;
byte[__PTHREAD_MUTEX_SIZE__]__opaque;
}
--
[Issue 11098] template instance x cannot use local y as parameter to non-global template z
https://issues.dlang.org/show_bug.cgi?id=11098
--- Comment #2 from r...@rcorre.net ---
This is still around in DMD2.067.
The UFCS trick is a nice work-around on the callee side.
You can also work around it on the caller side with:
struct S {
void f(alias F)() { }
}
void main() {
static int fun(int i) { return i; }
S.init.f!(fun);
}
Both are less than ideal though.
--
[Issue 14618] New: can break immutable with inout and a delegate
https://issues.dlang.org/show_bug.cgi?id=14618
Issue ID: 14618
Summary: can break immutable with inout and a delegate
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Keywords: accepts-invalid
Severity: normal
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: ag0ae...@gmail.com
struct S
{
immutable(int)* p;
}
inout(int)* f(inout S s)
{
inout(int)* result;
auto dg = (inout(int)* p) {result = p;};
dg(s.p);
return result;
}
void main()
{
immutable int x = 42;
immutable int* p = x;
assert(*p == 42); /* passes */
scope(exit) assert(*p == 42); /* fails */
int* m = f(S(p)); /* uh-oh */
*m = 13; /* writing over immutable *p */
}
--
[Issue 14610] [REG2.067] 'null this' assertion missing in 2.067
https://issues.dlang.org/show_bug.cgi?id=14610 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added CC||bugzi...@digitalmars.com Hardware|x86_64 |All --- Comment #2 from Walter Bright bugzi...@digitalmars.com --- https://github.com/D-Programming-Language/dmd/pull/4678 --
[Issue 14571] [REG2.064] Large static arrays seem to lock up DMD
https://issues.dlang.org/show_bug.cgi?id=14571 --- Comment #18 from Manu turkey...@gmail.com --- (In reply to Walter Bright from comment #6) I'll fix this, but you should know that this necessarily creates large sections in the executable file of repeated data. For such large arrays, it is better to allocate and initialize them on program startup. I reported it because it was a bug, and I agree it's not excellent practise. That said though, Vladimir has already presented my thoughts; it's perfectly valid code, people do it, code like this exists. In my case, I am porting C++ code, and it's quite a lot of code... it is difficult to refactor and port at the same time. Regarding .init, this is something I never really thought about too much, but I'm now really concerned. I have been concerned by classinfo's in the past, but somehow init slipped under my radar. I think a few things need to be considered and/or possible. 1. How do I disable the existence of 'init' for a type? It's conceivable that I want to produce an uninitialised (and uninitialisable) type, like these ones I have here. 2. Any type with a static array naturally has an unreasonably large .init value; what optimisations are possible with relation to init? Can they be alocated+synthesised at init (*cough*) time, rather than built into the exe? An array is a series of repeated elements, so storing that full array in the binary is not only wasteful, but can only lead to disaster when people put a static array as a member of a type, and the length is large, or perhaps is fed from a 3rd party who doesn't have this specific consideration in mind (nor should they). 3. Can D effectively link-strip .init when it is un-referenced? How can we make this possible if there is something preventing it? I'd love to spend some time working towards D binaries being the same predictable size as C/C++ binaries. For some reason, despite my efforts, I always seem to end up with D binaries that are easily 10 times the size of their counterpart C binary. Infact, I constantly find myself in the surprising situation where I create a D interface for a C lib, which simply declares extern(C)'s along with minimal D code for adaptation, no actual functional D code in sight, and the .lib it produces is significantly larger than the entire C lib that it represents. I have never taken the time to explore the problem, I suspect it's just classinfo's and init values... are there other known bloat inducing problems? The way globals work on modern CPUs is you are not saving any execution time by using static data. Large static arrays is an artifact of FORTRAN. This isn't about execution time, it's about perfectly valid code that looks completely benign causing an unexpected explosion to your binary. Not all programmers are aware or conscious of this sort of thing. It shouldn't be so simple for an unexpecting (junior?) programmer to make a mess like this, and likely not understand what they've done, or that they've even done it at all. --
[Issue 14617] PTHREAD_MUTEX_INITIALIZER does not work on OSX
https://issues.dlang.org/show_bug.cgi?id=14617
Martin Nowak c...@dawg.eu changed:
What|Removed |Added
CC||c...@dawg.eu
--- Comment #1 from Martin Nowak c...@dawg.eu ---
According to the headers, the initializer should be {0x32AAABA7}.
http://www.opensource.apple.com/source/Libc/Libc-167/pthreads.subproj/pthread.h
--
[Issue 14611] socket.localAddress fails on Unix sockets with longer path ( 13 characters)
https://issues.dlang.org/show_bug.cgi?id=14611 Vladimir Panteleev thecybersha...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED CC||thecybersha...@gmail.com Resolution|--- |FIXED --
[Issue 14571] [REG2.064] Large static arrays seem to lock up DMD
https://issues.dlang.org/show_bug.cgi?id=14571 --- Comment #19 from Vladimir Panteleev thecybersha...@gmail.com --- (In reply to Manu from comment #18) 1. How do I disable the existence of 'init' for a type? I think that if you make sure that all of the initial values are zero bytes, the compiler won't generate a .init block. Instead, the TypeInfo will have a null .init pointer, and the runtime will use that as a clue to simply do a memset instead of copying over the .init data when allocating new types. You might be able to also use this to ensure that your complex types aren't accidentally creating .init blocks. 2. Any type with a static array naturally has an unreasonably large .init value; what optimisations are possible with relation to init? Can they be alocated+synthesised at init (*cough*) time, rather than built into the exe? Not at the moment, AFAIK. 3. Can D effectively link-strip .init when it is un-referenced? How can we make this possible if there is something preventing it? Each .init would need to be in its own section to allow linker garbage collection. DMD doesn't seem to do this at the moment, though (at least not on Win32/Win64). Whether to put things in individual sections is usually a trade-off between link time and resulting executable size. It would be great if DMD at least gave the user some control over this. gcc has e.g. -ffunction-sections and -fdata-sections. I'd love to spend some time working towards D binaries being the same predictable size as C/C++ binaries. For some reason, despite my efforts, I always seem to end up with D binaries that are easily 10 times the size of their counterpart C binary. I agree, bloated executables are not nice. This becomes a real problem with proprietary/closed-source applications, since then the compiler is pulling in code and data that is never actually used, and which should not be present in the published executable. I have never taken the time to explore the problem, I suspect it's just classinfo's and init values... are there other known bloat inducing problems? Yes. - Static constructors pull in everything they reference. - Object.factory requires that all classes that the compiler sees must be instantiatable, which means pulling in their vtables, invariants, virtual methods, and all their dependencies. - Many things which could be emitted in separate sections are put in one section. As a result, anything that's referenced within that section pulls in everything else from it, and all their dependencies. - There are probably other problems. This is generally one of the more neglected aspects of D and the current implementations. People working on embedded D stuff are constantly running into the above problems as well. --
[Issue 14617] PTHREAD_MUTEX_INITIALIZER does not work on OSX
https://issues.dlang.org/show_bug.cgi?id=14617
Steven Schveighoffer schvei...@yahoo.com changed:
What|Removed |Added
CC||schvei...@yahoo.com
--- Comment #2 from Steven Schveighoffer schvei...@yahoo.com ---
According to testing:
Stevens-MacBook-Pro:testd steves$ cat pthreadm.cpp
#include pthread.h
#include stdio.h
int main(int argc, char *argv[])
{
pthread_mutex_t x = PTHREAD_MUTEX_INITIALIZER;
unsigned char *b = (unsigned char *)x;
unsigned char *e = (unsigned char *)((x) + 1);
while(b != e)
printf(%02x , (int)*b++);
printf(\n);
}
Stevens-MacBook-Pro:testd steves$ ./pthreadm
a7 ab aa 32 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00
So that jives with Martin's research. I'll see about a PR.
--
[Issue 11098] template instance x cannot use local y as parameter to non-global template z
https://issues.dlang.org/show_bug.cgi?id=11098 r...@rcorre.net changed: What|Removed |Added CC||r...@rcorre.net --
