Re: large files: when ubiquitous?
From: P.T. Breuer (ptb_at_oboe.it.uc3m.es)
Date: 05/10/04
- Next message: Basile Starynkevitch [news]: "Re: Why linux is so stupid with hardware drivers?"
- Previous message: Dragan Cvetkovic: "Re: Why linux is so stupid with hardware drivers?"
- In reply to: Kasper Dupont: "Re: large files: when ubiquitous?"
- Next in thread: Ulrich Weigand: "Re: large files: when ubiquitous?"
- Reply: Ulrich Weigand: "Re: large files: when ubiquitous?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Mon, 10 May 2004 20:31:27 +0200
Kasper Dupont <kasperd@daimi.au.dk> wrote:
> > 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.
I have no idea which hotline to the the God of database code you have,
but it doesn't seem to be working. Open Ears and Listen Deep: the
"keys" are arbitrary values with no content that the database portion
knoweth anything about. Whether they denote process identifiers of
memory addresses is unknown to the database code, which doesn't care.
You know it doesn't care, because they are passed in as void*. That's
all.
Even if you inlined the db code (which you can't!).
> > The code is fine. Gcc merely complained about it, unnecessarily.
>
> gcc produce a warning because the code is wrong.
You don't seem to understand the concepts here. Gcc implements an
algorithm for semantic optimization, and an algorithm for detecting
syntactic correctness. That syntactic algorithm is warning of general
conditions when the semantic algorithm might fail, not warning when the
optimization that the semantic algorithm _does_ do _does_ fail. That's
fine and dandy - it's conservative but it's wrong. This is a case in
point. There is no optimization that it can do here, and hence nothing
that can fail. I would ask it to confine its remarks to cases in which
it actually does some of that optimization that can fail. It's just
annoying as it is.
Let me remind you, it complains about
long pif;
... first(..., (void **)&pif, ...)
... pif ...
but not about
long pif;
void *data;
... first(..., &data, ...)
pif = (long)data;
... pif ...
and as you can see for yourself, there is no optimization that it can
do in the first example that it cannot also do in the second. Try it!
Any extra optimization must involve the use of the storage space for
"data". But it is free in the first case to invent that extra space for
itself and use it too!
> If you
> don't believe me report it as a bug and see how quickly
> the gcc developers will close it.
That it complains is not a functional problem.
It also annoys me when it warns about possibly missing parens in
logical expressions, btw. I know perfectly well what the logical
operator precedences are, and if it doesn't, then it can shut up.
> And BTW, don't expect them to be nearly as patient as me.
You don't seem to have either patience or understanding of the math.
When you have the same number of papers as I have in abstract
interpretation of computer programs, you may huff. Until then, you can
make a small but significant step off the side of the bankside of a
lake.
> > 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.
You don't understand - the word "mistake" is relative only to the
compiler. It is warning you that *IT* may make a mistake in converting
your source code to machine code, ad it is obviously wrong. It can't
make any optimization here, so it can shut up!
> 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.
There is no design problem. The fact that one has to obscure the code
so that gcc shuts up is the 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.
Oh, well done, moriarty.
> Again it
> is impossible to know for sure if that would happen.
No, it's perfectly possible. No optimization implies no changes based
on optimization implies correctness. Or are you going to complain that
the second code is magically "correct" and the first is not?
> What
> the compiler warns you about is code, that is incorrect
The code is correct in the semantic sense.
> and could potentially lead to unexpected optimizations.
Except of course that there aren't any. It knows that. That's what's
wrong with the warning.
> > Examine your reasoning. See where it fails.
>
> It doesn't.
It fails everywhere, as far as I can see!
> You just didn't take the required time to
> understand it.
There isn't anything to understand - you are basing your reasoning on
the idea that code is correct or incorrect, without having a clear idea
of what that means. You want to define the sense of "correct" first.
In case you hadn't noticed, it is syntactically correct. Therefore the
compiler compiles it. The warning is from the compiler saying that it
might not compile it _correctly_.
Tough - it's wrong; it can't help but compile it correctly. If it wants
to use as excuse for going out and not compiling it correctly the idea
that there is some paragraph in a 99 spec that allows it to go out and
shoot your grandmother instead, then that would be wilful nuttiness, and
wilfully nutty compilers are not good. It would have had to go out and
do it "on purpose".
What has IN FACT happened is that there is a bug in its error reporting
system. It reports a violation of certain sufficient conditions that
_guarrantee_ that its optimization algorithm works. But the conditions
are too strict (they're not quite necessary, at least;) - in that there
are weaker conditions that also are sufficient. Those weaker conditions
obviously include "I have done no optimization", which is the case here.
It's simple to suppress the warning when it does no optimization.
> > > > 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
You did not, and I really wish you would stop making things up. The
only example you supplied was of what "type punning" was, for which I
thank you. It was optimisation based on the premise that different
types do not overlap in storage. As I recall it was
*a = 1;
*b = 4.2;
return *a;
where a and b are in fact the same addresses. Great. Under the
assumption that a and b do not overlap, that can be "optimised" to
*b = 4.2;
return *a = 1;
which has different semantics (in the case when a and b overlap).
> the same incorrect statements, and now even try to imply
> I made them. That is simply not true.
Cease naking things up yourself, and you will progress.
Peter
- Next message: Basile Starynkevitch [news]: "Re: Why linux is so stupid with hardware drivers?"
- Previous message: Dragan Cvetkovic: "Re: Why linux is so stupid with hardware drivers?"
- In reply to: Kasper Dupont: "Re: large files: when ubiquitous?"
- Next in thread: Ulrich Weigand: "Re: large files: when ubiquitous?"
- Reply: Ulrich Weigand: "Re: large files: when ubiquitous?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
