{"thread":{"id":"18943","subject":"[PATCH 0/1] Improve progress display in kB range.","startedAt":"2009-04-19T04:32:42Z","lastAt":"2009-04-24T22:20:45Z","messageCount":13,"participants":["James Cloos","Nicolas Pitre","Junio C Hamano","Johannes Sixt"],"isPatch":true,"patchVersion":1,"patchTotal":1},"messages":[{"id":"111633","messageId":"d03620ac4d99f3280df31708032a072a4a6cd96e.1240115957.git.cloos@jhcloos.com","threadId":"18943","inReplyTo":"cover.1240115957.git.cloos@jhcloos.com","subject":"[PATCH 1/1] Improve progress display in kB range.","fromName":"James Cloos","fromEmail":"cloos@jhcloos.com","sentAt":"2009-04-19T04:32:42Z","receivedAt":"2009-04-19T04:32:42Z","isPatch":true,"sender":{"key":"cloos@jhcloos.com","avatar":"https://gravatar.com/avatar/ec9a05787d29afe41e243e4b60bd0e2f69d757688e8f0bfe5e78bc185a3e317f?d=mp&s=160"},"body":"When progress.c:throughput_string() is called, the variable total\ninvariably has its twelve least significant bits set. Ie, it is\nalways the case that:\n\n total & 0xFFF == 0xFFF\n\nAs such, there is no point in displaying centi KiB.\n\nSigned-off-by: James Cloos \n---\n progress.c | 5 ++---\n 1 files changed, 2 insertions(+), 3 deletions(-)\n\ndiff --git a/progress.c b/progress.c\nindex 55a8687..e51b834 100644\n--- a/progress.c\n+++ b/progress.c\n@@ -125,9 +125,8 @@ static void throughput_string(struct throughput *tp, off_t total,\n \t\t\t (int)(total >> 20),\n \t\t\t ((int)(total & ((1 << 20) - 1)) * 100) >> 20);\n \t} else if (total > 1 << 10) {\n-\t\tl -= snprintf(tp->display, l, \", %u.%2.2u KiB\",\n-\t\t\t (int)(total >> 10),\n-\t\t\t ((int)(total & ((1 << 10) - 1)) * 100) >> 10);\n+\t\tl -= snprintf(tp->display, l, \", %u KiB\",\n+\t\t\t (int)(total >> 10));\n \t} else {\n \t\tl -= snprintf(tp->display, l, \", %u bytes\", (int)total);\n \t}\n-- \n1.6.3.rc1.1.g7e8e.dirty\n"},{"id":"111632","messageId":"cover.1240115957.git.cloos@jhcloos.com","threadId":"18943","inReplyTo":null,"subject":"[PATCH 0/1] Improve progress display in kB range.","fromName":"James Cloos","fromEmail":"cloos@jhcloos.com","sentAt":"2009-04-19T04:38:53Z","receivedAt":"2009-04-19T04:38:53Z","isPatch":true,"sender":{"key":"cloos@jhcloos.com","avatar":"https://gravatar.com/avatar/ec9a05787d29afe41e243e4b60bd0e2f69d757688e8f0bfe5e78bc185a3e317f?d=mp&s=160"},"body":"One of the few irritations when using git — note that you’ll need a\nrelatively slow link to notice — is that the progress always shows\nsomething .99 when under one Meg.\n\nThis patch eliminates the constant .99 from the progress display.\n\nJames Cloos (1):\n Improve progress display in kB range.\n\n progress.c | 5 ++---\n 1 files changed, 2 insertions(+), 3 deletions(-)\n\n-- \nJames Cloos OpenPGP: 1024D/ED7DAEA6\n"},{"id":"111835","messageId":"alpine.LFD.2.00.0904210054190.6741@xanadu.home","threadId":"18943","inReplyTo":"d03620ac4d99f3280df31708032a072a4a6cd96e.1240115957.git.cloos@jhcloos.com","subject":"Re: [PATCH 1/1] Improve progress display in kB range.","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2009-04-21T04:56:10Z","receivedAt":"2009-04-21T04:56:10Z","isPatch":true,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Sun, 19 Apr 2009, James Cloos wrote:\n\n> When progress.c:throughput_string() is called, the variable total\n> invariably has its twelve least significant bits set. Ie, it is\n> always the case that:\n> \n> total & 0xFFF == 0xFFF\n\nCould you please explain ow you come to that conclusion?\n\n\nNicolas\n"},{"id":"111886","messageId":"m3skk2szgv.fsf@lugabout.jhcloos.org","threadId":"18943","inReplyTo":"alpine.LFD.2.00.0904210054190.6741@xanadu.home","subject":"Re: [PATCH 1/1] Improve progress display in kB range.","fromName":"James Cloos","fromEmail":"cloos@jhcloos.com","sentAt":"2009-04-21T17:11:52Z","receivedAt":"2009-04-21T17:11:52Z","isPatch":true,"sender":{"key":"cloos@jhcloos.com","avatar":"https://gravatar.com/avatar/ec9a05787d29afe41e243e4b60bd0e2f69d757688e8f0bfe5e78bc185a3e317f?d=mp&s=160"},"body":">>>>> \"Nicolas\" == Nicolas Pitre writes:\n\nNicolas> On Sun, 19 Apr 2009, James Cloos wrote:\n>> When progress.c:throughput_string() is called, the variable total\n>> invariably has its twelve least significant bits set. Ie, it is\n>> always the case that:\n>> \n>> total & 0xFFF == 0xFFF\n\nNicolas> Could you please explain ow you come to that conclusion?\n\nEmpirical evidence.\n\nEven since the current progress was added, it has always shown nn.99 KiB\nin that range. I added an extra snprintf(3) to show total in hex and it\nalways ends in FFF.\n\nI presume the progress function is getting called just before total hits\na page boundry. In any case, the empirical evidence is clear. And only\neven seeing .99 is annoying. Hense the proposed patch.\n\n-JimC\n-- \nJames Cloos OpenPGP: 1024D/ED7DAEA6\n"},{"id":"111888","messageId":"alpine.LFD.2.00.0904211319570.6741@xanadu.home","threadId":"18943","inReplyTo":"m3skk2szgv.fsf@lugabout.jhcloos.org","subject":"Re: [PATCH 1/1] Improve progress display in kB range.","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2009-04-21T17:28:04Z","receivedAt":"2009-04-21T17:28:04Z","isPatch":true,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Tue, 21 Apr 2009, James Cloos wrote:\n\n> >>>>> \"Nicolas\" == Nicolas Pitre writes:\n> \n> Nicolas> On Sun, 19 Apr 2009, James Cloos wrote:\n> >> When progress.c:throughput_string() is called, the variable total\n> >> invariably has its twelve least significant bits set. Ie, it is\n> >> always the case that:\n> >> \n> >> total & 0xFFF == 0xFFF\n> \n> Nicolas> Could you please explain ow you come to that conclusion?\n> \n> Empirical evidence.\n> \n> Even since the current progress was added, it has always shown nn.99 KiB\n> in that range. I added an extra snprintf(3) to show total in hex and it\n> always ends in FFF.\n\nEmpirical evidence on my side shows the opposite. I just did a fetch in \nmy kernel repo and got:\n\n Receiving objects: 100% (1373/1373), 223.36 KiB, done.\n\n> I presume the progress function is getting called just before total hits\n> a page boundry. In any case, the empirical evidence is clear. And only\n> even seeing .99 is annoying. Hense the proposed patch.\n\nI must NACK your patches. Presumptions are not good enough \njustification for such a change, especially if results can't be \nreproduced. That doesn't mean the code is completely bug free of \ncourse, but finding the source of the bug affecting you would be a far \nbetter course of action than simply turning our back on it. Maybe you \ncan tell us more about your environment?\n\n\nNicolas\n"},{"id":"111903","messageId":"m3d4b5oj76.fsf@lugabout.jhcloos.org","threadId":"18943","inReplyTo":"alpine.LFD.2.00.0904211319570.6741@xanadu.home","subject":"Re: [PATCH 1/1] Improve progress display in kB range.","fromName":"James Cloos","fromEmail":"cloos@jhcloos.com","sentAt":"2009-04-21T20:16:53Z","receivedAt":"2009-04-21T20:16:53Z","isPatch":true,"sender":{"key":"cloos@jhcloos.com","avatar":"https://gravatar.com/avatar/ec9a05787d29afe41e243e4b60bd0e2f69d757688e8f0bfe5e78bc185a3e317f?d=mp&s=160"},"body":">>>>> \"Nicolas\" == Nicolas Pitre writes:\n\nNicolas> Empirical evidence on my side shows the opposite. I just did a fetch in \nNicolas> my kernel repo and got:\n\nNicolas> Receiving objects: 100% (1373/1373), 223.36 KiB, done.\n\nOK. That does show that my proposed patch is incomplete.\n\nThe contrary example is from the final output, if the received pack\nis less than a Meg. The annoyance is in the progress display.\n\nIn index-pack.c, fill() calls xread() and then display_throughput().\nSince xread() is designed to call read(2) and simple continue on any\nEINTR or EAGAIN, then — even though xread() explicitly does not\nguarantee that ‘len’ bytes are read even if the data are available —\nin practice xread() fills its buffer. (At least on 32-bit x86,\nusing Linus’ kernel.)\n\nTherefore, in practice — and as I have witnessed several thousand times\nwithout ever having seen a contrary example — display_throughput() is\ncalled *durring* a download only when total & 0xFFF == 0xFFF.\n\nPerhaps, then, display_throughput() should round differently, so that\nthe logical equivilent of:\n\n ( ( n << 10) & 0x3FF ) / 1024.0\n\nwould be rounded up. Then throughput_string() could elide the \".%2.2u\"\nwhenever ((int)(total & ((1 << 10) - 1)) * 100) >> 10) == 0.\n\nOr throughput_string() could simply elide the \".%2.2u\" whenever\ntotal & 0x3FF == 0x3FF.\n\nNicolas> I must NACK your patches. Presumptions are not good enough\nNicolas> justification for such a change, especially if results can't\nNicolas> be reproduced.\n\nUnderstood. I concentrated on the progress display and ignored the\nfinal display.\n\n-JimC\n-- \nJames Cloos OpenPGP: 1024D/ED7DAEA6\n"},{"id":"111949","messageId":"m34owgoj08.fsf@lugabout.jhcloos.org","threadId":"18943","inReplyTo":"m3d4b5oj76.fsf@lugabout.jhcloos.org","subject":"Re: [PATCH 1/1] Improve progress display in kB range.","fromName":"James Cloos","fromEmail":"cloos@jhcloos.com","sentAt":"2009-04-22T14:33:19Z","receivedAt":"2009-04-22T14:33:19Z","isPatch":true,"sender":{"key":"cloos@jhcloos.com","avatar":"https://gravatar.com/avatar/ec9a05787d29afe41e243e4b60bd0e2f69d757688e8f0bfe5e78bc185a3e317f?d=mp&s=160"},"body":"|> Therefore, in practice — and as I have witnessed several thousand times\n|> without ever having seen a contrary example — display_throughput() is\n|> called *durring* a download only when total & 0xFFF == 0xFFF.\n\nAnother possibility is an off-by-one error. The relevant part of fill()\nlooks like:\n\n,----< excerpt from index-pack.c:fill() >\n| do {\n| ssize_t ret = xread(input_fd, input_buffer + input_len,\n| sizeof(input_buffer) - input_len);\n| if (ret <= 0) {\n| if (!ret)\n| die(\"early EOF\");\n| die(\"read error on input: %s\", strerror(errno));\n| }\n| input_len += ret;\n| if (from_stdin)\n| display_throughput(progress, consumed_bytes + input_len);\n| } while (input_len < min);\n| return input_buffer;\n| }\n`----\n\nif *(input_buffer + ret) is the last read octet rather than the next\nempty octet, that would also explain what I see.\n\nPerhaps that call to display_throughput() should have an extra +1?\n\n-JimC\n-- \nJames Cloos OpenPGP: 1024D/ED7DAEA6\n"},{"id":"111989","messageId":"7vljps324a.fsf@gitster.siamese.dyndns.org","threadId":"18943","inReplyTo":"m34owgoj08.fsf@lugabout.jhcloos.org","subject":"Re: [PATCH 1/1] Improve progress display in kB range.","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-04-22T19:44:05Z","receivedAt":"2009-04-22T19:44:05Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"James Cloos writes:\n\n> |> Therefore, in practice — and as I have witnessed several thousand times\n> |> without ever having seen a contrary example — display_throughput() is\n> |> called *durring* a download only when total & 0xFFF == 0xFFF.\n>\n> Another possibility is an off-by-one error. The relevant part of fill()\n> looks like:\n>\n> ,----< excerpt from index-pack.c:fill() >\n> | do {\n> | ssize_t ret = xread(input_fd, input_buffer + input_len,\n> | sizeof(input_buffer) - input_len);\n> | if (ret <= 0) {\n> | if (!ret)\n> | die(\"early EOF\");\n> | die(\"read error on input: %s\", strerror(errno));\n> | }\n> | input_len += ret;\n> | if (from_stdin)\n> | display_throughput(progress, consumed_bytes + input_len);\n> | } while (input_len < min);\n> | return input_buffer;\n> | }\n> `----\n>\n> if *(input_buffer + ret) is the last read octet rather than the next\n> empty octet, that would also explain what I see.\n\nAfter checking \"ret\" from xread(), input_len is incremented by that\namount, and the next iteration gives \"input_buffer + input_len\" to\nxread(). If input_buffer[ret] _were_ the last octet read, your loop would\nbe discarding that octet when you call more than one xread() to fill the\nbuffer.\n"},{"id":"112024","messageId":"m3ab68mi3q.fsf@lugabout.jhcloos.org","threadId":"18943","inReplyTo":"7vljps324a.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH 1/1] Improve progress display in kB range.","fromName":"James Cloos","fromEmail":"cloos@jhcloos.com","sentAt":"2009-04-22T22:35:45Z","receivedAt":"2009-04-22T22:35:45Z","isPatch":true,"sender":{"key":"cloos@jhcloos.com","avatar":"https://gravatar.com/avatar/ec9a05787d29afe41e243e4b60bd0e2f69d757688e8f0bfe5e78bc185a3e317f?d=mp&s=160"},"body":">>>>> \"Junio\" == Junio C Hamano writes:\n\nJunio> If input_buffer[ret] _were_ the last octet read, [the] loop would\nJunio> be discarding that octet when [it] call[s] more than one xread()\nJunio> to fill the buffer.\n\nThat did sem more likely, but I thought I'd throw out the possibility.\n\nI just tried instrumenting fill().\n\nIn the first call to fill() during a fetch, xread() returns 4096. In\nthe second call to fill(), xread() returns 4095. In all subsequent\ncalls to fill(), xread() returns 4096 again.\n\nSo, after the second call to xread(), consumed_bytes & 0xFFF == 0xFFF.\n\nIt always follows the pattern:\n\nxread() read 0x1000 from fd 0 at 0x80a0900\nret = 0x1000\nconsumed_bytes = 0\ninput_len = 0x1000\n\nxread() read 0xFFF from fd 0 at 0x80a0900\nret = 0xFFF\nconsumed_bytes = 0x1000\ninput_len = 0xFFF\n\nxread() read 0x1000 from fd 0 at 0x80a0900\nret = 0x1000\nconsumed_bytes = 0x1FFF\ninput_len = 0x1000\n\nwith all subsequent calls reading 0x1000 and adding 0x1000 to\nconsumed_bytes, until the final chuck of tha pack is read.\n\nAlso, all calls to xread() where the status lines are being sent from\nthe remote server also return 0x1000 octets. Only the second chunck of\na pack ever returns 0xFFF.\n\nI've tested against a number of remote servers and the pattern holds for\na wide range of remote server versions.\n\nThe pattern also holds for clones over ssh.\n\nDoes anyone have an idea of why the second call to read(2), when\nreceiving a pack from a remote, always leaves the last octet of the\nbuffer free, whereas all other read(2)s fill it?\n\n-JimC\n-- \nJames Cloos OpenPGP: 1024D/ED7DAEA6\n"},{"id":"112050","messageId":"49F0094A.6020609@viscovery.net","threadId":"18943","inReplyTo":"m3ab68mi3q.fsf@lugabout.jhcloos.org","subject":"Re: [PATCH 1/1] Improve progress display in kB range.","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2009-04-23T06:23:06Z","receivedAt":"2009-04-23T06:23:06Z","isPatch":true,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"James Cloos schrieb:\n>>>>>> \"Junio\" == Junio C Hamano writes:\n> \n> Junio> If input_buffer[ret] _were_ the last octet read, [the] loop would\n> Junio> be discarding that octet when [it] call[s] more than one xread()\n> Junio> to fill the buffer.\n> \n> That did sem more likely, but I thought I'd throw out the possibility.\n> \n> I just tried instrumenting fill().\n> \n> In the first call to fill() during a fetch, xread() returns 4096. In\n> the second call to fill(), xread() returns 4095. In all subsequent\n> calls to fill(), xread() returns 4096 again.\n> \n> So, after the second call to xread(), consumed_bytes & 0xFFF == 0xFFF.\n> \n> It always follows the pattern:\n> \n> xread() read 0x1000 from fd 0 at 0x80a0900\n> ret = 0x1000\n> consumed_bytes = 0\n> input_len = 0x1000\n> \n> xread() read 0xFFF from fd 0 at 0x80a0900\n> ret = 0xFFF\n> consumed_bytes = 0x1000\n> input_len = 0xFFF\n> \n> xread() read 0x1000 from fd 0 at 0x80a0900\n> ret = 0x1000\n> consumed_bytes = 0x1FFF\n> input_len = 0x1000\n> \n> with all subsequent calls reading 0x1000 and adding 0x1000 to\n> consumed_bytes, until the final chuck of tha pack is read.\n> \n> Also, all calls to xread() where the status lines are being sent from\n> the remote server also return 0x1000 octets. Only the second chunck of\n> a pack ever returns 0xFFF.\n> \n> I've tested against a number of remote servers and the pattern holds for\n> a wide range of remote server versions.\n> \n> The pattern also holds for clones over ssh.\n> \n> Does anyone have an idea of why the second call to read(2), when\n> receiving a pack from a remote, always leaves the last octet of the\n> buffer free, whereas all other read(2)s fill it?\n\nYou could instrument upload-pack.c. There is an xread() around l.237; does\nit aways return 4096? And send_client_data() at around l.254; when does it\nsend 4096 and when 4095 bytes? Read the comment in this if-branch.\n\nupload-pack is run on the server-side; therefore, you can test this only\non local repositories (unless you can replace upload-pack on the server, too).\n\n-- Hannes\n"},{"id":"112231","messageId":"m3zle5hkpa.fsf@lugabout.jhcloos.org","threadId":"18943","inReplyTo":"m3ab68mi3q.fsf@lugabout.jhcloos.org","subject":"Re: [PATCH 1/1] Improve progress display in kB range.","fromName":"James Cloos","fromEmail":"cloos@jhcloos.com","sentAt":"2009-04-24T20:15:21Z","receivedAt":"2009-04-24T20:15:21Z","isPatch":true,"sender":{"key":"cloos@jhcloos.com","avatar":"https://gravatar.com/avatar/ec9a05787d29afe41e243e4b60bd0e2f69d757688e8f0bfe5e78bc185a3e317f?d=mp&s=160"},"body":"It turns out that the off by one is intentional.\n\n>From upload-pack.c:\n\n/* Data ready; we keep the last byte to ourselves\n * in case we detect broken rev-list, so that we\n * can leave the stream corrupted. This is\n * unfortunate -- unpack-objects would happily\n * accept a valid packdata with trailing garbage,\n * so appending garbage after we pass all the\n * pack data is not good enough to signal\n * breakage to downstream.\n */\n\nUpload-pack uses a buffer of 8193 octets, which is why it is always\nthe second xread() that returns 0xFFF. It first sends 8191 octets,\nthen n chunks of 8192 and then the final chunk.\n\nIt seems to only way to fix the progress annoyance -- and it is most\nannoying -- would be to round correctly in progress.c.\n\n(The .99 comes from 1023/1024, which is .999 and therefor ought to\nround up to 1.00, not down to 0.99.)\n\nWill a patch which does round-to-nearest (instead of the current\nround-to-zero) be accepted?\n\n-JimC\n-- \nJames Cloos OpenPGP: 1024D/ED7DAEA6\n"},{"id":"112242","messageId":"alpine.LFD.2.00.0904241722220.6741@xanadu.home","threadId":"18943","inReplyTo":"m3zle5hkpa.fsf@lugabout.jhcloos.org","subject":"Re: [PATCH 1/1] Improve progress display in kB range.","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2009-04-24T21:46:15Z","receivedAt":"2009-04-24T21:46:15Z","isPatch":true,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Fri, 24 Apr 2009, James Cloos wrote:\n\n> It turns out that the off by one is intentional.\n> \n> >From upload-pack.c:\n> \n> /* Data ready; we keep the last byte to ourselves\n> * in case we detect broken rev-list, so that we\n> * can leave the stream corrupted. This is\n> * unfortunate -- unpack-objects would happily\n> * accept a valid packdata with trailing garbage,\n> * so appending garbage after we pass all the\n> * pack data is not good enough to signal\n> * breakage to downstream.\n> */\n> \n> Upload-pack uses a buffer of 8193 octets, which is why it is always\n> the second xread() that returns 0xFFF. It first sends 8191 octets,\n> then n chunks of 8192 and then the final chunk.\n> \n> It seems to only way to fix the progress annoyance -- and it is most\n> annoying -- would be to round correctly in progress.c.\n> \n> (The .99 comes from 1023/1024, which is .999 and therefor ought to\n> round up to 1.00, not down to 0.99.)\n> \n> Will a patch which does round-to-nearest (instead of the current\n> round-to-zero) be accepted?\n\nSure. What about this (untested):\n\ndiff --git a/progress.c b/progress.c\nindex 55a8687..621c34e 100644\n--- a/progress.c\n+++ b/progress.c\n@@ -121,13 +121,13 @@ static void throughput_string(struct throughput *tp, off_t total,\n \t\t\t (int)(total >> 30),\n \t\t\t (int)(total & ((1 << 30) - 1)) / 10737419);\n \t} else if (total > 1 << 20) {\n+\t\tint x = total + 5243; /* for rounding */\n \t\tl -= snprintf(tp->display, l, \", %u.%2.2u MiB\",\n-\t\t\t (int)(total >> 20),\n-\t\t\t ((int)(total & ((1 << 20) - 1)) * 100) >> 20);\n+\t\t\t x >> 20, ((x & ((1 << 20) - 1)) * 100) >> 20);\n \t} else if (total > 1 << 10) {\n+\t\tint x = total + 5; /* for rounding */\n \t\tl -= snprintf(tp->display, l, \", %u.%2.2u KiB\",\n-\t\t\t (int)(total >> 10),\n-\t\t\t ((int)(total & ((1 << 10) - 1)) * 100) >> 10);\n+\t\t\t x >> 10, ((x & ((1 << 10) - 1)) * 100) >> 10);\n \t} else {\n \t\tl -= snprintf(tp->display, l, \", %u bytes\", (int)total);\n \t}\n\nNicolas\n"},{"id":"112248","messageId":"m3tz4dhewa.fsf@lugabout.jhcloos.org","threadId":"18943","inReplyTo":"alpine.LFD.2.00.0904241722220.6741@xanadu.home","subject":"Re: [PATCH 1/1] Improve progress display in kB range.","fromName":"James Cloos","fromEmail":"cloos@jhcloos.com","sentAt":"2009-04-24T22:20:45Z","receivedAt":"2009-04-24T22:20:45Z","isPatch":true,"sender":{"key":"cloos@jhcloos.com","avatar":"https://gravatar.com/avatar/ec9a05787d29afe41e243e4b60bd0e2f69d757688e8f0bfe5e78bc185a3e317f?d=mp&s=160"},"body":">>>>> \"Nicolas\" == Nicolas Pitre writes:\n\n>> Will a patch which does round-to-nearest (instead of the current\n>> round-to-zero) be accepted?\n\nNicolas> Sure. What about this (untested):\n\nNicolas> +\t\tint x = total + 5243; /* for rounding */\nNicolas> +\t\tint x = total + 5; /* for rounding */\n\nThat looks correct.\n\n-JimC\n-- \nJames Cloos OpenPGP: 1024D/ED7DAEA6\n"}]}