World: r3wp

input-next may have the same problem, but did you try it?

Strings are terminated properly with gets/input-line but you must 
allocate an unknown storage size, which is warned for in the source 
of the binding

The binaries Red generates with a binding are now ten times as big 
as a few weeks ago, because it now generates code for #import definitions. 
Is that correct?

When I have a struct! as a local variable, is only the pointer to 
the struct reserved on the stack, not the struct itself?

When I make a STRUCT for a local variable within a function, is it 
created on the heap, so that I need to free it?

Bigger binaries: yes, it is caused by #import bindings and by runtime 
message strings.

Local struct variable: that is correct, only the pointer is stored 
in the stack frame.

STRUCT is used to declare literal structures. As all literals, it 
is stored in the data segment of the executable image, you don't 
need to free it as it is not allocated with a malloc() call.

Kaj: have you found the "struct [...]" construction somehow misleading?


I am asking this because there is a discussion about that on the 
mailing-list and I need to decide this weekend if I keep pointer/struct 
literal declarations as-is or change it.

Any feedback on this topic (and other opened questions on the ML 
and issue tracker) will be appreciated.

I've been thinking about it, but the reason it is misleading is basically 
that it's defined at the C level. You have to flip flop your mind 
between low level C thinking and high level REBOL thinking

I suppose this is inherent in the concept of Red/System, and I think 
it's mainly a matter of learning the new language

However, my own preference is to make concepts higher level if it 
doesn't compromise performance

It now dawns on me that I mixed up STRUCT and ALLOCATE. I hit these 
issues last night and went to bad because I was tired and pretty 
sure that I would be able to see it more clearly today, but I had 
already formulated the questions in my head :-)

to bed

The fact that I needed to allocate a local struct was pointed out 
to me by the new initialisation checks in Red, so that's pretty good

It would be nice to be able to use SIZE? on a datatype, instead of 
an actually existing data value:

size? integer!

That might only be useful with integer! as it should be extended 
to 64-bit when Red/System will be ported to 64-bit platforms. But 
I think that a specific macro would be more appropriate (something 
like integer-size?).

or rather: get-integer-size

No, I simplified the example. I actually wanted to get sizes of structs 
without allocating one

Try with an alias (untested).

Doesn't it get the size of the pointer then?

Let me try...

SIZE? doesn't seem to recognize the alias.

An alias is an abstract definition, it doesn't allocated anything. 
So we can decide that the size of an alias is the whole struct size.

allocated => allocate

Yes, that's what I would like

In the runtime, there's now a new generic pointer type defined:

#define byte-ptr!	c-string!

However, it's type incompatible with the previous definition, which 
NULL still uses:

null: 		pointer [integer!]				;-- null pointer declaration

The documentation specifies a third definition, namely integer!

This comes back to the lack of a void pointer type again

There is a ticket about null: https://github.com/dockimbel/Red/issues/96

Failing that, I think these definitions should use the same type

The new ALLOCATE and FREE use c-string! which makes using them on 
generic byte arrays, and comparisons with NULL, confusing

NULL will be adapted to cop with that (either using polymorphism 
or by replacing it by a NULL? macro).

I find ALLOCATE and FREE using c-string! unintuitive

Other types need to be cast to use these functions

Same as malloc() with C void pointers.

Still, why do we have now have three different definitions of a generic 
pointer?

There is no such thing as a generic pointer in Red/System.

I know, but I #define it as handle! like we talked about before, 
but there's now no way to define handle! in such a way that it works 
everywhere

Have you tried with defining it as integer!?

I once did, but I doubt it will now compensate for c-string! and 
NULL

Integer! is conceptually the closest type to handle!.

Yes, so why not define NULL and byte-ptr! as integer?

About NULL, please read the ticket on github I have posted above. 
NULL will be changed.

Sure, but why not fix this inconvenience right now?