«

jacob navia wrote:

> I have never seen a program that XOR pointers.

It was at one point the standard hack to do doubly-linked lists
with just one link. (Not in C, perhaps. I seem to remember that
I came across it for the PDP-8, except, since the PDP-8 didn't
have a XOR [1], one used TAD instead.)

[1] For almost all X you might have expected from a processor,
the PDP-8 didn't have X. Like a STORE instruction, or index
registers [2].

[2] For some value of "STORE", or index, or registers.

--
Chris "Mary Hopkins" Dollin

Hewlett-Packard Limited registered no:
registered office: Cain Road, Bracknell, Berks RG12 1HN 690597 England

jacob navia <> writes:

> Philip Potter wrote:
>> jacob navia wrote:
>
>>> ???
>>>
>>> You XOR pointers?
>>>
>>> You write pointer to files?
>>
>> It doesn't matter what /I/ do, but what the previous programmers on
>> the same project did; and we all know it's a mistake to make
>> assumptions about such people.
>>
>
> I have never seen a program that XOR pointers.
> Neither one that writes pointers to disk, then reads them back.
> Sorry, I am programming in C since relatively few years. I
> started around 1984.

Thats silly.

Conceivably a distributed system could store a block of pointers on a
remote node for a while via a remote copy which does not increment local
system reference counts. There are lots of things which can cause it to
fail. And if people become too reliant on it it would be a *nightmare*
to find the cause of a problem since none of the mallocs have frees to
match against.

The bottom line is this (using my typically black and white views of
such things) : Garbage Collection sucks. It promotes lazy programming
and a "get it all for free" mentality and is partly responsible for the
bloatware which is now regularly released .

Few seem to consider memory footprint anymore.

>
>> (A side point: does your GC count a pointer to the middle of an
>> array as a reference? If not, that's another (much more common) case
>> where memory could be erroneously freed.)
>>
>
> It counts as a reference of course.

jacob navia wrote:
> Tor Rustad wrote:
>> jacob navia wrote:
>>> As many people know, I think that garbage collection is a good
>>> solution for many memory allocation problems.
>>
>> Right, but I'm more interested in knowing what Richard Heathfield
>> would have liked C99 to include, but C99 didn't.
>>
>
> Yes, that is obvious. You live and love for R.H.

Your garbage collector appears to be broken.

--
Tor < | tr i-za-h a-z>

cr88192 wrote:
> "Tor Rustad" <> wrote in message

[...]

>> IMO, the main domain of C is system and embedded development. Even if
>> extending this domain by including communication, security development and
>> DB engine development, a GC seems neither important, or of much interest.
>>
>
> errm, are you trying to claim that all of us good old desktop-pc developers
> are all off using stuff like Java and C# or something?...

No, I say that C1X should focus on the main domain of C, and try to keep
the language small and simple. The C99 variable-length arrays was a step
too far. Adding GC to Standard C, would IMO be a major mistake.

> must of us are in a land where we still want things like GC, but don't feel
> like selling our souls to some proprietary VM framework to get it.

Nobody is stopping you from using the Boehm GC.

--
Tor < | tr i-za-h a-z>

santosh wrote:
> In article <4742c71a$0$27407$>, jacob navia
> <> wrote on Tuesday 20 Nov 2007 5:07 pm:
>
>> Philip Potter wrote:
>>> jacob navia wrote:
>>>> ???
>>>>
>>>> You XOR pointers?
>>>>
>>>> You write pointer to files?
>>> It doesn't matter what /I/ do, but what the previous programmers on
>>> the same project did; and we all know it's a mistake to make
>>> assumptions about such people.
>>>
>> I have never seen a program that XOR pointers.
>> Neither one that writes pointers to disk, then reads them back.
>> Sorry, I am programming in C since relatively few years. I
>> started around 1984.
>
> I guess that intentionally obfuscated (for whatever reasons) programs
> might XOR their pointers.

Yup, I have seen this trick used in software based copy-protection
schemes, the intent was to make the job harder for crackers &
dis-assemblers.

The old AARD code used by Microsoft in win.com, was far worse than
that... debuggers was defeated by pointing interrupts to invalid code,
code itself was XOR encrypted. Duh.. XOR'ed pointers is nothing,
compared to the Windows AARD code.

