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

Johannes Schindelin [off-list ref] 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.

quoted

quoted

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.  If there is
such a deep meaning, it needs documented, and if there isn't then probably
the use of (uint32_t *) should also be fixed.

Hi,

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

Johannes Schindelin [off-list ref] writes:

quoted

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.

quoted

quoted

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