Re: large files: when ubiquitous?
From: Kasper Dupont (kasperd_at_daimi.au.dk)
Date: 05/10/04
- Next message: Tuukka Toivonen: "Re: Why linux is so stupid with hardware drivers?"
- Previous message: Kasper Dupont: "Re: Futex"
- In reply to: P.T. Breuer: "Re: large files: when ubiquitous?"
- Next in thread: P.T. Breuer: "Re: large files: when ubiquitous?"
- Reply: P.T. Breuer: "Re: large files: when ubiquitous?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Mon, 10 May 2004 19:26:10 +0200
"P.T. Breuer" wrote:
>
> Kasper Dupont <kasperd@daimi.au.dk> wrote:
> > "P.T. Breuer" wrote:
> > >
> > > pid_t *pid = malloc(sizeof(*pid));
> > > .... first( ... (void **)pid ...);
> >
> > That is even more wrong.
>
> That's what you said to do. I was merely writing it out for you so that
> you can see that it is silly. Why you say that what you say is wrong is
> bizarre.
I did not tell you to malloc memory in that part of the
code. OK, so maybe I didn't tell you to take the address
of pid when passing it to the function, I thought it was
obvious that change needed to be done as well.
>
> > You don't need to malloc any
> > memory to get the value out, and the cast is still wrong.
> >
> > pid_t *pid;
> > .... first( ... (void **)&pid ...);
> >
> > And then do whatever you want to do with that pid like:
>
> ??? I really don't understand you - that is strange coding. Are you
> trying to suggest that one should first of all store a pid in a malloced
> bit of memory, then pass its address into the database as a key, then
> get that address out again during the iteration? Then free the memory.
> I think you are!
Yes, that is the only sensible way to use that database
interface. Of course freeing should only happen when you
delete the object from the database. There might be other
ways to handle memory allocations than through malloc and
free, but you need to be consistent.
>
> That's possible, but unnecessary - while in the general case one does
> need a key manager to pass off "handles" for keys into the database
> functions, that isn't necessary in this case, because the database keys
> that are being stored are smaller than the size of their addresses would
> be! So we can just pass the keys instead of their addresses and save
> ourselves the hassle of dealing with the key manager.
That would make sense, unfortunately the database you are
using does not seem to support that.
>
> The code is fine. Gcc merely complained about it, unnecessarily.
gcc produce a warning because the code is wrong. If you
don't believe me report it as a bug and see how quickly
the gcc developers will close it.
And BTW, don't expect them to be nearly as patient as me.
>
> It is not smart. The algorithm incorrectly warns when it does not need
> to warn. It complians about
>
> long pid;
> ... first(... (void **)&pid ...)
>
> but not about
>
> long pid;
> void *data;
> ... first(... &data ...)
> pid = (long)data;
>
> which is exactly the same, semantically, but less clear as code.
That is exactly the point. It is *impossible* to write a
compiler that will notice every possible mistake you could
make. But it does a quite good job. Your second example
just shows how to make the code so unclear that gcc will
not notice anything wrong. But of course it doesn't fix
the design problem.
> Gcc
> does NOT have the right to perform any optimizations based on the idea
> (in the first example) that &pid does not coincide with a void** because
> there are NO void** for it to coincide with, hence any optimization it
> does is valid for both the case of there are and there aren't. What are
> you going to suggest?
It might be, that in your case, the compiler would not
perform any optimizations that change anything. Again it
is impossible to know for sure if that would happen. What
the compiler warns you about is code, that is incorrect
and could potentially lead to unexpected optimizations.
>
> Examine your reasoning. See where it fails.
It doesn't. You just didn't take the required time to
understand it.
>
> > > gcc uses the idea that different types live in different places in
> > > order to reorder (and presumably elide) statements to advantage.
> >
> > Where the h... did you get that idea from? I have told
>
> The idea comes from you, and I believe it is a fairly accurate summary -
> I should have said "abstract instructions", not "statements", but it's
> accurate modulo that.
You are wrong. I never said, that was happening. You
are the only person who ever said that, and I explained
at once that wasn't the case. I even provided you an
example clearly showing, you were wrong. You keep making
the same incorrect statements, and now even try to imply
I made them. That is simply not true.
-- Kasper Dupont -- der bruger for meget tid paa usenet. For sending spam use abuse@mk.lir.dk and kasperd@mk.lir.dk I'd rather be a hammer than a nail.
- Next message: Tuukka Toivonen: "Re: Why linux is so stupid with hardware drivers?"
- Previous message: Kasper Dupont: "Re: Futex"
- In reply to: P.T. Breuer: "Re: large files: when ubiquitous?"
- Next in thread: P.T. Breuer: "Re: large files: when ubiquitous?"
- Reply: P.T. Breuer: "Re: large files: when ubiquitous?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
