Re: large files: when ubiquitous?

From: P.T. Breuer (ptb_at_oboe.it.uc3m.es)
Date: 05/10/04


Date: Mon, 10 May 2004 18:07:46 +0200

Kasper Dupont <kasperd@daimi.au.dk> wrote:
> "P.T. Breuer" wrote:
> >
> > It is not a question of using them - they ARE of type void**. So, no, I
> > (a) am not confused, and (b) that is how I am using them
>
> No. An int* is not a void**. How many times do I have

They are not the same type. I don't know what else you wish to say. So?

> to tell that before you will understand? Are you just

What is it with you? Is there some reason that you should think that I
think that int* and void** are the same type? Why?

> too stupid to understand? Or don't you want to understand?

Thanks, but I understand just fine. Whatever it is that you don't
understand, however, has me mystified, stupid or not.

> > Uhuh. In that case I would have to malloc somewhere as storage for it in
> > order to receive the value given by the first() and next() calls.
> >
> > 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.

> 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!

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.

> printf("%jd\n",(intmax_t)*pid);
>
> You probably need a malloc before you insert something.

Eh? Yes, you are suggesting what I think you are.

> But that appears to be how that database works, so live
> with it or don't use it.

You certainly don't know what you are talking about! However, there's
no way apparently of making you shut up about it.

> > I prefer something like
> >
> > long pid;
> > .... first( ... (void **)&pid ...);
>
> That is wrong. And you are trying to use the database
> for something it cannot do.

It is perfectly fine. I really don't know where you get such ideas
from! What do you suggest is "wrong" with it, pray?

> > Tough. The point of this particular subthread is that gcc is
> > complaining about type-punning (and the name is misleading!) when it is
> > clear that it should not complain.
>
> No, the point of this particular subthread is, that you
> have written some broken code,

The code is fine. Gcc merely complained about it, unnecessarily. If
have given my reasoning. Either answer the reasoning or shut up
already.

> and you refuse to fix
> your code. And now you complain about gcc being so smart,

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. 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? That the optimizer may place pid in a register,
share the register with other longs, and then we discover that we
overwrote a different long when we thought we were writing a void**?
Sorry - no void**'s.

Examine your reasoning. See where it fails. Come back later.

> it can see, what you did wrong.

Explain your criteria for "wrong"! There is nothing wrong with the code
above. You can see what it is equivalent to.

> > 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, what is going on. You didn't bother to check for
> yourself, and you are still making incorrect assumptions.

I don't make such things.

Peter



Relevant Pages

  • Re: large files: when ubiquitous?
    ... > The value is not a pointer, it is a pid. ... In that generic database, keys are nominally given ... of what you store it should be void, ...
    (comp.os.linux.development.system)
  • Re: large files: when ubiquitous?
    ... >> A pointer for keys is the norm in db's. ... And values of type void* too. ... The database makes it clear that it ... addresses indexed by pid. ...
    (comp.os.linux.development.system)
  • [PATCH 7/28] UML - Factor out register saving and restoring
    ... * Licensed under the GPL ... +extern void init_registers(int pid); ... int is_skas_winch ...
    (Linux-Kernel)
  • RE: Identify PID for remote database handle--CLARIFICATION...
    ... Identify PID for remote database handle--CLARIFICATION... ... If you need more information on these views, see the Oracle docs and/or ... I have a perl program running on server A which makes a remote ...
    (perl.dbi.users)
  • Re: Identify PID for remote database handle--CLARIFICATION...
    ... It's a bad mistake to assume _any_ process gets assigned a PID; something one would understand if they, understood IPC as in Interprocess Communication, which occurs at a lower OS level, where Descriptors - which are typically some type of "int" - are used to identify sibling processes with one another. ... Identify PID for remote database handle--CLARIFICATION... ... If you need more information on these views, see the Oracle docs and/or ... I have a perl program running on server A which makes a remote ...
    (perl.dbi.users)