[Gambas-user] BUG Install on mandriva

[Benoît Minisini]

> > VarPtr() must be used when a C-function argument is actually a pointer to
> > a variable that will be modified by the called function.
> 
> I disagree for two or three reasons. First, an external declaration
> already implies that the declaration refers to something extraneous to
> gambas, where things are different. This is even more true for gambas,
> which only needs EXTERN to interface to modules written in other
> languages, because it has a more natural and efficient way to use its
> own modules/components.
> The second reason is that using BYREF in the external declaration, the
> task of the function is well defined for now and forever. Actually, in
> that case, BYREF would internally mean something different - but anyway
> all the declaration takes a totally different way in its implementation.
> But, at high, logic level, BYREF would keep its intimate meaning.
> Third, if I can not declare an external parameter with BYREF, I must
> then use varptr() on every call - this moves the logic from declaration
> to its usage - and there is more to type on the keyboard.

This is not possible, because Gambas use dynamic linking. You have to specify 
VarPtr() at function call. 

Moreover, even if I agree that the ByRef syntax is nicer, it cannot be used 
there again because of the dynamic linking: ByRef for a Gambas function 
implies compiling a different code than your ByRef for an extern function, and 
as Gambas may not know at compile time if a function is extern or "intern", he 
cannot do that. 

Moreover, whereas ByRef can be applied to any Gambas assignment expression, 
VarPtr() can only be applied to a local variable or a global variable of the 
current class.

So...

> 
> >> I see it. This is why I stressed on pointers (or MEMORY keyword, which I
> >> don't know). Another way is to have a PACKED keyword, so the user can
> >> put holes where needed. Kind of a dirty thing... but I don't believe
> >> that libffi can do magic - if a compiler chooses to reorder the fields,
> >> libffi can not know. I say this because I have seen the alsa structures
> >> - there is nothing that prevents a compiler to do strange things, but
> >> libasound must be compatible with applications, at least on a
> >> inter-architecture basis.
> > 
> > I think so. And PACKED can be implemented, but then your sources won't
> > work anymore on ARM architecture, where non-aligned access are forbidden
> > and lead to a bus fault!
> 
> The same is true with pointers and MEMORY streams. The idea about PACKED
> is extreme, it lets the programmer do whatever he wants, with all the
> (few) benefits and (lot of) caveats of such a thing. But are you saying
> that memory streams have no risk on ARM?

Yes, because data is read by using memcpy(), not a pointer access.

> The problem is: are you sure that pointers, memory streams and varptr()
> are needed? 

Yes. Having a stream allows to use all the stream functions, so it is useful.

> Memory streams can be used to peek everywhere in memory, but
> you know well that this is a non-sense. The only legitimate memory
> addresses are those returned by some form of alloc(), or indirectly by
> functions which use, in turn, alloc(), or addresses already in use by
> variables. All these things could disappear if you implement correctly
> "byref" and structures, gaining a much more clean design.

I admit that the design may not be perfect, but again all these syntax cover 
all the needed features for memory access. This is not just a matter of using 
one keyword instead of another one. And structures are implemented correctly, 
except that you cannot pack them.

And beware: memory allocated by Alloc() must be freed with Free(), and you 
must not use Free() to free memory allocated by an extern function! Alloc() 
does not call the glibc malloc() directly, and Free() does not call the glibc 
free() directly too.

Regards,

-- 
Benoît Minisini