Re: Mistake of opening of a file having a name in cp1251.
According to the documentation https://msdn.microsoft.com/de-de/library/yeby3zcb.aspx, _wfopen already takes a wide-character string, not an ANSI string. So return _wfopen(name.tempCStringW(), mode.tempCStringW()); would be the correct way. All these weird ansi versions are Windows 98 era legacy, they aren't commonly used anymore. Please also try whether your C runtime implements _wfopen correctly or otherwise your file name is somehow broken (maybe it's on a FAT filesystem etc). For that, please try opening it in a C program using _wfopen(_T(filenamehere), r); For comparison, try to create a file with the same name on an NTFS filesystem and try opening it in a C program using _wfopen(_T(filenamehere), r); Does that work? Also, what version and flavour (DMD, GDC, LDC) of D do you use?
Re: signal handling
Hmmm... Just found https://www.securecoding.cert.org/confluence/display/seccode/void+SIG33-C.+Do+not+recursively+invoke+the+raise%28%29+function, the bottom part Compliant Solution (POSIX) does raise() in the signal handler. However, I can't find it in the POSIX standard at http://pubs.opengroup.org/onlinepubs/009695399/functions/sigaction.html. But https://www.securecoding.cert.org/confluence/display/seccode/SIG30-C.+Call+only+asynchronous-safe+functions+within+signal+handlers lists the async-safe functions. raise() and sigaction() are in it. But _Exit() is, too.
Re: internal compiler error with immutable
Hi Ketmar,
Hi Ali,
thank you!
On Sunday, 8 February 2015 at 09:42:14 UTC, Ali Çehreli wrote:
spawn(user, cucs, ubyte(3));
^to!
Other than that, it works.
(The Attributes are basically literal constants but the library
cannot know which are used in a given program - but probably not
more than 20 or so are used realistically - it would be a UI
design faux pas for content to be - like XP start menu - in
hundreds of different yellowish greenish colors)
Unfortunately, I can't seem to get opEquals to work with
immutable (or const, for that matter) either. (does compile,
though)
The obvious
bool opEquals(immutable(C) b) immutable {
return value == b.value;
}
doesn't work. Probably have to override the one from Object ?
Even though I don't really use polymorphism here.
override bool opEquals(Object b) immutable {
return value == (cast(immutable(C)) b).value;
}
Nope. Doesn't work (or compile) either.
As a test, I added
foreach (ubyte i; 0 .. 10) {
if (i % 2) {
cucs.add(new immutable(C)(i));
assert(new immutable(C)(i) == new immutable(C)(i));
// this
}
}
to your program but the assertion fails after the changes (if it
even compiles).
Hmm, maybe I should just store immutable struct C pointers? Yep,
that works, although then I have to compare for equality by *a ==
*b... oh well, I use opEquals comparison only internally after
all.
internal compiler error with immutable
Hi,
I'm trying to use immutable class instances and that seems to be
really difficult.
For example, with the following program I get an internal
compiler error:
cut-
import std.outbuffer : OutBuffer;
import std.typecons : Rebindable;
enum Attrkey : ubyte {
Fgcolor,
Bgcolor,
}
enum MAX_COMPRESSED_ATTRS = 128U;
alias Codes = Rebindable!(Attrs)[MAX_COMPRESSED_ATTRS];
static shared Codes codes;
private class Attrsp {
immutable(Attrsp) next;
Attrkey key;
ubyte value;
private this(Attrkey key, ubyte value, immutable(Attrsp) next) {
this.next = next;
this.key = key;
this.value = value;
}
// FIXME allow comparing the entire chain for equality.
private immutable void print(OutBuffer destination /*
destination */) {
destination.write(Attrs();
destination.write(cast(ubyte) key); // FIXME .toString()
destination.write(, );
destination.write(value);
destination.write(, \n);
if(this.next is null)
destination.write(null);
else
next.print(destination);
destination.write());
}
override immutable string toString() {
auto destination = new OutBuffer();
print(destination);
return destination.toString();
}
// TODO add newless static opCall which also does compression?
/*doesn't work static immutable immutable(Attrsp) opCall(Attrkey
key, ubyte value, immutable(Attrsp) next) {
return new immutable Attrsp(key, value, next);
}*/
alias Code = ubyte;
/* Compresses the given attributes into 1 Byte, if possible.
Returns MAX_COMPRESSED if it's not possible. */
static Code compress(immutable(Attrs) node) { // FIXME make
thread safe
ubyte i;
for(i = 0U; i MAX_COMPRESSED_ATTRS; ++i) {
if(codes[i] is null) {
codes[i] = node;
return i;
} else if(codes[i] == node)
return i;
}
return i; // tell that it didn't work.
}
static immutable(Attrs) uncompress(Code value) {
assert(value = 0U value MAX_COMPRESSED_ATTRS);
return codes[value];
}
}
alias Attrs = immutable(Attrsp);
cut-
gdc A.d
cc1d: ../../src/gcc/d/dfrontend/statement.c:293:
ErrorStatement::ErrorStatement(): Assertion `global.gaggedErrors
|| global.errors' failed.
cc1d: internal compiler error: Aborted
Please submit a full bug report,
with preprocessed source if appropriate.
See file:///usr/share/doc/gcc-4.9/README.Bugs for instructions.
gdc (Debian 4.9.1-19) 4.9.1
cut-
What I'm trying to do is save space by putting often-used Attrs
into an array and just compressing references to those into 1
Byte in the other data structures where it's used (these other
data structures are not thread-local). Why do I need Rebindable
to begin with? I'm not even trying to modify the contents of the
instance, I'm just trying to assign another one to the array slot
(actually not even another one - it was null before).
Re: signal handling
Hi rlonstein,
I've now read up on the opengroup pages about signal handling
(which references POSIX), and apparently it goes like this:
A signal can be delivered to a specific thread or to a process.
If it's delivered to a process, a random thread of that process
will receive it. If it's delivered to a thread, that thread will
receive it. sigaction() thus seems to be required per-thread. The
handler of a random thread will usually be called.
I've now settled on:
- per thread, register signal handler using sigaction with a mask
that blocks all the cleanup signals while the handler is running.
Remember the old handler in TLS variable.
- in the signal handler, clean up (just use the write syscall to
make it sane), then use sigaction to reinstall the old signal
handler, and then call raise().
Seems to work fine so far. Not sure whether it's safe to raise()
inside a signal handler. Calling raise() without reinstalling the
old signal handler is a very bad idea, I tried. Interesting is
that, after reinstalling the old signal handler, I can raise()
inside the signal handler even though it's blocked. It probably
gets queued in the kernel for the thread. Then the handler
returns and it processes the queue, calling the old handler. So
win win?
See
http://svn.nomike.com/playground/trunk/L1/D/TUI/Terminalclient.d,
bottom. Note that I don't distinguish between whether I'm in the
correct thread or not since for my use case it's not necessary.
The FD is always the same and who cares who resets the terminal...
I have very little state so I'm doing
equally little beside freeing extern handles.
Yeah, same for me, really.
Setting a global flag and testing it didn't really prove
adequate and littered the checks everywhere
Yeah,I don't think that EINTR and flag-checking is even safe.
What if you check the flag (and see nothing happened) and then go
back to the loop and block (in read() or whatever), and right
after the flag checking, unbeknowst to you the signal handler
sets the flag, returns, and only then you block in read()? You'd
block forever.
Do you know signalfd() ?
I know how it is with external libaries, they always block at the
silliest of times. But I've had one (OKAPI) which gave me the FD
back, so I could select() on a bunch FDs in my mainloop. In that
case, signalfd() was nice since it showed up as a normal read
ready in select(), i.e. as a normal event source. Might be
worth a try in your case?
Like this, in pseudo-code:
while (!error) {
auto readyfd = select([signalfd, externalfd]);
if (readyfd == signalfd)
... signal (would have) happened, handle it
else if (readyfd == externalfd)
vendor_read_chunk();
else ...
}
so I'm thinking now of leveraging std.signals but I'm not sure
that will be reliable.
Hmm, I don't know that one yet.
Re: internal compiler error with immutable
Hi, I've filed it with gdcproject.org before reading your reply. Will it be forwarded to issues.dlang.org or should I file it there as well? Also, it seems there's a new DMD release underway right now, does it still happen with that? (I tried but can't get it to build - doesn't seem to support ARMHF target)
signal handling
Hi, if I want to clean up inside a signal handler and then exit the process (as it would have without me handling it), what do I do? Can I exit() inside a signal handler or should I use a more direct quit now function? (after all, it could have been in the middle of relinking the free list when the signal arrived) Do I reinstall the previous signal handler and then abort() ? If I want to store the previous signal handler, do I have to store in a shared variable ? If I have multiple threads, what will happen to the other threads? Will it join() them and hang or will it kill them as well or will it just stop the thread that received the signal? Which thread did receive the signal?
BitArray crash
Hi,
I'm trying to use BitArray instead of rolling my own. But how
does one use it?
I tried:
import std.bitmanip : BitArray;
int main() {
BitArray b;
b[2] = true;
return 0;
}
$ gdc l.d
$ gdb a.out
(gdb) r
Program received signal SIGSEGV, Segmentation fault.
0x00438f88 in std.bitmanip.BitArray.opIndexAssign()
(this=..., b=true,
i=2) at ../../../../src/libphobos/src/std/bitmanip.d:604
Huh?
(gdc-4.8 (Ubuntu 4.8.2-19ubuntu1) 4.8.2)
I think I have to set length first. At least an example at the
docs of bitsSet() halfway down the page does it...
Threads and stdio and HANDLE
Hello,
I'm trying to write some toy examples using threads in D.
Is the std.stdio.File thread-local or shared? Is flockfile used
when I synchronize on it?
I tried checking phobos myself and found some things I don't get
(in stdio.d):
alias FLOCK = flockfile;
this(this) { @trusted
if(fps_)
FLOCK(fps_);
}
What is this(this)?
If I want to write to stdout from a thread, do I use
LockingTextWriter? File? shared File? Does each thread have the
same stdout? (Ok I checked, they have the same address, so
probably. Phobos has it as __gshared stdout, aha)
Also, in order to avoid all that (also I want to be able to set
Console text attributes on Windows), I tried to use the lowlevel
I/O next:
For UNIX, the fds are per-process and just integers. So I know
there that I can just pass around the int fd to any threads.
For Windows, if I use GetStdHandle, is the resulting HANDLE valid
for threads other than the one that called GetStdHandle ? Because
the HANDLE is a pointer but doesn't have shared. Does one know
for Windows handles in general which are per-thread and which are
per-process ?
Finally, I'm trying to come to grips with shared:
The first use of shared is to signal to the compiler that it
should not store the variable in thread-local storage. But when I
acquire a lock (using synchronized, say), I'm supposed to cast
away the shared, right? Does it then still know that it's not
thread-local (but that I ensured that nobody else accesses it for
the time being)?
What does specifying shared class or shared struct do?
Re: How to prevent sensitive information is displayed when the extension 'exe' is modified to 'txt' on windows?
Hi, sigh, so I have to annoy you with the truth... On Tuesday, 6 January 2015 at 17:15:28 UTC, FrankLike wrote: How to prevent sensitive information is displayed when the extension 'exe' is modified to 'txt' on windows? By not putting it in in the first place. Everything else is no good in the end. Encryption, xoring, everything is almost useless for that purpose. If you build a exe ,such as which can get Data from DataBase,when you modify the exe's extension to 'txt', and you open it by notepad.exe (on windows),you will find the info,it's important for me,so how to stop the info to display ? Do you mean find the password? (I don't see that field in your example) Remove the password field and let the operating system care of auth forwarding to the database server. Then create all the users on your database and make sure to set their permissions right. That way, your computer and the database server will negotiate whether they let the user in and it's their problem. I always do it like that. Also, that way, you already have existing permission management tools (in the dbms). If you don't want to grant them permission on the table, don't. Create a view with the harmless info and grant them permission to that. Likewise, if you want to completely abstract it away, create stored procedures in the database as the interface for your app and grant them only permission to execute them. Trusted_Connection=Yes\ Well, now I don't see what the problem you are trying to solve is. You are doing as outlined above already. So what is the problem you are trying to solve?
opDispatch
Hi,
I'm trying to learn how opDispatch works. Unfortunately, a very
simple example already doesn't work (error: no property 'a' for
type 'Foo'):
import std.stdio : writeln;
struct X {
int a;
}
class Foo {
X value;
template opDispatch(string s) {
value.opDispatch!(s) opDispatch;
}
}
int main() {
auto f = new Foo;
writeln(f.a);
return 0;
}
What am I missing?
Is there another way to make Foo forward all unknown things to X ?
Re: opDispatch
I tried to make it even simpler to get to the core of the problem
I'm having:
...
template opDispatch(string s) {
alias value.a opDispatch;
}
The compiler then complains:
error: need 'this' for 'a' of type 'int'
I can only think: And? It's right there... it's a class instance,
it has 'this'.
Re: opDispatch
Tobias: Thanks! Your version works. But now it's read-only.
Re: opDispatch
Adam: Thanks, that was very illuminating! I tried and these work indeed. Is there a function like opDispatch which can be used (at compile time) to refer to something by name whether or not it's custom? (to access something like value.a safely. mixin and string concatenation looks like would have problems with special characters easily) (Something like getattr(x, a) in Python)
Re: opDispatch
Not sure how that works together with opDispatch. I am not sure why you see safety reasons at compile time though. Hmm, I'm not really worried about safety in this case (in many other slightly different scenarios I am). More worried about strange Unicode characters in fields I have no control over (in other libraries etc) messing it up for no reason.
