Re: [PATCH v2] builtin-fast-export: Add importing and exporting of revision marks

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

On Sat, 7 Jun 2008, Junio C Hamano wrote:

> Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes:
> 
> > Okay, I looked again, and indeed, you _copied_ it.  Instead of using the 
> > functions mark_object() and get_object_mark() which are there only to be 
> > used by you.
> >
> > So please fix.
> >
> >> >Even if that is the case, doesn't "(uint32_t *)deco->decoration - 
> >> >(uint32_t *)NULL" mean the value range for deco->decoration is 
> >> >one-fourth of U32?
> >
> > It is.  But since every object needs already at least 20 bytes, and we do 
> > not even have the complete address space to put objects into, and we do 
> > not plan to support 64-bit only repositories, I think we are fine.
> 
> Oh, I was not complaining about the one-fourthness.  I was wondering why 
> "(uint32_t *)", which makes it look like the type itself has very deep 
> meaning for this computation, was used, instead of "(char *)" or 
> something that makes it much clearer that what could be pointed at by 
> the pointer does not matter and you are only using them as fake 
> integers.

Probably you are right.  I had the impression that you could not rely on 
(void *) having the full precision, but that was completely bogus.

It could be changed to (char *) safely.

Ciao,
Dscho

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux