Could you please give me some advice on GC in C?

[Keith Thompson]

You can't do that, because malloc has to be system sensitive. It
has to know things not directly available, such as where to get
memory, alignment requirements, etc.

Did you, by any chance, actually mean to say that you *can* do that,
but only in a system-sensitive manner?

 

[Ben Bacarisse]

Where am I assuming even an incorrect implementation? All I am
assuming is a method of deciding whether a pointer to anywhere
within an allocated block exists.

Yes. You assume that adding a valid offset to a pointer will confuse
a garbage collector. Such a collector would an incorrect
implementation of the technique. That's not fair critique unless you
know (and you might do) of such brain-dead implementations.

I could probably replace the
+128 with writing a hex version of the pointer value, and restoring
it later, which avoids all arguments about how clost the possible
pointer must be.

No, not by using hex you can't -- your program would be in the realms
of undefined behaviour even without a garbage collector. I know what
you mean though -- you might write the pointer using %p and read it
back later. That *would* have been fair and I would not have
commented. It would show the lengths you have to go to to confuse a
good collector. Instead you implied that a simple and valid pointer
manipulation might cause trouble.

 

[Ben Bacarisse]

You can't do that, because malloc has to be system sensitive. It
has to know things not directly available, such as where to get
memory, alignment requirements, etc.

Er, yes. Why does that mean one can't have a C implementation where
malloc calls the Boehm allocator?

 

[Keith Thompson]

No, not by using hex you can't -- your program would be in the realms
of undefined behaviour even without a garbage collector. I know what
you mean though -- you might write the pointer using %p and read it
back later. That *would* have been fair and I would not have
commented. It would show the lengths you have to go to to confuse a
good collector. Instead you implied that a simple and valid pointer
manipulation might cause trouble.

Yes, I think you could fool Boehm GC by saving a pointer value in hex.

Treat the pointer object as an array of unsigned char, and use sprintf
or something similar to save the representation in hexadecimal in a
string somewhere (or even write it to a file). Then clobber the
actual pointer, wait a while, and restore the pointer from the hex
string. C semantics require this to restore the valid pointer value;
Boehm GC is likely to assume that no copy of the pointer is stored
anywhere in memory and release the pointed-to memory. It's really the
same idea as using "%p".

(This is not intended to be an argument against GC; it's just an
obscure corner case that you have to watch out for when using it, and
that would have to be taken into account if GC were ever added to the
C standard (presumably as an optional feature).)

 

[Ben Bacarisse]

Yes, I think you could fool Boehm GC by saving a pointer value in hex.

Treat the pointer object as an array of unsigned char, and use sprintf
or something similar to save the representation in hexadecimal in a
string somewhere (or even write it to a file). Then clobber the
actual pointer, wait a while, and restore the pointer from the hex
string. C semantics require this to restore the valid pointer value;
Boehm GC is likely to assume that no copy of the pointer is stored
anywhere in memory and release the pointed-to memory. It's really the
same idea as using "%p".

Yes, that would fool most GCs but it's not what CBFlaconer was talking
about and thus not what I said was impossible without UB. CBF was
talking about "writing a hex version of the pointer value" and your
example writes out the representation.

I know this is a pedantic point, but it seems to matter in this case.
Valid manipulations of the pointer's value don't usually fools
collectors, but lots of manipulations of the representation do.

The writing and reading of the pointer using %p is defined in terms of
what is does to the value.

 

[Keith Thompson]

Yes, that would fool most GCs but it's not what CBFlaconer was talking
about and thus not what I said was impossible without UB. CBF was
talking about "writing a hex version of the pointer value" and your
example writes out the representation.

I know this is a pedantic point, but it seems to matter in this case.
Valid manipulations of the pointer's value don't usually fools
collectors, but lots of manipulations of the representation do.

The writing and reading of the pointer using %p is defined in terms of
what is does to the value.

Ok, I see what you mean. I didn't take "writing a hex version of the
pointer value" quite that literally. (Note that sprintf with "%p"
uses hex on many systems.)

You could also fool a garbage collector by something as simple as
byte-swapping a pointer in place (or shuffling the bits if a pointer
is 1 byte).

 

[Flash Gordon]

No, he deliberately snipped the portion that shows his imbecility,
below:

^^^^^

Which pointed out that the code would require modification.

You have recently claimed that code which uses implementation *defined*
behaviour "does not work". Are you now retracting that claim, since
obviously it works on the on the implementations where it worked by
definition of those implemenations, just like you nmalloc package works
on implementations which provide sbrck and where you method of dealing
with alignment works?

Either you flat statement that code which uses implementation defined
behaviour does not work is false, or your nmalloc package does not work.

Oh, and your nmalign function assumes that a pointer can be converted to
a long with no loss of information, something the standard does not
guarantee. In fact, the standard does not guarantee there is ANY integer
type which would work. It then assumes things about the converted value
which are not guaranteed to be true.