See "Undocumented DOS" by Andrew Schulman.

--
Tor < | tr i-za-h a-z>

On Nov 20, 4:31 am, Chris Dollin <chris.dol...@hp.com> wrote:
> Ben Bacarisse wrote:
> > Chris Dollin <chris.dol...@hp.com> writes:
> >> I /think/ that adding exceptions would introduce run-time overheads: I
> >> could of course be wrong.

It forces call stack uniformity (the EH needs to be able to crawl up
the stack and unwind the stack in a uniform way.) So for example,
tail-call recursion might not be able to be turned into gotos if there
is a potential for exceptions to be thrown under a call inside that
tail recursion (actually, I don't know that for sure -- but its one of
those things you would have to check very carefully). I also know
that compilers such as WATCOM C/C++ definitely use very non-uniform
stack frames whenever they can get away with it, for leaf-function
optimization reasons.

> > If you mean a cost incurred by program that don't even use them (just
> > in case)
>
> If an entire program doesn't use any EH, then you'd expect the overhead to
> be minimal.

If the entire program is one file, then sure -- the compiler could
detect this and drop the overly-uniform call-stack frames. However,
more real projects are multi-file, and not very many compilers do link-
time recompiling (though Intel's compiler does that).

> It might not be zero, unless there's a way to tell the compiler to
> compile compilation units assuming that they'll be used in an EH-free
> program: it's possible that code that might execute in an EH
> environment might suffer optimisation penalties. On the other hand,
> I don't see that they'd be much different from any penalties already
> paid for set/longjmp.

The set/longjmp storage is handled by the programmer. With EH, it has
to dynamically be stored somewhere -- presumably in the stack itself
(this seems to be the only solution that would make sense in multi-
threaded environments.)

> I seem to recall that earlier C++ compilers had this sort of EH-controlling
> switch. (Not having using C++ in anger recently, I don't know about
> current C++ compilers, not even specifically g++.)

Watcom and Microsoft definitely retain those switches.

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

Paul Hsieh wrote:
> On Nov 20, 4:31 am, Chris Dollin <chris.dol...@hp.com> wrote:
>> Ben Bacarisse wrote:
>>> Chris Dollin <chris.dol...@hp.com> writes:
>>>> I /think/ that adding exceptions would introduce run-time overheads: I
>>>> could of course be wrong.
>
> It forces call stack uniformity (the EH needs to be able to crawl up
> the stack and unwind the stack in a uniform way.) So for example,
> tail-call recursion might not be able to be turned into gotos if there
> is a potential for exceptions to be thrown under a call inside that
> tail recursion (actually, I don't know that for sure -- but its one of
> those things you would have to check very carefully). I also know
> that compilers such as WATCOM C/C++ definitely use very non-uniform
> stack frames whenever they can get away with it, for leaf-function
> optimization reasons.
>

This is only true if your language needs destructors.
C doesn't need that, so all that does not apply.

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

On Nov 20, 12:40 am, Philip Potter <p...@doc.ic.ac.uk> wrote:
> jacob navia wrote:
> > Keith Thompson wrote:
> >> jacob navia wrote:
> >>> Normal applications like 99.9999 C applications that can use the GC
> >>> without any problems!
>
> >> Is 99.9999 intended to be an exaggeration, or do you really think the
> >> number is that high (I assume it's a percentage)?
>
> > How many applications you have seen that write pointers into
> > disk files, xor pointers or do such kind of nonsense?
>
> > I have never seen one.
>
> Jacob, don't quote figures you fabricated then use anecdotal evidence to
> back them up. That's just not science.

Lol! Can you point me to any other "science" being practiced in this
newsgroup? Come on now, aside from some pointer arithmetic (which
Boehm has not problem with)

> [...] Unless you have done proper
> research across a wide cross-section of application domains and coding
> groups, the fact that you've never seen one means precisely zilch. (I
> have seen precisely zero uses of ptrdiff_t - I guess it doesn't exist,
> right?)

The Better String Library uses ptrdiff_t to deal with aliasing in a
conservative and portable way.

> It doesn't matter how many people can use GC successfully, it matters
> how many /can't/

Jacob's response to you here is very on point. GC is being proposed
to deal with the much worse problem of dealing with malloc and free.
The problems that might happen due to misuse of GC will be a drop in
the ocean compared with the rampant memory leaks C programmers create
today.

> [...] - and because the sort of problems that we're talking
> about, the errors are of the intermittent runtime difficult-to-debug
> variety. If I can't be absolutely sure that I can use your GC on my
> standard C program, I won't bother. I'd have to go through the entire
> program to make sure it doesn't do 'clever' stuff with pointers; or
> start a new C-with-GC program from scratch (but I wouldn't do that
> because I'd be stuck with one compiler on one platform).

You are worried about non-opaque (and non-pointer offsetting) pointer
manipulation? No matter what it is you have in mind, its almost
certainly a violation of the standard. Writing pointers to a file
then reading them back? That's extremely brittle coding that I would
be very scared of -- disks can fail, and be accessed asynchronously by
other processes.

Real programs don't do this sort of nonsense. We're talking about a
percentage that is way less than the coverage missed by a typical test
suite for even the best software.

This is why the Boehm collector exists, and is being used in real
production code today.

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

On Nov 20, 7:50 am, jacob navia <ja...@nospam.org> wrote:
> Keith Thompson wrote:
> > jacob navia wrote:
> >> Normal applications like 99.9999 C applications that can use the GC
> >> without any problems!
>
> > Is 99.9999 intended to be an exaggeration, or do you really think the
> > number is that high (I assume it's a percentage)?
>
> How many applications you have seen that write pointers into
> disk files, xor pointers or do such kind of nonsense?
>
> I have never seen one.

Surely the point is that if you want to propose a *standardized* GC
(which would be better done in comp.std.c), then what does and doesn't
break it will need to be specified!

You could either do this negatively:
"As long as you don't xor pointers or write them to disk or ...
(expand 'such kind of nonsense' here) or ... then your program can use
GC safely"

or positively:
"You're allowed to store arbitrarily many pointers in arbitrarily deep
linked sequences, add offsets to them, cast them(?), ..., and GC is
guaranteed to work"

Either way, it seems to me that you'll end up with an extremely long
and unwieldy list of conditions if you want to cover all bases. If you
can't express an idea cleanly, that might indicate that there's
something wrong with it...

>
> --
> jacob navia
> jacob at jacob point remcomp point fr
> logiciels/informatiquehttp://www.cs.virginia.edu/~lcc-win32

"Charlton Wilbur" <> wrote in message
news:...
>>>>>> "cr" == cr88192 <> writes:
>
> cr> after all, if no one really wanted GC, then Java and C# would
> cr> leave them out, and things like Boehm, and the endless other
> cr> custom GC frameworks, would simply not be used.
>
> Of course. *Someone* wants garbage collection. At times, even *I*
> want garbage collection. But you cannot go from that statement, which
> you have provided adequate evidence for, to your original claim that
> *most* programmers want garbage collection without a whole lot more
> evidence than you have thus far provided.
>
> I see enough benefits to having a memory management scheme that's
> completely deterministic and completely in the hands of the programmer
> that I don't want to see it go away as an option. And (as has been
> pointed out) the semantics of C make it very difficult to use a
> garbage collector that's implemented as a library; I think the
> effort's better spent elsewhere.
>

who ever said I wanted malloc to go away?...

I say, we have the GC, and we have malloc.

maybe they can share the same implementation, or maybe they dont.
in any case, I am not arguing that we abandon malloc and put everything in
the hands of the GC, rather, I argue, we have both options available, and
use each where it makes sense.

so, I argue for availability, and that it is a worthwhile option, not
mandatory usage, or even abandoning manual memory management approaches
(when it so happens that they make the most sense...).

for example, my new gc has a function, said, 'gcfree()', and what does it
do? it frees things. why? because freeing something ealier makes things a
lot faster than waiting for the heap to get full and the GC to reclaim it...


as for said "difficulty". I have used garbage collection in my projects for
many years, and have never had much difficulty with it (apart from dealing
with certain cases, such as a previous version of my GC, when used as the
core of a previous script lang, being too damn slow and having to collect
the heap too damn often...).


> Charlton
>
>
>
> --
> Charlton Wilbur
>