Re: Garbage Collection in C

In article <453339c7$0$5106$ba4acef3@xxxxxxxxxxxxxx>,
jacob navia <jacob@xxxxxxxxxxxxxxxx> wrote:

Note that if the APIs are part of some DLLs the GC will see them anyway.

That statement is vacuously true, since if the number of DLLs that the
GC would pay attention to is precisely zero, that would still be
"some DLLs".

Are you talking about some -particular- DLLs? Are you saying that
the particular GC library you mentioned is able to locate pointers
properly throughout -all- DLLs? Throughout all DLLs specially compiled
with the library??

Your original posting mentioned a number of operating systems, most
of which don't have *any* DLLs. For example, the IRIX operating system
mentioned does not have DLLs (it has DSOs, Dynamic Shared Objects,
but those don't appear to have the same connotations; Windows uses
lots of DLLs, but DSOs are not used particularily often with IRIX,
at least not "Dynamic"-ally.)

Casts to integers do not affect the GC at all.

Amazing. How does the GC deal with the fact that on a number of
systems, pointers are 64 bits, but 'int' is only 32 bits ?


And how does it deal with representation changes that can occur
when casting pointers? About all the C89 standard promises is that

a) any object pointer may be converted to void*

b) void* and char* have the same alignment and representation

c) casting an object pointer to a pointer with a less strict alignment
and back again to the original type is promised to work -- but
representation changes are permitted along the way

d) casting a pointer into an integral type might work (implementation
defined) if the type is wide enough, possibly changing representation
as it goes. Casting an integral type to a pointer might work
(implementation defined). In C89, the result of converting a pointer
to an integral type and back need not compare equal to the original;
in K&R2 and C99 it must compare equal if it is defined at all.

e) function pointers are not object pointers and nothing in the
C89 standard requires that they be convertable to any kind of object
pointer, including no requirement at any level that converting them
to void* will work.

f) function pointers may be converted to a different kind of function
pointer and back again and the result must compare equal to the
original

g) outputting a pointer with a %p format and scanning it back in with %p
format will result in something that compares equal to the original
pointer if the implementation makes %p meaningful at all.

Thus, even just casting an object pointer to char* and storing that
is not certain to result in a bitwise storage identical to the
original object pointer -- and if the garbage collector doesn't know
all the representation conversions that -might- take place and try
them all, it can believe a pointer to be unused when it is still in use.
--
All is vanity. -- Ecclesiastes
.

Relevant Pages

  • Re: re-sharing memory
    ... byte alignment settings for projects. ... The pointer would be written to a global pointer within another ... Then the other DLLs ... > Process B opens and initialises the shared memory. ...
    (microsoft.public.vc.mfc)
  • Re: cpencrypt, in out parameters
    ... Note that non-standard, third party libraries like CPEncrypt, whatever ... the heck it is, and DLLs, which are a part of the Windows operating ... And always test the pointer value returned by malloc() for NULL. ...
    (comp.lang.c)
  • Re: Exporting/importing a variable from a Dll
    ... we can export it and retrieve through pointer to a class and use the method ... > usually poor practice in ordinary programming, more so with DLLs. ...
    (microsoft.public.vc.mfc)
  • Re: Typecast clarification
    ... If 'int' is a four-byte type (which it is on many ... that 'char' and 'int' number the bits in the same order. ... because you cannot dereference a pointer to void. ... safety is automatic - for instance, when converting "signed char" to ...
    (comp.lang.c)
  • Re: Typecast clarification
    ... If 'int' is a four-byte type, there's 24 different byte orders theoretically possible, 6 of which would be identified as Little Endian by this code, 5 of them incorrectly. ... A conforming implementation of C could use the same bit that is used by an 'int' object to store a value of '1' as the sign bit when the byte containing that bit is interpreted as a char. ... there are implicit conversions between void* and any other pointer to to object type. ... If the value is currently of a type which has a range which is guaranteed to be a subset of the the range of the target type, safety is automatic - for instance, when converting "signed char" to "int". ...
    (comp.lang.c)