It has at least one identifier (_sysquery) at file scope which starts
with an underscore, which is reserved for the implementation and so not
available for user code.

Now, have you posted all these other limitations every time you have
said it will work on any implementation which provides sbrck? I don't
remember you pointing them out, so your code does not work by your own
arguments.

 

[James Kuyper]

No, not by using hex you can't -- your program would be in the realms
of undefined behaviour even without a garbage collector. ...

Citation, please?

 

[Ben Bacarisse]

Citation, please?

Sorry, none available since it is a "can't" rather than a "can"
argument. I just can't see any way to write the value of a pointer in
hex so that it can be recovered later.

%p might use hex, but that is not assured, and there is no int type
that can always be used (6.3.2.3 p6). Of course, I could simply be
missing the way to do it. I should have asked CBFalconer what he
means by writing the value in hex and left it at that.

If you take the phrase less literally and allow the representation or
the pointer to be used then, yes, its possible. But then I why go to
the bother of using IO? Almost any manipulation of the representation
can be used to exhibit a potential problem with a collector.

 

[James Kuyper]

Sorry, none available since it is a "can't" rather than a "can"
argument. I just can't see any way to write the value of a pointer in
hex so that it can be recovered later.

%p might use hex, but that is not assured, and there is no int type
that can always be used (6.3.2.3 p6). Of course, I could simply be
missing the way to do it. I should have asked CBFalconer what he
means by writing the value in hex and left it at that.

If you take the phrase less literally and allow the representation or
the pointer to be used then, yes, its possible. ...

You can use "%p" to display and retrieve the value of a pointer, and
that presents a problem for GC, regardless of whether it actually prints
in hex format.

You can convert a pointer value to uintptr_t and print it in
hexadecimal, and then read it back in, and reverse the conversion; this
present a problem for GC on any systems which supports uintptr_t,
regardless of the fact that there are other systems which do not support it.

You can print out the representation of a pointer in hex, and read it
back in again, and that cause a problem for GC, even though Chuck
specified he was printing the value, not the representation.

... But then I why go to
the bother of using IO? Almost any manipulation of the representation
can be used to exhibit a potential problem with a collector.

I believe that this is precisely the point he was trying to make.

 

[CBFalconer]

.... snip ...

But frankly life's too short to argue with argumentative people.
You note, correctly, that CBF has been especially cantankerous
recently. The same can increasingly be said about yourself.

Probably true enough. I recently got sufficienly sick of RHs
foolish carping and responded. I think I have largely ignored his
silly postings in the past.

 

[CBFalconer]

.... snip ...

Now, have you posted all these other limitations every time you
have said it will work on any implementation which provides
sbrck? I don't remember you pointing them out, so your code does
not work by your own arguments.

By the way, it is "sbrk". What I believe I have done is include
the information that nmalloc was written to run on DJGPP. I have
not made a point of being specific about the variations involved.
Actually, there is no need to specify this, since it is impossible
to write a generic portable malloc package.

 

[CBFalconer]

Sorry, none available since it is a "can't" rather than a "can"
argument. I just can't see any way to write the value of a pointer in
hex so that it can be recovered later.

You can make a hex representation of any bit pattern. Since
pointers are stored in memory, they are made up of bits. Therefore
representable in hex. This is a silly argument.

 

[CBFalconer]

Ben Bacarisse wrote:
.... snip ...


I believe that this is precisely the point he was trying to make.

Thank you.

 

[Keith Thompson]

Ben Bacarisse wrote: [...]

Sorry, none available since it is a "can't" rather than a "can"
argument. I just can't see any way to write the value of a pointer in
hex so that it can be recovered later.

You can make a hex representation of any bit pattern. Since
pointers are stored in memory, they are made up of bits. Therefore
representable in hex. This is a silly argument.

I think the point is that "value" and "representation" are two
different things. For example, two different bit patterns might
represent the same pointer value; your approach then gives two
distinct hex representations for one value. Yes, it's a nitpick; in
any case, you can reconstruct the same pointer value from either
representation.

(I suppose you could use sprintf with "%p" to obtain a string
representation of a pointer value, and then construct a hexadecimal
string from that, but that's not what anybody meant.)

 

[Ben Bacarisse]

Thank you.

The whole thread could have been circumvented had you posted a program
that manipulated the representation, then. Instead you posted one
that manipulated the value, and talked about doing IO on the value.

 

[Chris Dollin]

You allocate GC memory using GC_malloc (or, better, the macro
GC_MALLOC) and, of course, one can arrange that this be a replacement
for malloc but I understood the two heaps were usually separate.

Ah! Sorry, I had an over-general interpretation of `malloced` in
my head at that time. I /thought/ something was iffy, and I was
right -- it was me.

 

[Chris Dollin]

You allocate GC memory using GC_malloc (or, better, the macro
GC_MALLOC) and, of course, one can arrange that this be a replacement
for malloc but I understood the two heaps were usually separate.

Ah, I was being an over-generalising idiot. Where's my cow?