www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Creating named tempfiles

reply Martin Nowak <code+news.digitalmars dawg.eu> writes:
As you might have noticed already, this functionality is currently 
missing in phobos leading people to write buggy or platform specific code.

We just fixed this in dub.
https://github.com/D-Programming-Language/dub/pull/497

Time to finally add this to phobos, what's missing is someone to 
implement it ;).
https://issues.dlang.org/show_bug.cgi?id=13996
Feb 03 2015
next sibling parent reply Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Wednesday, February 04, 2015 03:33:50 Martin Nowak via Digitalmars-d wrote:

 As you might have noticed already, this functionality is currently
 missing in phobos leading people to write buggy or platform specific code.

 We just fixed this in dub.
 https://github.com/D-Programming-Language/dub/pull/497

 Time to finally add this to phobos, what's missing is someone to
 implement it ;).
 https://issues.dlang.org/show_bug.cgi?id=13996


I have an implementation for it already, but I get linker errors for _wsopen
and any of its variants on Windows, so it doesn't work on Windows. If it
weren't for that, I'd have created a pull request for it quite some time
ago.

Has anyone else ever used _wsopen or its variants with dmd? If so, I'd love
to know how they got them to link.

- Jonathan M Davis
Feb 03 2015
parent reply "Kagamin" <spam here.lot> writes:
Looks like a relatively new function, so I guess, snn simply 
doesn't implement it.
Feb 03 2015
next sibling parent "Kagamin" <spam here.lot> writes:
Oops, no, not new.
Feb 03 2015
prev sibling next sibling parent reply Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Wednesday, February 04, 2015 07:34:14 Kagamin via Digitalmars-d wrote:

 Looks like a relatively new function, so I guess, snn simply
 doesn't implement it.


No. If I grep dmc's folder, snn.lib contains _wsopen. It doesn't contain
_wsopen_s, which is what MS wants folks to use, but it does have _wsopen.
However, when I try and use it, I get

Error 42: Symbol Undefined __wsopen 16

As I understand it, snn.lib is already linked in for other stdio stuff, so I
don't know why it can't find _wsopen. And adding pragma(lib, "snn.lib");
doesn't help. So, I don't know what to do.

- Jonathan M Davis
Feb 04 2015
parent reply "Kagamin" <spam here.lot> writes:
You got it declared with stdcall convention, should change to 
cdecl.
Feb 04 2015
parent reply Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Wednesday, February 04, 2015 08:18:46 Kagamin via Digitalmars-d wrote:

 You got it declared with stdcall convention, should change to
 cdecl.


Well, I have it as extern(Windows) like everything else in
core.sys.windows.windows - it has extern(Windows): at the top. Should that
be something else in this case? I'm not at all familiar with the Windows
calling conventions.

- Jonathan M Davis
Feb 04 2015
next sibling parent reply "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Jonathan M Davis via Digitalmars-d"  wrote in message 
news:mailman.5879.1423038837.9932.digitalmars-d puremagic.com...


 Well, I have it as extern(Windows) like everything else in
 core.sys.windows.windows - it has extern(Windows): at the top. Should that
 be something else in this case? I'm not at all familiar with the Windows
 calling conventions.


Try extern(C) and see if it works.  If it's a C function, it will most 
likely be using C mangling instead of system mangling.
Feb 04 2015
parent Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Wednesday, February 04, 2015 19:51:38 Daniel Murphy via Digitalmars-d wrote:

 "Jonathan M Davis via Digitalmars-d"  wrote in message
 news:mailman.5879.1423038837.9932.digitalmars-d puremagic.com...


 Well, I have it as extern(Windows) like everything else in
 core.sys.windows.windows - it has extern(Windows): at the top. Should that
 be something else in this case? I'm not at all familiar with the Windows
 calling conventions.


 Try extern(C) and see if it works.  If it's a C function, it will most
 likely be using C mangling instead of system mangling.


Yes. extern(C) does seem to do the trick. Thanks for guys' help. I've had
the code sitting around incomplete for quite some time now, and it's long
past time for it to become a PR.

https://github.com/D-Programming-Language/phobos/pull/2956

- Jonathan M Davis
Feb 04 2015
prev sibling next sibling parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Wed, 04 Feb 2015 00:33:48 -0800, Jonathan M Davis via Digitalmars-d
wrote:


 On Wednesday, February 04, 2015 08:18:46 Kagamin via Digitalmars-d
 wrote:

 You got it declared with stdcall convention, should change to cdecl.


