I'm indifferent as to alignment, left alignment sounds fine as it's
easier for parsing and grepping.
Width: IMO 20, not 16, since offsets are 64-bit. (And there is no need
to be a power of 2, because (a) we use atomic move-into-place without
in-place edits, and (b) the sequence number is currently supposed to be
at the start, so it'd throw off the block alignment anyway.)
Overflow: yes, we should check for that, at write time or at read time.
Or both. I think svn__atoui64() take care of that for the 'read' end...
Peter Samuelson wrote on Thu, Jul 07, 2011 at 12:12:29 -0500:
>
> [hwright_at_apache.org]
> > + /* Update the manifest. */
> > + SVN_ERR(svn_stream_printf(manifest_stream, iterpool,
> > + "%016" APR_OFF_T_FMT, next_offset));
> > + next_offset += finfo.size;
>
> Bikeshed time! I think space-padding (either %16 or %-16) would look
> better than the zero-padding. The only reason to use ASCII digits is
> for human readability, after all, right? left-alignint (%-16) also
> means the scanf at the other end only has to scan 6 or so digits
> instead of all 16, not that that's meaningful. (:
>
> Also, for purely theoretical defense against ridiculousness, should we
> assert(next_offset <= 9999999999999999llu) or so? (Not sure if there's
> a portable suffix for a 64-bit constant.) Overflow is basically
> impossible with today's computing and disk resources, but it would be
> kinda bad if anyone managed to get it to happen.
> --
> Peter Samuelson | org-tld!p12n!peter | http://p12n.org/
Received on 2011-07-07 19:54:59 CEST