World: r3wp

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?

I don't care what handle! is, just that there are three incompatible 
definitions

Because I currently work on another ticket.

It's just changing the two lines I cited above

I don't mean right now right now, I mean before making NULL polymorphic

The NULL changes will be done this weekend, you won't have to wait 
too long.

That still leaves the incompatibility between byte-ptr! and the documentation

byte-ptr! as integer?: certainly not, byte-ptr! as it names implies 
is a byte! pointer, so semantically different than just integer!.

But you're saying all the time that a void pointer is conceptually 
closest to an integer?

Right.

You should erase the "void pointer" expression from your mind, it 
is corrupting your vision. :-)

Again, I don't care much what it is (although I wouldn't expect ALLOCATE 
to return a c-string!), just that the definitions are compatible, 
so you don't have to insert confusing typecasts everywhere

I'm just following what you have written in the manual about pointers

the definitions are compatible
: which ones?

NULL, byte-ptr! and the manual use three type incompatible definitions. 
I must compare and pass these types

NULL and documentation will be fixed during this weekend.

So will they be compatible with byte-ptr! thereafter?

NULL should work with any kind of pointer/struct or be removed.

I haven't decided yet on the right solution, but you can safely use 
ALLOCATE as it is defined right now, that won't be changed.

Not really, because casts are needed on every use of ALLOCATE and 
FREE

That would be the case whatever type you would put in the return 
definition of ALLOCATE?

As you can allocate memory space for various datatypes.

No, because there's one exception: the type that ALLOCATE and FREE 
choose to use

You've lost me...what type are you talking about?

They currently use c-string! I'm not sure that's the clearest one. 
It's unintuitive to me, as if the type returned is very specific 
and comes with a zero byte at the end

That is why I have not put c-string! but byte-ptr!.

I know, but that gets lost during compilation. What the compiler 
complains about is that you have to cast to and from c-string!

Do I really need to add a new [pointer! [byte!]] to the compiler 
just to make this error message looks nicer?

(I mean adding a new datatype in the compiler).

I think that would be very useful, but that's the more fundamental 
pointer discussion. I'm now just concerned about making casts the 
least confusing

I pretty sure that some ppl would complain that [pointer! [byte!]] 
is exactly the same as c-string!...;-)

I don't get what is the issue with casting (expect the error message)?

Sure, but I mean, we had two definitions of a generic pointer: integer! 
or pointer! [integer!]. Why confuse it with c-string! now?

expect => except

Well, I have already answered that question above. I am sorry if 
that change breaks existing code. Once again, the C void pointer 
is a very confusing concept that should not be used outside of C 
language. If you refer to a C void pointer without any context, it 
is just a memory address, so integer! (or handle!) would be the closest 
corresponding concept. If you refer to a C function returning a void 
pointer like malloc(), the closest transposition in Red/System would 
be ALLOCATE returning a byte! pointer.

Malloc() allocates a memory region that granularity is by default 
a byte (until you cast is to something else).

So, in summary, there is no 1 to 1 transposition of the C void pointer 
concept in Red/System, it is 1 to 2 (or more), depending on the context.

If you would write a C function such as: 

void *bar() { return((void *)&foo);)


where foo would be another function. If I had to make a binding to 
this function from Red, I would use integer! (or preferably the handle! 
macro) to define the return value.

Six months ago, I wanted to introduce an address! type to be the 
equivalent of C void pointer. It would have worked as an integer!. 
But as it would have been only used to in C binding definitions, 
I thought it would be a waste to have a first-class datatype just 
for that, when integer!, pointer! [...], or a macro could do the 
same job.

If [pointer! [byte!]] could do the job and make C coders happy, I 
will add it to Red/System.

I'm not concerned with all that here. Let me make this very concrete. 
In runtime/common.reds, changing

#define byte-ptr!	c-string!

to

#define byte-ptr!	pointer [integer!]

Would solve all my current concerns

Well, this is certainly not the right definition a byte! pointer. 
:-) Can't you wait until monday when all the current issues regarding 
NULL and documentation will be fixed?