Re: No tempFile() in std.file

[Patrick Schluter via Digitalmars-d-learn]

On Wednesday, 17 May 2017 at 05:30:40 UTC, Patrick Schluter wrote:

On Tuesday, 16 May 2017 at 13:56:57 UTC, Jonathan M Davis wrote:

[...]


As your solution doesn't inherently solve the race condition 
associated with temporary files, you could still generate the 
name with a wrapper around tempnam() or tmpnam() (Posix for 
Windows I don't know). This would avoid the double open() of 
the scenario above.


But as Jonathan said above, this is not a good solution in any 
case. In Posix the use the mks*temp() family of functions is 
standard now.

Re: No tempFile() in std.file

[Patrick Schluter via Digitalmars-d-learn]

On Tuesday, 16 May 2017 at 13:56:57 UTC, Jonathan M Davis wrote:
On Tuesday, May 16, 2017 11:19:14 bachmeier via 
Digitalmars-d-learn wrote:

On Monday, 15 May 2017 at 22:38:15 UTC, Jonathan M Davis wrote:
> [...]

That seems perfectly reasonable to me. Couldn't the function 
return both the path and the file in a struct? This is 
something that really should be in Phobos. It's one of those 
little things that makes D a lot less pleasurable to work 
with, at least for anyone needing that functionality.


std.file doesn't have anything to do with File. It only 
operates on entire files at a time, so it wouldn't make sense 
for a function in std.file to return a std.stdio.File. At most 
what would make sense to me would be to have a function in 
std.file which created the file as empty and closed it and then 
returned the file name for the program to then open or do 
whatever else it wants with - which would actually be perfectly 
fine if you then wanted to use std.file.write or similar to the 
file. It's just more annoying if you want a File, because then 
you end up effectively opening the file twice.


- Jonathan M Davis


As your solution doesn't inherently solve the race condition 
associated with temporary files, you could still generate the 
name with a wrapper around tempnam() or tmpnam() (Posix for 
Windows I don't know). This would avoid the double open() of the 
scenario above.

Re: Equivalent to nullptr

[Leonardo via Digitalmars-d-learn]

On Thursday, 4 May 2017 at 04:34:40 UTC, Stanislav Blinov wrote:
In the meantime, you can get around the issue by redeclaring 
the function with another name and loading it manually just 
after calling DerelictSDL2.load():



import derelict.sdl2.sdl;

__gshared SDL_bool function (const(SDL_Point)*, int, 
const(SDL_Rect)*, SDL_Rect*) SDL_EnclosePoints_;


void main()
{
   DerelictSDL2.load();
   DerelictSDL2.bindFunc(cast(void**)_EnclosePoints_, 
"SDL_EnclosePoints");

   // ...
}


Now you'd need to call SDL_EnclosePoints_ instead of 
SDL_EnclosePoints.


Thank you.

Re: D equivalent of C++11's function local static initialization?

[Timothee Cour via Digitalmars-d-learn]

NOTE: curious about both cases:
* thread local
* shared

On Tue, May 16, 2017 at 8:04 PM, Timothee Cour  wrote:
> what's the best D equivalent of C++11's function local static initialization?
> ```
> void fun(){
>   static auto a=[](){
> //some code
>return some_var;
>   }
> }
> ```
>
> (C++11 guarantees thread safety)

D equivalent of C++11's function local static initialization?

[Timothee Cour via Digitalmars-d-learn]

what's the best D equivalent of C++11's function local static initialization?
```
void fun(){
  static auto a=[](){
//some code
   return some_var;
  }
}
```

(C++11 guarantees thread safety)

Re: Cheetah: Keeping track of multiple connected clients

[aberba via Digitalmars-d-learn]

On Tuesday, 16 May 2017 at 21:56:16 UTC, aberba wrote:

On Tuesday, 16 May 2017 at 17:49:07 UTC, bauss wrote:

[...]


It really awesome the way you responded quickly. About 
targeting a client, suppose I have clients A, B, and C.


Message can be broadcast to all using above solution. But in 
case A want to sent message to B and not C, how does server 
detect the specific destination client's id? Does 
client.send(...) allow json string with target id from browser 
client?


I'm trying to find a way to receive meesage in one language 
along with target client's id and send to the target after I 
have translated to another lang.


The client is a browser socket using WebScoket() api. Or does 
cheetah only work with its D client?

Re: Cheetah: Keeping track of multiple connected clients

[aberba via Digitalmars-d-learn]

On Tuesday, 16 May 2017 at 17:49:07 UTC, bauss wrote:

On Tuesday, 16 May 2017 at 16:01:49 UTC, aberba wrote:
Does anyone know how to keep track of multiple clients in 
Cheetah socket lib such that one can directly message a client 
or broadcast to all connected clients.



Something like:

onMessage(... e)
{
...
   // send to all
   e.clients.broadcast (message);

...OR...
   // target a client
e.clients[clientID].send(message);
}

Or any D lib with similar function.


I have now added an internal client-storage to the project.

The server will have a getClientById(size_t) and a getClients() 
which can be used.


Ex.

foreach (client; e.server.getClients())  {
// ... Broadcast to each client here
}

...

e.server.getClientById(clientId).send(...);

Each client will be attached to a clientId when they connect.

The client id is a property of the SocketClient class.

To enable the internal storage you must set storeClients to 
true on the server when initializing it, otherwise the storage 
won't be used.


Ex.

server.storeClients = true;

If you don't want to get latest version of it, then you can 
just make your own storage ex. an associative array and then 
add each client to it when they connect.


Right now dub doesn't seem to be able to trigger a manual 
update on the package, so you might have to fetch the updates 
manually from the Github repository.


https://github.com/bausshf/cheetah/commit/9646fd407d274a94c37dc1b0297541963aeb3e6d


It really awesome the way you responded quickly. About targeting 
a client, suppose I have clients A, B, and C.


Message can be broadcast to all using above solution. But in case 
A want to sent message to B and not C, how does server detect the 
specific destination client's id? Does client.send(...) allow 
json string with target id from browser client?


I'm trying to find a way to receive meesage in one language along 
with target client's id and send to the target after I have 
translated to another lang.

Re: Cheetah: Keeping track of multiple connected clients

[bauss via Digitalmars-d-learn]

On Tuesday, 16 May 2017 at 16:01:49 UTC, aberba wrote:
Does anyone know how to keep track of multiple clients in 
Cheetah socket lib such that one can directly message a client 
or broadcast to all connected clients.



Something like:

onMessage(... e)
{
...
   // send to all
   e.clients.broadcast (message);

...OR...
   // target a client
e.clients[clientID].send(message);
}

Or any D lib with similar function.


I have now added an internal client-storage to the project.

The server will have a getClientById(size_t) and a getClients() 
which can be used.


Ex.

foreach (client; e.server.getClients())  {
// ... Broadcast to each client here
}

...

e.server.getClientById(clientId).send(...);

Each client will be attached to a clientId when they connect.

The client id is a property of the SocketClient class.

To enable the internal storage you must set storeClients to true 
on the server when initializing it, otherwise the storage won't 
be used.


Ex.

server.storeClients = true;

If you don't want to get latest version of it, then you can just 
make your own storage ex. an associative array and then add each 
client to it when they connect.


Right now dub doesn't seem to be able to trigger a manual update 
on the package, so you might have to fetch the updates manually 
from the Github repository.


https://github.com/bausshf/cheetah/commit/9646fd407d274a94c37dc1b0297541963aeb3e6d

Cheetah: Keeping track of multiple connected clients

[aberba via Digitalmars-d-learn]

Does anyone know how to keep track of multiple clients in Cheetah 
socket lib such that one can directly message a client or 
broadcast to all connected clients.



Something like:

onMessage(... e)
{
...
   // send to all
   e.clients.broadcast (message);

...OR...
   // target a client
e.clients[clientID].send(message);
}

Or any D lib with similar function.

Re: No tempFile() in std.file

[Jonathan M Davis via Digitalmars-d-learn]

On Tuesday, May 16, 2017 08:06:13 H. S. Teoh via Digitalmars-d-learn wrote:
> On Tue, May 16, 2017 at 06:56:57AM -0700, Jonathan M Davis via 
Digitalmars-d-learn wrote:
> > On Tuesday, May 16, 2017 11:19:14 bachmeier via Digitalmars-d-learn 
wrote:
> > > On Monday, 15 May 2017 at 22:38:15 UTC, Jonathan M Davis wrote:
> > > > I suppose that we could add a tempFile that did what
> > > > std.stdio.File.scratchFile did but create an empty file and return
> > > > its path rather than returning a File, though that would be a bit
> > > > annoying, since you'd then have to open it to operate on it
> > > > instead of just writing to it. Maybe it would be worth doing
> > > > though given the stupidity blocking std.stdio.File.scratchFile.
>
> [...]
>
> Don't forget that there are security concerns related to this.  Most
> modern OS APIs tend to prefer a temp file creation call that atomically
> (1) generates a unique filename and (2) creates a file with said
> filename with permissions set such that it can only be exclusively used
> by the calling process.
>
> The reason for this is that there is a race condition between the
> generation of the filename and the creation of the file.
[...]

Yes, which is why you use the system call that fails if the file already
exists when you open it. std.stdio.File.scratchFile dealt with all of that
(and AFAIK, did so correctly, though I could have missed something). And
we'd have it in Phobos still if it weren't for the complaints about hello
world's excecutable size. But all of the subtleties around that mess is why
we don't have a std.file.tempFile which simply returns a suggested file
name. You'd _think_ that it would be a simple issue, but unfortunately, it's
not.

- Jonathan M Davis

Re: No tempFile() in std.file

[H. S. Teoh via Digitalmars-d-learn]

On Tue, May 16, 2017 at 08:06:13AM -0700, H. S. Teoh via Digitalmars-d-learn 
wrote:
> On Tue, May 16, 2017 at 06:56:57AM -0700, Jonathan M Davis via 
> Digitalmars-d-learn wrote:
> > On Tuesday, May 16, 2017 11:19:14 bachmeier via Digitalmars-d-learn wrote:
> > > On Monday, 15 May 2017 at 22:38:15 UTC, Jonathan M Davis wrote:
> > > > I suppose that we could add a tempFile that did what
> > > > std.stdio.File.scratchFile did but create an empty file and return
> > > > its path rather than returning a File, though that would be a bit
> > > > annoying, since you'd then have to open it to operate on it
> > > > instead of just writing to it. Maybe it would be worth doing
> > > > though given the stupidity blocking std.stdio.File.scratchFile.
> [...]
> 
> Don't forget that there are security concerns related to this.
[...]

Cf.:
https://cwe.mitre.org/data/definitions/377.html
https://cwe.mitre.org/data/definitions/378.html

https://security.stackexchange.com/questions/34397/how-can-an-attacker-use-a-fake-temp-file-to-compromise-a-program

https://security.openstack.org/guidelines/dg_using-temporary-files-securely.html


T

-- 
A bend in the road is not the end of the road unless you fail to make the turn. 
-- Brian White

[issue std.regex] Fail to match with negative look-ahead assertion when tracking down on a delimiter

[k-five via Digitalmars-d-learn]

Although I wanted to post this context at: 
https://issues.dlang.org/

but even I registered at,I could not login to.

--

As long as I know a little about RegExp, the two below patterns 
are the same:


[ 1 ]:
^(?:[ab]|ab)(.)(?:(?!\1).)+\1$

[ 2 ]:
^(?:ab|[ab])(.)(?:(?!\1).)+\1$

but the number [ 1 ] is false and the [ 2 ] is true, whereas it 
should be true for both:



--
code:

void main( immutable string[] args ){

immutable string str = "ab some-word ";
Regex!( char ) rx = regex( `^(?:[ab]|ab)(.)(?:(?!\1).)+\1$` );
immutable bool b1 = !matchFirst( str, rx ).empty();

writeln( b1 );  // false ( should be true )

rx = regex( `^(?:ab|[ab])(.)(?:(?!\1).)+\1$` );
immutable bool b2 = !matchFirst( str, rx ).empty();

writeln( b2 );  // true

}
--
Demo on regex101.com:
https://regex101.com/r/JV9Ju1/1

the main problem is not related to character class [], since the 
following is true for both:


^(?:ab|[ab])(.)-\1$

^(?:[ab]|ab)(.)-\1$

but with: (.)(?:(?!\1).) it fails if a character-class appears at 
the beginning.


I am not sure but may it is the same bug that GCC below the 
version 5.3.0 have had.


here is my question on Stack-Overflow and found out this bug:
http://stackoverflow.com/questions/42627957/the-same-regex-but-different-results-on-linux-and-windows-only-c

Re: No tempFile() in std.file

[H. S. Teoh via Digitalmars-d-learn]

On Tue, May 16, 2017 at 06:56:57AM -0700, Jonathan M Davis via 
Digitalmars-d-learn wrote:
> On Tuesday, May 16, 2017 11:19:14 bachmeier via Digitalmars-d-learn wrote:
> > On Monday, 15 May 2017 at 22:38:15 UTC, Jonathan M Davis wrote:
> > > I suppose that we could add a tempFile that did what
> > > std.stdio.File.scratchFile did but create an empty file and return
> > > its path rather than returning a File, though that would be a bit
> > > annoying, since you'd then have to open it to operate on it
> > > instead of just writing to it. Maybe it would be worth doing
> > > though given the stupidity blocking std.stdio.File.scratchFile.
[...]

Don't forget that there are security concerns related to this.  Most
modern OS APIs tend to prefer a temp file creation call that atomically
(1) generates a unique filename and (2) creates a file with said
filename with permissions set such that it can only be exclusively used
by the calling process.

The reason for this is that there is a race condition between the
generation of the filename and the creation of the file. On Posix, for
example, an attacker could guess the generated filename and preemptively
create the temp file with unexpected content that may cause the program
to malfunction (usually to trigger another security flaw and thereby
cause arbitrary code execution or privilege escalation, etc.), or to
substitute a symlink that points to a file the program shouldn't be
writing to / reading from (e.g., /etc/passwd).  Actual exploits have
been carried out using this route, hence it's something application
programmers need to be aware of.

(Note that even if your program doesn't do anything directly security
related, it may still be an issue; e.g., it could be a music player but
an attacker could potentially leverage it to read sensitive files by
redirecting file operations or cause a malfunction that gives the
attacker escalation of privileges, e.g., a remote attacker gaining shell
access on a local user account, from which further attacks can be
launched. In this day and age of advanced exploits being widely
disseminated over the 'net, these scenarios are far more likely than
we'd like to think.)


T

-- 
Без труда не выловишь и рыбку из пруда. 

Re: No tempFile() in std.file

[bachmeier via Digitalmars-d-learn]

On Tuesday, 16 May 2017 at 13:56:57 UTC, Jonathan M Davis wrote:

std.file doesn't have anything to do with File. It only 
operates on entire files at a time, so it wouldn't make sense 
for a function in std.file to return a std.stdio.File. At most 
what would make sense to me would be to have a function in 
std.file which created the file as empty and closed it and then 
returned the file name for the program to then open or do 
whatever else it wants with - which would actually be perfectly 
fine if you then wanted to use std.file.write or similar to the 
file. It's just more annoying if you want a File, because then 
you end up effectively opening the file twice.


- Jonathan M Davis


Okay, now I see your point. Your proposal is still a lot better 
than doing nothing.

Re: No tempFile() in std.file

[Jonathan M Davis via Digitalmars-d-learn]

On Tuesday, May 16, 2017 11:19:14 bachmeier via Digitalmars-d-learn wrote:
> On Monday, 15 May 2017 at 22:38:15 UTC, Jonathan M Davis wrote:
> > I suppose that we could add a tempFile that did what
> > std.stdio.File.scratchFile did but create an empty file and
> > return its path rather than returning a File, though that would
> > be a bit annoying, since you'd then have to open it to operate
> > on it instead of just writing to it. Maybe it would be worth
> > doing though given the stupidity blocking
> > std.stdio.File.scratchFile.
>
> That seems perfectly reasonable to me. Couldn't the function
> return both the path and the file in a struct? This is something
> that really should be in Phobos. It's one of those little things
> that makes D a lot less pleasurable to work with, at least for
> anyone needing that functionality.

std.file doesn't have anything to do with File. It only operates on entire
files at a time, so it wouldn't make sense for a function in std.file to
return a std.stdio.File. At most what would make sense to me would be to
have a function in std.file which created the file as empty and closed it
and then returned the file name for the program to then open or do whatever
else it wants with - which would actually be perfectly fine if you then
wanted to use std.file.write or similar to the file. It's just more annoying
if you want a File, because then you end up effectively opening the file
twice.

- Jonathan M Davis

Re: No tempFile() in std.file

[bachmeier via Digitalmars-d-learn]

On Monday, 15 May 2017 at 22:38:15 UTC, Jonathan M Davis wrote:
I suppose that we could add a tempFile that did what 
std.stdio.File.scratchFile did but create an empty file and 
return its path rather than returning a File, though that would 
be a bit annoying, since you'd then have to open it to operate 
on it instead of just writing to it. Maybe it would be worth 
doing though given the stupidity blocking 
std.stdio.File.scratchFile.


That seems perfectly reasonable to me. Couldn't the function 
return both the path and the file in a struct? This is something 
that really should be in Phobos. It's one of those little things 
that makes D a lot less pleasurable to work with, at least for 
anyone needing that functionality.

Re: Atomicity of file-copying/moving

[FreeSlave via Digitalmars-d-learn]

On Tuesday, 16 May 2017 at 08:32:56 UTC, Nordlöw wrote:
What's the status of atomicity of file-copying and -moving 
(renaming) using std.file on different platforms?


Not sure about renaming but copying is not atomic on Posix 
because it does not handle interruption by signal. I opened issue 
about that https://issues.dlang.org/show_bug.cgi?id=17296

Re: No tempFile() in std.file

[Jacob Carlborg via Digitalmars-d-learn]

On 2017-05-16 09:39, Anonymouse wrote:


Linker --gc-sections


IIRC that only works with LDC. With DMD it's possible that it removes 
sections that are used but not directly referenced.


--
/Jacob Carlborg

Atomicity of file-copying/moving

[Nordlöw via Digitalmars-d-learn]

What's the status of atomicity of file-copying and -moving 
(renaming) using std.file on different platforms?

Re: No tempFile() in std.file

[Anonymouse via Digitalmars-d-learn]

On Tuesday, 16 May 2017 at 05:09:12 UTC, Era Scarecrow wrote:

On Monday, 15 May 2017 at 22:38:15 UTC, Jonathan M Davis wrote:
Personally, I think that it would be very much worth making 
hello world larger, since hello world really doesn't matter, 
but because there are plenty of folks checking out D who write 
hello world and then look at the executable size, it was 
considered unacceptable for it to get much larger.


I'm reminded of doing the same thing with C++ using streams and 
saw the size explode from 60k or so to something like 400k, for 
seemingly no good reason at all.


Hmmm while we're on the subject of size, is there a tool to 
strip out functions that are never used from the final 
executable?


Linker --gc-sections, though in my experience it doesn't cull 
much. Add --print-gc-sections to see what it does remove.