=20
 Well, I have it as extern(Windows) like everything else in
 core.sys.windows.windows - it has extern(Windows): at the top. Should
 that be something else in this case? I'm not at all familiar with the
 Windows calling conventions.


for the most time `extern(Windows)` is using only for winapi calls. and=20
`wsopen` is a library call, so it's likely an `extern(C)`.=
Feb 04 2015
parent reply Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Wednesday, February 04, 2015 09:02:01 ketmar via Digitalmars-d wrote:

 On Wed, 04 Feb 2015 00:33:48 -0800, Jonathan M Davis via Digitalmars-d
 wrote:


 On Wednesday, February 04, 2015 08:18:46 Kagamin via Digitalmars-d
 wrote:

 You got it declared with stdcall convention, should change to cdecl.


 Well, I have it as extern(Windows) like everything else in
 core.sys.windows.windows - it has extern(Windows): at the top. Should
 that be something else in this case? I'm not at all familiar with the
 Windows calling conventions.


 for the most time `extern(Windows)` is using only for winapi calls. and
 `wsopen` is a library call, so it's likely an `extern(C)`.


Well, unfortunately, a C function is a C function to me. I know that
different calling conventions exist in Windows, but I have no idea why, what
the difference is, or what they affect. AFAIK, it's not an issue that exists
on POSIX systems. I really should study up on it.

- Jonathan M Davis
Feb 04 2015
parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Wed, 04 Feb 2015 01:13:18 -0800, Jonathan M Davis via Digitalmars-d
wrote:


 for the most time `extern(Windows)` is using only for winapi calls. and
 `wsopen` is a library call, so it's likely an `extern(C)`.


=20
 Well, unfortunately, a C function is a C function to me. I know that
 different calling conventions exist in Windows, but I have no idea why,
 what the difference is, or what they affect. AFAIK, it's not an issue
 that exists on POSIX systems. I really should study up on it.


it's mostly historical artifacts. and it's too late to change that. most=20
of the time it's used to make your program crash in most unexpected ways.

first windows was written in pascal, so it has pascal calling convention=20
(left-to-right order, callee cleans the stack). i don't know why, but=20
when they go to 32-bit version, they start using stdcall calling=20
convention (right-to-left order, yet callee still cleans the stack). that=20
is what `extern(Windows)` in D means. and most of other libraries written=20
in C, and they using cdecl convetion (right-to-left order, caller cleans=20
the stack). lovely things, aren't they?

so you have to triple-check your declarations when using windows. 'cause=20
besides name mangling, you can accidentally mark some stdcall function as=20
cdecl, and your program will work... for some time. but with bad stack=20
pointer, which will lead to some mystical bugs later.=
Feb 04 2015
parent Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Wednesday, February 04, 2015 09:33:22 ketmar via Digitalmars-d wrote:

 On Wed, 04 Feb 2015 01:13:18 -0800, Jonathan M Davis via Digitalmars-d
 wrote:


 for the most time `extern(Windows)` is using only for winapi calls. and
 `wsopen` is a library call, so it's likely an `extern(C)`.


 Well, unfortunately, a C function is a C function to me. I know that
 different calling conventions exist in Windows, but I have no idea why,
 what the difference is, or what they affect. AFAIK, it's not an issue
 that exists on POSIX systems. I really should study up on it.


 it's mostly historical artifacts. and it's too late to change that. most
 of the time it's used to make your program crash in most unexpected ways.

 first windows was written in pascal, so it has pascal calling convention
 (left-to-right order, callee cleans the stack). i don't know why, but
 when they go to 32-bit version, they start using stdcall calling
 convention (right-to-left order, yet callee still cleans the stack). that
 is what `extern(Windows)` in D means. and most of other libraries written
 in C, and they using cdecl convetion (right-to-left order, caller cleans
 the stack). lovely things, aren't they?

 so you have to triple-check your declarations when using windows. 'cause
 besides name mangling, you can accidentally mark some stdcall function as
 cdecl, and your program will work... for some time. but with bad stack
 pointer, which will lead to some mystical bugs later.


Just one more reason to hate Windows, I guess.

- Jonathan M Davis
Feb 04 2015
prev sibling parent "Kagamin" <spam here.lot> writes:
On Wednesday, 4 February 2015 at 08:33:57 UTC, Jonathan M Davis 
wrote:

 On Wednesday, February 04, 2015 08:18:46 Kagamin via 
 Digitalmars-d wrote:

 You got it declared with stdcall convention, should change to
 cdecl.


 Well, I have it as extern(Windows) like everything else in
 core.sys.windows.windows - it has extern(Windows): at the top. 
 Should that
 be something else in this case? I'm not at all familiar with 
 the Windows
 calling conventions.

 - Jonathan M Davis


