On Friday, October 27, 2017 21:38:55 Jonathan M Davis via Digitalmars-d-
learn wrote:
> Also, toStringz specifically returns an immutable(char)* - though looking
> it over right now, I'd say that that's a bug for the overload that takes
> const(char)[] instead of string. It really should return con
On Saturday, October 28, 2017 02:46:00 Shriramana Sharma via Digitalmars-d-
learn wrote:
> On Wednesday, 25 October 2017 at 00:35:29 UTC, Ali Çehreli wrote:
> > > char[] name = "/tmp/XX".dup;
> >
> > remain valid. The actual issue is the missing '\0'. So,
> >
> > consider toStringz in this case
On Wednesday, 25 October 2017 at 00:35:29 UTC, Ali Çehreli wrote:
> char[] name = "/tmp/XX".dup;
remain valid. The actual issue is the missing '\0'. So,
consider toStringz in this case:
https://dlang.org/library/std/string/to_stringz.html
Thanks for your reply, but can you clarify exa
On Sunday, 18 January 2015 at 00:51:37 UTC, Laeeth Isharc wrote:
On Saturday, 17 January 2015 at 16:55:42 UTC, Marc Schütz wrote:
On Saturday, 17 January 2015 at 14:37:00 UTC, Laeeth Isharc
wrote:
On Saturday, 17 January 2015 at 13:47:39 UTC, Marc Schütz
wrote:
[...]
I agree that it would be
On Sunday, 18 January 2015 at 16:00:32 UTC, Kagamin wrote:
On Sunday, 18 January 2015 at 11:21:52 UTC, Marc Schütz wrote:
It's not different, and if you're still doing the O_EXCL open
afterwards, it's safe. I just assumed you were going to use
the generated filename without a further check. Thi
On 10/22/2017 06:41 PM, Shriramana Sharma wrote:
> On Sunday, 22 October 2017 at 15:21:37 UTC, Shriramana Sharma wrote:
>> For my program right now I'm using a souped-up version using a static
>> array:
>>
>> char[20] name = "/tmp/XX";
Literal strings have a '\0' attached, which does not
On Sunday, 22 October 2017 at 15:21:37 UTC, Shriramana Sharma
wrote:
For my program right now I'm using a souped-up version using a
static array:
char[20] name = "/tmp/XX";
Hmm I was wondering if I needed it to be static, and verily,
substituting:
char[] name = "/tmp/XX".dup;
On Sunday, October 22, 2017 15:21:37 Shriramana Sharma via Digitalmars-d-
learn wrote:
> On Saturday, 17 January 2015 at 17:16:41 UTC, Tobias Pankrath
>
> wrote:
> > You're looking for core.sys.posix.stdlib : mkstemp.
> >
> > I think that should be used by std.stdio.File as well, care to
> > create
On Saturday, 17 January 2015 at 17:16:41 UTC, Tobias Pankrath
wrote:
You're looking for core.sys.posix.stdlib : mkstemp.
I think that should be used by std.stdio.File as well, care to
create an enhancement request in bugzilla?
Though this thread is old, I ran into the issue when wanting to
c
On Sunday, 18 January 2015 at 11:21:52 UTC, Marc Schütz wrote:
It's not different, and if you're still doing the O_EXCL open
afterwards, it's safe. I just assumed you were going to use the
generated filename without a further check. This is then
unsafe, no matter how the UUID is generated, and
On Saturday, 17 January 2015 at 21:32:18 UTC, Jonathan M Davis
via Digitalmars-d-learn wrote:
But I think that what we need is a function in std.stdio (e.g
tempFile
insteaf of tmpfile) which returns an open File with a randomly
generated
name and gives you access to its name rather than using C'
On Sunday, 18 January 2015 at 00:51:37 UTC, Laeeth Isharc wrote:
I don't follow why a collision attack is applicable in this
case.
Your stage 1 of generating unique names: how is this different
from using a random uuid?
It's not different, and if you're still doing the O_EXCL open
afterwards
On Saturday, 17 January 2015 at 17:16:41 UTC, Tobias Pankrath
wrote:
On Saturday, 17 January 2015 at 16:55:42 UTC, Marc Schütz wrote:
On Saturday, 17 January 2015 at 14:37:00 UTC, Laeeth Isharc
wrote:
On Saturday, 17 January 2015 at 13:47:39 UTC, Marc Schütz
wrote:
Is it currently possible to g
On Saturday, 17 January 2015 at 16:55:42 UTC, Marc Schütz wrote:
On Saturday, 17 January 2015 at 14:37:00 UTC, Laeeth Isharc
wrote:
On Saturday, 17 January 2015 at 13:47:39 UTC, Marc Schütz
wrote:
Is it currently possible to get the path to a safe temporary
file, i.e. one that is guaranteed to
On Saturday, January 17, 2015 13:47:37 via Digitalmars-d-learn wrote:
> Is it currently possible to get the path to a safe temporary
> file, i.e. one that is guaranteed to be freshly created and will
> not override another existing file?
>
> There's `std.file.tempDir`, which doesn't create a unique
On Saturday, 17 January 2015 at 16:55:42 UTC, Marc Schütz wrote:
On Saturday, 17 January 2015 at 14:37:00 UTC, Laeeth Isharc
wrote:
On Saturday, 17 January 2015 at 13:47:39 UTC, Marc Schütz
wrote:
Is it currently possible to get the path to a safe temporary
file, i.e. one that is guaranteed to
On Saturday, 17 January 2015 at 14:37:00 UTC, Laeeth Isharc wrote:
On Saturday, 17 January 2015 at 13:47:39 UTC, Marc Schütz wrote:
Is it currently possible to get the path to a safe temporary
file, i.e. one that is guaranteed to be freshly created and
will not override another existing file?
On Saturday, 17 January 2015 at 13:47:39 UTC, Marc Schütz wrote:
Is it currently possible to get the path to a safe temporary
file, i.e. one that is guaranteed to be freshly created and
will not override another existing file?
There's `std.file.tempDir`, which doesn't create a unique file.
Th
Is it currently possible to get the path to a safe temporary
file, i.e. one that is guaranteed to be freshly created and will
not override another existing file?
There's `std.file.tempDir`, which doesn't create a unique file.
Then there's `std.stdio.tmpfile()`, which does, but it returns a
`F
19 matches
Mail list logo