«

"Richard Heathfield" <> wrote in message
news:bhl2mk$1c6$...
> Jussi Ekholm wrote:
>
> > jacob navia <> wrote:
> >> There is "magic bullet" of course, I am not trying to sell you
> >> something since my compiler system is free. It is a great tool for PC
> >> applications, where there are no real time and memory constraints.
> >
> > I apologize if this is a stupid question (although, I recall someone
> > saying "there is no stupid questions, only stupid people...), but what
> > is this "magic bullet" you're talking about?
>
> Jacob, I'm sure, meant to write "there is no silver bullet".
>

Exactly. Thanks for the correction

> In "The Mythical Man-Month" by Fred Brooks, there is a chapter entitled "No
> Silver Bullet - Essence and Accident in Software Engineering". The chapter
> is subtitled: "There is no single development, in either technology or
> management technique, which by itself promises even one order-of-magnitude
> improvement within a decade in productivity, in reliability, in
> simplicity".

On Sat, 16 Aug 2003 19:39:36 +0200
"jacob navia" <> wrote:

>
> "Bjorn Reese" <> wrote in message
> news:...
> > jacob navia wrote:
> >
> > > #define free GC_free
> > [...]
> > > #define free(a) (a=NULL)
> >
> > What about memory allocated by third-party libraries, which was not
> > allocated using GC_malloc() and thus must be freed with free()?
>
> Memory not allocated by the collector will not be touched of course.
> External libraries work without any problems!

The point was that if the external library passes you a pointer that you
are expected to free, then after your redefinition of free the following
code fragment gives a memory leak

{
char *derf;
derf = foo(); /* foo is in library and returns pointer from malloc */
/* do some stuff */
free(derf);
}

I would also point out that if you don't have to free some dynamically
allocated memory but other pieces of dynamically allocated memory do
need freeing you (or at least I) am more likely to make a mistake and
either use the standard free on a pointer that should be left for the GC
or not call it on a pointer to memory provided (though a library) by
malloc.
--
Mark Gordon

"Mark Gordon" <> wrote in message
news:...
> The point was that if the external library passes you a pointer that you
> are expected to free, then after your redefinition of free the following
> code fragment gives a memory leak
>
> {
> char *derf;
> derf = foo(); /* foo is in library and returns pointer from malloc */
> /* do some stuff */
> free(derf);
> }
>
> I would also point out that if you don't have to free some dynamically
> allocated memory but other pieces of dynamically allocated memory do
> need freeing you (or at least I) am more likely to make a mistake and
> either use the standard free on a pointer that should be left for the GC
> or not call it on a pointer to memory provided (though a library) by
> malloc.

Yes, this could be a problem. Fortunately libraries that pass allocated
memory expecting you to free it are very rare. This is because they can
only work with one compiler system. The "malloc" implementations are
not compatible: you can't free with gcc's free() a piece of memory allocated
with MSVC, for instance.

That's why this example is not very real. Most libraries are designed to
work with many compiler systems and do not rely on the user freeing memory.
Usually they give an interface where you call some API to free the
allocated memory.

jacob

On Sat, 16 Aug 2003 10:57:25 +0000 (UTC), in comp.lang.c , Richard
Heathfield <> wrote:

>In "The Mythical Man-Month" by Fred Brooks, there is a chapter entitled "No
>Silver Bullet - Essence and Accident in Software Engineering". The chapter
>is subtitled: "There is no single development, in either technology or
>management technique, which by itself promises even one order-of-magnitude
>improvement within a decade in productivity, in reliability, in
>simplicity".

Like all generalisations, this one is wrong. Counterexamples:

Clean water in london wiped out cholera inside a few year
pennicilin stopped a wide range of deaths
consumer GPS in the 1990s reliably position you to within feet
and what about HTTP?

I guess you could argue that none of these is a "single development".
Hmm, in that case, nothing ever is.

--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>


----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---

On Sat, 16 Aug 2003, jacob navia wrote:
>
> "Mark Gordon" <> wrote ...
> > The point was that if the external library passes you a pointer that you
> > are expected to free, then after your redefinition of free the following
> > code fragment gives a memory leak
> >
> > {
> > char *derf;
> > derf = foo(); /* foo is in library and returns pointer from malloc */
> > /* do some stuff */
> > free(derf);
> > }

Simple answer: GC_free(x) can look to see if it allocated x. If it
did, it marks it for cleanup. If it didn't, it can pass x on to the
implementation's 'free' function (and kind of assume the user must
know what he's doing). Not a silver bullet, but avoids memory leaks.

> > I would also point out that if you don't have to free some dynamically
> > allocated memory but other pieces of dynamically allocated memory do
> > need freeing you (or at least I) am more likely to make a mistake and
> > either use the standard free on a pointer that should be left for the GC
> > or not call it on a pointer to memory provided (though a library) by
> > malloc.
>
> Yes, this could be a problem. Fortunately libraries that pass allocated
> memory expecting you to free it are very rare. This is because they can
> only work with one compiler system. The "malloc" implementations are
> not compatible: you can't free with gcc's free() a piece of memory allocated
> with MSVC, for instance.

Well, *if* the library is compiled with the same object file format as
the compiler's generated code, then the library function (say Strdup())
doesn't actually contain any memory management code. It just contains
a call to '_malloc' or '@_MALLOC' or whatever, and when the linker
does its magic, the '_malloc' in the library code and the '_free' in
the user code match up and everyone's happy.

Of course, last I checked you couldn't use MSVC library files with GCC
object files, so all bets are off. But it's a file format problem,
not a library problem.

> That's why this example is not very real. Most libraries are designed to
> work with many compiler systems and do not rely on the user freeing memory.
> Usually they give an interface where you call some API to free the
> allocated memory.

Strdup.

Also, I'm in the middle [or end, depending on motivation] of writing
an image-format library that has lots of functions like

int ReadPPM(const char *fname, unsigned char *(*data)[3], int *w, int *h);

for which the user is expected to call 'free' on the data pointer
when necessary:

unsigned char (*data)[3];
int w, h;
int rc = ReadPPM("input.ppm", &data, &w, &h);
if (rc < 0)
return EXIT_FAILURE;
else {
process(data, w, h);
free(data);
return 0;
}

Obviously the answer to this particular case is, "Don't use GC for
your image-format library's applications," and that's perfectly
reasonable. Just pointing out that there probably are a lot of
libraries in C for which GC would eventually be a problem.

-Arthur

In article <bhm805$gee$>, jacob navia wrote:
>
> Yes, this could be a problem. Fortunately libraries that pass allocated
> memory expecting you to free it are very rare. This is because they can
> only work with one compiler system. The "malloc" implementations are
> not compatible: you can't free with gcc's free() a piece of memory allocated
> with MSVC, for instance.
>
Wrong. Shared and static libraries will contain only reference to malloc
and free calls. They will be resolved only when the final program is
linked (or, in case of dynamic linking, when it is run). At that point
a single implementation of malloc will be used an all is well. As long as
MS linker can read gcc's object files (and vice-versa), there is no problem in
mixing different compilers at all.