Functions in <io.h> are low-level I/O API, providing POSIX-style 
wrappers for winapi functions: 
https://msdn.microsoft.com/en-us/library/40bbyw78.aspx - you can 
see them documented as part of C runtime library. The 
declarations should be somewhere core.sys.windows.io, see for 
example core.sys.windows.stat.
Everything in C runtime library uses C calling convention, 
because that's a library special for C, which makes it working. C 
is C, Windows is Windows, that's the difference. There can be Ada 
runtime library, which will use whatever calling (and naming) 
convention native to Ada, there can be Pascal runtime library, 
which will use whatever calling convention native to Pascal, 
there can be Haskell runtime library, which will use whatever 
calling convention native to Haskell, and so on. C has runtime 
library too.
Feb 04 2015
prev sibling parent reply Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Wednesday, February 04, 2015 00:13:21 Jonathan M Davis via Digitalmars-d
wrote:

 On Wednesday, February 04, 2015 07:34:14 Kagamin via Digitalmars-d wrote:

 Looks like a relatively new function, so I guess, snn simply
 doesn't implement it.


 No. If I grep dmc's folder, snn.lib contains _wsopen. It doesn't contain
 _wsopen_s, which is what MS wants folks to use, but it does have _wsopen.
 However, when I try and use it, I get

 Error 42: Symbol Undefined __wsopen 16

 As I understand it, snn.lib is already linked in for other stdio stuff, so I
 don't know why it can't find _wsopen. And adding pragma(lib, "snn.lib");
 doesn't help. So, I don't know what to do.


Oh, wait. Looking over io.h, whereas _wsopen is declared, I see two
problems. One, MS declared it as

int _wsopen(const wchar* filename, int oflag, int shflag, int pmode);

whereas dmc seems to have

int __CLIB _wsopen(const wchar_t *, int, int, ...);

So, for some reason, dmc made it variadic. And the second problem is that
dmc has that block of function declarations surrounded by

#ifdef __NT__
#ifndef __STDC__
// declarations
#endif
#endif

and it's quite possible that the declarations are being skipped entirely.
And since changing the D declaration for _wsopen to be variadic simply
changes the error message to

 Error 42: Symbol Undefined __wsopen 12

that would imply that those declarations aren't actually enabled. And
without some version of _wsopen, I don't know how to get the code working
properly on Windows. Maybe the a version will work? But those are supposed
to be avoided like the plague as I understand it.

All in all, this is quite annoying.

- Jonathan M Davis
Feb 04 2015
parent ketmar <ketmar ketmar.no-ip.org> writes:
On Wed, 04 Feb 2015 00:29:58 -0800, Jonathan M Davis via Digitalmars-d
wrote:


 Oh, wait. Looking over io.h, whereas _wsopen is declared, I see two
 problems. One, MS declared it as
=20
 int _wsopen(const wchar* filename, int oflag, int shflag, int pmode);
=20
 whereas dmc seems to have
=20
 int __CLIB _wsopen(const wchar_t *, int, int, ...);
=20
 So, for some reason, dmc made it variadic.


`pmode` argument is optional (it depends on flags in `oflag`), and=20
passing it each time is somewhat annoying. but there is no way to do=20
optional args in C, so DMC made function variadic. take the first=20
declaration, it's ok.


  Error 42: Symbol Undefined __wsopen 12


and yes, it must be `extern(C)`, not `extern(Windows)`, as Daniel told=20
you in another post.=
Feb 04 2015
prev sibling parent reply Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Wednesday, February 04, 2015 00:29:58 Jonathan M Davis via Digitalmars-d
wrote:

 And the second problem is that
 dmc has that block of function declarations surrounded by

 #ifdef __NT__
 #ifndef __STDC__
 // declarations
 #endif
 #endif

 and it's quite possible that the declarations are being skipped entirely.


No, on further reflection, that can't be it, because it shows up in snn.lib,
not just io.h. So, it's actually in the compiled library. So, it probably is
a problem with the D declaration itself - be it the calling convention or
something else.

- Jonathan M Davis
Feb 04 2015
parent "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Jonathan M Davis via Digitalmars-d"  wrote in message 
news:mailman.5880.1423039515.9932.digitalmars-d puremagic.com...


 No, on further reflection, that can't be it, because it shows up in 
 snn.lib,
 not just io.h. So, it's actually in the compiled library. So, it probably 
 is
 a problem with the D declaration itself - be it the calling convention or
 something else.


Yes, it's the calling convention.
Feb 04 2015