Re: Passing variadic arguments to C
On Sunday, 22 February 2015 at 17:20:23 UTC, Foo wrote:
On Sunday, 22 February 2015 at 17:15:06 UTC, anonymous wrote:
On Sunday, 22 February 2015 at 17:09:27 UTC, Foo wrote:
Is this possible?
Example:
void foo(Args...)(auto ref Args args) {
sprintf(str.ptr, fmt.ptr, args);
}
yes
I get the error, that I cannot pass a dynamic array to a C
function.
My fault, the reason was that Args contains strings. ;)
Re: Passing variadic arguments to C
On Sunday, 22 February 2015 at 17:15:06 UTC, anonymous wrote:
On Sunday, 22 February 2015 at 17:09:27 UTC, Foo wrote:
Is this possible?
Example:
void foo(Args...)(auto ref Args args) {
sprintf(str.ptr, fmt.ptr, args);
}
yes
I get the error, that I cannot pass a dynamic array to a C
function.
Passing variadic arguments to C
Is this possible?
Example:
void foo(Args...)(auto ref Args args) {
sprintf(str.ptr, fmt.ptr, args);
}
Re: const member function
On Saturday, 21 February 2015 at 15:26:28 UTC, ketmar wrote: On Sat, 21 Feb 2015 08:27:13 +, rumbu wrote: My question was not how I do this, I know already. My question was if there is another way to safely call a non-const instance function on a const object. is there a way to been safely hit by a truck? In a tank. ;)
Re: const member function
On Saturday, 21 February 2015 at 06:38:18 UTC, rumbu wrote:
Often I'm using the following code pattern:
class S
{
private SomeType cache;
public SomeType SomeProp() @property
{
if (cache is null)
cache = SomeExpensiveOperation();
return cache;
}
}
Is there any way to mark SomeProp() as const? Because I want to
call somewhere const(S).SomeProp, which for the outside world
is must be "const", returning just a value, even that internaly
it modifies the internal S structure.
AFAIK it is unsafe and not recommended, but this works for me:
import std.stdio;
class Foo {
void say(string s) const {
writeln(s);
}
}
class Bar {
Foo f;
const(Foo) getFoo() const {
if (!f)
cast() this.f = new Foo();
return f;
}
}
void main() {
Bar b = new Bar();
const Foo f = b.getFoo();
f.say("Hello");
}
Re: What is the Correct way to Malloc in @nogc section?
On Saturday, 21 February 2015 at 14:39:47 UTC, anonymous wrote: On Saturday, 21 February 2015 at 13:41:41 UTC, Foo wrote: Finally, I tried to take your criticism objectively and, as far as I can tell, I resolved the issues. Is there still any objections or misconduct? Nice. I think you fixed everything I had pointed out. Yeah, I hope so too. Sorry for my annoyed behaviour, that wasn't my week and you where the the straw to break the camel's back. ;) I hope I have the phrase translated correctly. :D
Re: What is the Correct way to Malloc in @nogc section?
On Friday, 13 February 2015 at 22:55:27 UTC, anonymous wrote: On Thursday, 12 February 2015 at 23:52:41 UTC, Foo wrote: This is something I've done recently. Would be glad if my code will help you: https://github.com/Dgame/m3 Especially the m3.d module could be useful for you. /* Class and Struct */ emplace: You can't assume zero-initialization for structs. destruct: Is not memory-safe, and must not be marked @trusted. /* Array */ make: You can't assume zero-initialization. T.sizeof is not the size of an element. reserve: Not safe (you're freeing the old memory), must not be @trusted. append: T.sizeof is not the size of an element. You're multiplying twice with T.sizeof; in `append`, and also in `reserve`. destruct: Not safe, must not be @trusted. Finally, I tried to take your criticism objectively and, as far as I can tell, I resolved the issues. Is there still any objections or misconduct?
Re: What is the Correct way to Malloc in @nogc section?
On Friday, 13 February 2015 at 23:13:05 UTC, anonymous wrote: On Friday, 13 February 2015 at 23:04:25 UTC, Foo wrote: Don't understand me wrong. My code is not perfect, but maybe it can be helpful for someone. As it is right now, I fear it may do more harm than good. Always the same in this newsgroup. You want to help as good as you can (even if it's not perfect) and all you get are subliminal messages... :) I'm regret that I tried to help, I will delete this repo as far as possible. :)
Re: What is the Correct way to Malloc in @nogc section?
On Friday, 13 February 2015 at 22:55:27 UTC, anonymous wrote: On Thursday, 12 February 2015 at 23:52:41 UTC, Foo wrote: This is something I've done recently. Would be glad if my code will help you: https://github.com/Dgame/m3 Especially the m3.d module could be useful for you. /* Class and Struct */ emplace: You can't assume zero-initialization for structs. destruct: Is not memory-safe, and must not be marked @trusted. /* Array */ make: You can't assume zero-initialization. T.sizeof is not the size of an element. I'm aware of that. reserve: Not safe (you're freeing the old memory), must not be @trusted. append: T.sizeof is not the size of an element. You're multiplying twice with T.sizeof; in `append`, and also in `reserve`. destruct: Not safe, must not be @trusted. Ah, that is nice to know. I will fix this soon. Or would you help me out with an PR? Don't understand me wrong. My code is not perfect, but maybe it can be helpful for someone.
Re: GC has a "barbaric" destroyng model, I think
On Friday, 13 February 2015 at 09:28:30 UTC, Kagamin wrote: On Friday, 13 February 2015 at 09:11:26 UTC, Foo wrote: And I wouldn't say indiscriminately. Every function I marked with @trusted was checked by me so far. What did you check them for? :) Just first example: make and destruct, being marked as @trusted, don't prevent caller from UAF and double free vulnerabilities, and compiler can't help with that by checking the caller. Other functions marked as trusted have similar problems. If the the caller can't be automatically checked for safety and must ensure safety manually, it means the callee is @system. That seems to be a problem with trusted and safe :)
Re: GC has a "barbaric" destroyng model, I think
On Friday, 13 February 2015 at 08:00:43 UTC, Kagamin wrote: On Thursday, 12 February 2015 at 17:29:34 UTC, Foo wrote: And since today it is @safe wherever possible. Well, you marked functions @trusted rather indiscriminately :) Such approach doesn't really improve safety, and the code could work as well being @system. It's not like @system is inherently broken or something like that. Since with @safemarked functions are checked by the compiler it is advisable to mark functions with @safe. And I wouldn't say indiscriminately. Every function I marked with @trusted was checked by me so far. Of course I'm rather new to D, so I could be wrong. But since my other comrades aren't willing to use D, this code will rot on Github if nobody else will use it.
Re: What is the Correct way to Malloc in @nogc section?
On Thursday, 12 February 2015 at 23:27:51 UTC, Kitt wrote:
I'm currently trying to write a personal Associate Array class
that can be used in @nogc sections. Obviously, this means I'll
want to use malloc/free, however I'm not sure what the
"Correct" way to do this is. In a few places online I've seen
code for custom "_new" and "_delete" functions similar to this:
[code]
T _new(T, Args...) (Args args) {
size_t objSize;
static if(is (ValType == class))
objSize = __traits(classInstanceSize, T);
else
objSize = T.sizeof;
void* tmp = core.stdc.stdlib.malloc(objSize);
if (!tmp) throw new Exception("Memory allocation failed");
void[] mem = tmp[0..objSize];
T obj = emplace!(T, Args)(mem, args);
return obj;
}
void _delete(T)(T obj) {
clear(obj);
core.stdc.stdlib.free(cast(void*)obj);
}
[/code]
The Exception obviously uses the GC, and would need to be
replaced with a printf or something; however, emplace doesn't
have a @nogc replacement that I know of. What I'd like to know,
from people much more knowledgeable about the ins and outs of
D, is what the "Best" or "Correct" way to allocate and
deallocate within @nogc sections?
PS: Tangentially related, what hashing algorithm does D use?
I've seen people suggest using typeid(object).toHash(&object);
however, toHash isn't @nogc, so I need to write my own Hashing
function. For the sake of consistency and peace of mind, I'd
really like to match mine as closely to Ds internal one as
possible.
This is something I've done recently.
Would be glad if my code will help you:
https://github.com/Dgame/m3
Especially the m3.d module could be useful for you.
Re: GC has a "barbaric" destroyng model, I think
On Thursday, 12 February 2015 at 14:44:07 UTC, Kagamin wrote: On Thursday, 12 February 2015 at 12:52:03 UTC, Andrey Derzhavin wrote: If we can't relay on GC wholly, there is no need for GC. All of the objects, that I can create, I can destroy manually by myself, without any doubtful GC destroying attempts. Manual memory management should be possible in D, see for example https://github.com/Dgame/m3 And since today it is @safe wherever possible.
Re: Want to read a whole file as utf-8
Since I'm now almost finished, I'm glad to show you my work: https://github.com/Dgame/m3 You're free to use it or to contribute to it.
Re: Want to read a whole file as utf-8
On Tuesday, 3 February 2015 at 19:44:49 UTC, FG wrote: On 2015-02-03 at 19:53, Foo wrote: How can I do that without any GC allocation? Nothing in std.file seems to be marked with @nogc I'm asking since it seems very complicated to do that with C++, maybe D is a better choice, then we would probably move our whole project from C++ to D. Looks like std.stdio isn't marked with @nogc all the way either. So for now the temporary solution would be to use std.c.stdio. Get the file size, malloc a buffer large enough for it[1], use std.c.stdio.read to fill it, assign it to a char[] slice and std.utf.decode to consume the text... Oh wait, decode isn't @nogc either. FFS, what now? [1] I assume the file is small, otherwise there would be an extra step involved where after nearing the end of the buffer you move the rest of the data to the front, read new data after it, and continue decoding. How would I use decoding for that? Isn't there a way to read the file as utf8 or event better, as unicode?
Re: Want to read a whole file as utf-8
On Tuesday, 3 February 2015 at 19:56:37 UTC, FG wrote: On 2015-02-03 at 20:50, Tobias Pankrath wrote: Use std.utf.validate instead of decode. It will only allocate one exception if necessary. Looks to me like it uses decode internally... But Foo, do you have to use @nogc? It still looks like it's work in progress, and lack of it doesn't mean that the GC is actually involved in the function. It will probably take several months for the obvious nogc parts of the std lib to get annotated, and much longer to get rid of unnecessary use of the GC. So maybe the solution for now is to verify the source code of the function in question with ones own set of eyeballs and decide if it's good enough for use, ie. doesn't leak too much? Yes, we don't want to use a GC. We want determinsitic life times. I'm not the boss, but I support the idea. @Nordlöw Neither of them can be marked with @nogc. :/
Want to read a whole file as utf-8
How can I do that without any GC allocation? Nothing in std.file seems to be marked with @nogc I'm asking since it seems very complicated to do that with C++, maybe D is a better choice, then we would probably move our whole project from C++ to D.
Re: Conway's game of life
On Sunday, 1 February 2015 at 21:00:07 UTC, gedaiu wrote: Hi, I implemented Conway's game of life in D. What do you think that I can improve to this program to take advantage of more D features? https://github.com/gedaiu/Game-Of-Life-D Thanks, Bogdan For each remove you create a new array. That is lavish. You should use a bool inside the struct Cell. If it's false, the cell is not displayed and is out of the game. My suggestion: don't use the D GC, it's crap. Try to circumvent the GC wherever possible. Therefore you should use the -vgc compiler flag and the @nogc attribute.
Re: Fastest Way of Accessing Entries in an AA
On Friday, 9 January 2015 at 06:18:53 UTC, Jonathan M Davis via
Digitalmars-d-learn wrote:
On Friday, January 09, 2015 00:20:07 Foo via
Digitalmars-d-learn wrote:
On Thursday, 8 January 2015 at 23:06:39 UTC, Nordlöw wrote:
> On Thursday, 8 January 2015 at 16:11:07 UTC, ketmar via
> Digitalmars-d-learn wrote:
>> how can it? compiler doesn't know what the code is supposed
>> to
>> do. if
>> compilers will know such things someday, we can stop writing
>> programs
>> altogether, as compilers will be able to write any program
>> for
>> us. ;-)
>
> Correction:
>
> I thought it would be nice if the compiler explained to me
> that
>
> key in aa ? aa[key]
>
> is a sub-optimal performance-wise.
You know, that you kan reuse the result of the in operator by
AAs?
example:
auto ptr = key in aa;
ptr ? *ptr : ValueType.init
This idiom is quite common:
if(auto ptrToValue = key in aa)
{
}
though I'm not sure that that quite fits in with what Nordlow
seems to be
trying to do with init. aa.get probably does a better job of
that, though
looking at the implementation for get, it's basically doing
what you're
suggesting:
auto p = key in aa;
return p ? *p : defaultValue;
though that has the downside of using a lazy parameter for the
default
value, which is convenient but doesn't do great things for
performance.
- Jonathan M Davis
I just wasn't sure that he knows about it.
Re: Fastest Way of Accessing Entries in an AA
On Thursday, 8 January 2015 at 23:06:39 UTC, Nordlöw wrote: On Thursday, 8 January 2015 at 16:11:07 UTC, ketmar via Digitalmars-d-learn wrote: how can it? compiler doesn't know what the code is supposed to do. if compilers will know such things someday, we can stop writing programs altogether, as compilers will be able to write any program for us. ;-) Correction: I thought it would be nice if the compiler explained to me that key in aa ? aa[key] is a sub-optimal performance-wise. You know, that you kan reuse the result of the in operator by AAs? example: auto ptr = key in aa; ptr ? *ptr : ValueType.init
Re: VLA in Assembler
On Wednesday, 17 December 2014 at 16:10:40 UTC, Adam D. Ruppe
wrote:
On Wednesday, 17 December 2014 at 14:11:32 UTC, Foo wrote:
asm {
mov EAX, n;
mov [arr + 8], ESP;
sub [ESP], EAX;
mov [arr + 0], EAX;
}
but that does not work...
That wouldn't work even with malloc remember, an integer
more than one byte long, so your subtract is 1/4 the size it
needs to be! Also, since the stack grows downward, you're
storing the pointer to the end of the array instead of the
beginning of it.
NOTE: I've never actually done this before, so I'm figuring it
out as I go too. This might be buggy or otherwise mistaken at
points. (Personally, I prefer to use a static array sized to
the max thing I'll probably need that I slice instead of
alloca...)
Here's some code that runs successfully (in 32 bit!):
void vla(int n) {
int[] arr;
asm {
mov EAX, [n];
// the first word in an array is the length,
store that
mov [arr], EAX;
shl EAX, 2; // number of bytes == n * int.sizeof
sub ESP, EAX; // allocate the bytes
mov [arr + size_t.sizeof], ESP; // store the beginning of it
in the arr.ptr
}
import std.stdio;
writeln(arr.length);
writeln(arr.ptr);
// initialize the data...
foreach(i, ref a; arr)
a = i;
writeln(arr); // and print it back out
}
void main() {
vla(8);
}
This looks right but isn't, we changed the stack and didn't
put it back. That's usually a no-no. If we disassemble the
function, we can take a look at the end and see something scary:
8084ec6: e8 9d 6a 00 00 call 808b968
<_D3std5stdio15__T7writelnTAiZ7writelnFAiZv> // our final
writeln call
8084ecb: 5e popesi // uh oh
8084ecc: 5b popebx
8084ecd: c9 leave
8084ece: c3 ret
Before the call to leave, which puts the stack back how it was
at the beginning of the function - which saves us from a random
EIP being restored upon the ret instruction - the compiler put
in a few pop instructions.
main() will have different values in esi and ebx than it
expects! Running it in the debugger shows these values changed
too:
before
(gdb) info registers
[...]
ebx0xd4f4 -11020
[...]
esi0x80916e8134813416
after
ebx0x1 1
esi0x0 0
It popped the values of our array. According to the ABI: "EBX,
ESI, EDI, EBP must be preserved across function calls."
http://dlang.org/abi.html
They are pushed for a reason - the compiler assumes they remain
the same.
In this little test program, nothing went wrong because no more
code was run after vla returned. But, if we were using, say a
struct, it'd probably fault when it tried to access `this`.
It'd probably mess up other local variables too. No good!
So, we'll need to store and restore the stack pointer... can we
use the stack's push and pop instructions? Nope, we're changing
the stack! Our own pop would grab the wrong data too.
We could save it in a local variable. How do we restore it
though? scope(exit) won't work, it won't happen at the right
time and will corrupt the stack even worse.
Gotta do it ourselves - which means we can't do the alloca even
as a single mixin, since it needs code added before any return
point too!
(There might be other, better ways to do this... and indeed,
there is, as we'll see later on. I peeked at the druntime
source code and it does it differently. Continue reading...)
Here's code that we can verify in the debugger leaves
everything how it should be and doesn't crash:
void vla(int n) {
int[] arr;
void* saved_esp;
asm {
mov EAX, [n];
mov [arr], EAX;
shl EAX, 2; // number of bytes == n * int.sizeof
// NEW LINE
mov [saved_esp], ESP; // save it for later
sub ESP, EAX;
mov [arr + size_t.sizeof], ESP;
}
import std.stdio;
writeln(arr.length);
writeln(arr.ptr);
foreach(i, ref a; arr)
a = i;
writeln(arr);
// NEW LINE
asm { mov ESP, [saved_esp]; } // restore it before we return
}
Note that this still isn't quite right - the allocated size
should be aligned too. It works for the simple case of 8 ints
since that's coincidentally aligned, but if we were doing like
3 bytes, it would mess things up. Gotta be rounded up to a
multiple of 4 or 16 on some systems.
hmm, I'm looking at the alloca source and there's a touch of a
guard page on Windows too. Check out the file:
dmd2/src/druntime/src/rt/alloca.d, it is written in mostly
inline asm.
Note the comment
Re: VLA in Assembler
And it is using malloc... ;)
I wanted something that increases the stack pointer ESP.
e.g.
void main()
{
int[] arr;
int n = 42;
writeln(arr.length);
writeln(arr.ptr);
asm {
mov EAX, n;
mov [arr + 8], ESP;
sub [ESP], EAX;
mov [arr + 0], EAX;
}
writeln(arr.length);
//writeln(arr[0]);
}
but that does not work...
Re: VLA in Assembler
On Wednesday, 17 December 2014 at 12:15:23 UTC, uri wrote:
On Wednesday, 17 December 2014 at 11:39:43 UTC, Foo wrote:
On Wednesday, 17 December 2014 at 10:59:09 UTC, bearophile
wrote:
Foo:
Hi,
Could someone explain me, if and how it is possible to
allocate a variable length array with inline assembly?
Somewhat like
int[] arr;
int n = 42;
asm {
// allocate n stack space for arr
}
I know it is dangerous and all that, but I just want it
know. ;)
Doing it with alloca is simpler:
void main() @nogc {
import core.stdc.stdlib: alloca, exit;
alias T = int;
enum n = 42;
auto ptr = cast(T*)alloca(T.sizeof * n);
if (ptr == null)
exit(1); // Or throw a memory error.
auto arr = ptr[0 .. n];
}
Bye,
bearophile
Yes I know, but I really want it in inline assembly. It's for
learning purpose. :)
You could look at the disassembly.
And how? I'm on Windows.
Re: VLA in Assembler
On Wednesday, 17 December 2014 at 10:59:09 UTC, bearophile wrote:
Foo:
Hi,
Could someone explain me, if and how it is possible to
allocate a variable length array with inline assembly?
Somewhat like
int[] arr;
int n = 42;
asm {
// allocate n stack space for arr
}
I know it is dangerous and all that, but I just want it know.
;)
Doing it with alloca is simpler:
void main() @nogc {
import core.stdc.stdlib: alloca, exit;
alias T = int;
enum n = 42;
auto ptr = cast(T*)alloca(T.sizeof * n);
if (ptr == null)
exit(1); // Or throw a memory error.
auto arr = ptr[0 .. n];
}
Bye,
bearophile
Yes I know, but I really want it in inline assembly. It's for
learning purpose. :)
VLA in Assembler
Hi,
Could someone explain me, if and how it is possible to allocate a
variable length array with inline assembly?
Somewhat like
int[] arr;
int n = 42;
asm {
// allocate n stack space for arr
}
I know it is dangerous and all that, but I just want it know. ;)
Re: is there any reason UFCS can't be used with 'new'?
On Sunday, 28 September 2014 at 19:11:23 UTC, Jay wrote:
i want to chain 'new' with method calls on the created object.
i found this on the internet:
window.mainWidget = (new Button()).text("Hello
world"d).textColor(0xFF);
it would look much nicer with UFCS:
window.mainWidget = Button.new().text("Hello
world"d).textColor(0xFF);
well, it's not *exactly* UFCS but you get what i mean.
mixin template New(T) if (is(T == class)) {
static T New(Args...)(Args args) {
return new T(args);
}
}
class Bar {
string txt;
this() {
txt = "Foo";
}
this(string t) {
txt = t;
}
mixin New!Bar;
}
void main() {
import std.stdio;
writeln(Bar.New().txt);
writeln(Bar.New("Bar").txt);
}
Re: Programming a Game in D? :D
On Saturday, 2 August 2014 at 20:38:59 UTC, David wrote: Hi, not too sure if there's still someone reading this post, but i do have another question. So, I heared so much good stuff about D, it's powerfull, fast the syntax is nice, but well, why is D actually not used for common games yet? (I mean I know about some smaller projects, but nothing "big") Because D has a GC, is unstable and has many many bugs (even an ape could find some).
Re: mixin assembler does not work?
On Sunday, 20 July 2014 at 17:50:10 UTC, Nicolas Sicard wrote:
On Sunday, 20 July 2014 at 15:02:58 UTC, Foo wrote:
On Sunday, 20 July 2014 at 14:55:00 UTC, Foo wrote:
For clarification: how would that work without mixin + string?
I tried this:
mixin template Vala2(uint count, alias arr) {
asm {
sub ESP, count;
mov arr, count;
mov arr + 4, ESP;
}
}
but I get several errors. Unfortunately it seems that asm
cannot be used in mixin templates?!
The reason may be that mixin templates are just for inserting
declarations, which asm blocks aren't. This limitation isn't
specific to asm.
But what's the reason for that?
Re: mixin assembler does not work?
On Sunday, 20 July 2014 at 15:54:15 UTC, bearophile wrote:
mixin template Vala2(uint count, alias arr) {
What about disallowing "mixin templatename" unless you add
"mixin" before the "template" keyword?
Bye,
bearophile
I do not understand?
Re: mixin assembler does not work?
On Sunday, 20 July 2014 at 14:55:00 UTC, Foo wrote:
For clarification: how would that work without mixin + string?
I tried this:
mixin template Vala2(uint count, alias arr) {
asm {
sub ESP, count;
mov arr, count;
mov arr + 4, ESP;
}
}
but I get several errors. Unfortunately it seems that asm cannot
be used in mixin templates?!
Re: mixin assembler does not work?
On Sunday, 20 July 2014 at 14:46:32 UTC, bearophile wrote:
enum Vala(uint count, alias arr) = format("
asm {
sub ESP, %d; // Reserve 'count' bytes
mov %s, %d; // Set a.length = 'count'
mov %s + 4, ESP; // Set &a[0] to reserved bytes
}", count, arr.stringof, count, arr.stringof);
I'd like to write that more like this:
enum Vala(uint count, alias arr) = format("
asm {
sub ESP, %%(count); // Reserve 'count'
bytes
mov %%(arr.stringof), %%(count); // Set a.length =
'count'
mov %%(arr.stringof) + 4, ESP; // Set &a[0] to
reserved bytes
}");
See:
http://fslang.uservoice.com/forums/245727-f-language/suggestions/6002107-steal-nice-println-syntax-from-swift
Bye,
bearophile
It seems that your code doesn't work with 2.065.
Re: mixin assembler does not work?
On Sunday, 20 July 2014 at 14:44:07 UTC, sigod wrote:
On Sunday, 20 July 2014 at 14:18:58 UTC, Foo wrote:
template Vala(uint count, alias arr) {
immutable string c = to!string(count);
enum Vala = "asm { sub ESP, " ~ c ~ "; mov " ~ arr.stringof ~
",
" ~ c ~ "; mov " ~ arr.stringof ~ " + 4, ESP; }";
}
...
mixin Vala!(1000, a);
I'm not sure how to do it, but I see few mistakes in your code:
1. You declaring it as a string. (Or your intend to use
`mixin()`?)
2. You trying to use `template` as a [`mixin template`][0].
[0]: http://dlang.org/template-mixin
Yeah, it now works with mixin(Vala!(1000, a)); I thought that
both are the same.
Re: mixin assembler does not work?
For clarification: how would that work without mixin + string?
mixin assembler does not work?
Hey guys. Can someone explain me, why this code does only works
with the inline assembler version but not with the mixin?
Thanks in advance!
Code:
import std.stdio : writeln;
import std.conv : to;
template Vala(uint count, alias arr) {
immutable string c = to!string(count);
enum Vala = "asm { sub ESP, " ~ c ~ "; mov " ~ arr.stringof ~ ",
" ~ c ~ "; mov " ~ arr.stringof ~ " + 4, ESP; }";
}
void main() {
ubyte[] a;
writeln(a.length);
static if (false) {
asm {
sub ESP, 1000; // Reserve 1000 bytes
mov a, 1000;// Set a.length = 1000
mov a + 4, ESP; // Set &a[0] to reserved bytes
}
} else {
mixin Vala!(1000, a);
}
writeln(a.length);
}
