git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Michael Haggerty <mhagger@alum.mit.edu>
To: Johannes Sixt <j6t@kdbg.org>, Junio C Hamano <gitster@pobox.com>
Cc: Git Mailing List <git@vger.kernel.org>
Subject: Re: [PATCH mh/lockfile-retry] lockfile: replace random() by rand()
Date: Thu, 04 Jun 2015 13:42:38 +0200	[thread overview]
Message-ID: <557039AE.3020107@alum.mit.edu> (raw)
In-Reply-To: <55700F10.8030806@kdbg.org>

On 06/04/2015 10:40 AM, Johannes Sixt wrote:
> Am 30.05.2015 um 19:12 schrieb Junio C Hamano:
>> Johannes Sixt <j6t@kdbg.org> writes:
>>
>>> There you have it: Look the other way for a while, and people start
>>> using exotic stuff... ;)
>>
>> Is it exotic to have random/srandom?  Both are in POSIX and 4BSD;
>> admittedly rand/srand are written down in C89 and later, so they
>> might be more portable, but I recall the prevailing wisdom is to
>> favor random over rand for quality of randomness and portability, so
>> I am wondering if it may be a better approach to keep the code as-is
>> and do a compat/random.c based on either rand/srand (or use posix
>> sample implementation [*1*]).
> 
> For our purposes here, the linear congruence of rand() is certainly
> sufficient. At this time, compatibility functions for random/srandom
> would just mean a lot of work for little gain.

We *certainly* don't require high-quality random numbers for this
application. Regarding portability, there is one definite point in favor
of rand() (it's available on Windows) vs. Junio's recollection that
random() might have portability advantages, presumably on other platforms.

Maybe the easiest thing would be to switch to using rand() and see if
the OS/2 and VMS users complain ;-)

Michael

-- 
Michael Haggerty
mhagger@alum.mit.edu

  reply	other threads:[~2015-06-04 11:42 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-30  6:23 [PATCH mh/lockfile-retry] lockfile: replace random() by rand() Johannes Sixt
2015-05-30 17:12 ` Junio C Hamano
2015-06-04  8:40   ` Johannes Sixt
2015-06-04 11:42     ` Michael Haggerty [this message]
2015-06-04 15:57       ` Junio C Hamano
2015-06-05 19:45     ` [PATCH 0/4] Fix file locking with retry and timeout on Windows Johannes Sixt
2015-06-05 19:45       ` [PATCH 1/4] lockfile: replace random() by rand() Johannes Sixt
2015-06-05 19:45       ` [PATCH 2/4] help.c: wrap wait-only poll() invocation in sleep_millisec() Johannes Sixt
2015-06-05 19:45       ` [PATCH 3/4] lockfile: convert retry timeout computations to millisecond Johannes Sixt
2015-06-05 19:45       ` [PATCH 4/4] lockfile: wait using sleep_millisec() instead of select() Johannes Sixt
2015-06-05 19:57       ` [PATCH 0/4] Fix file locking with retry and timeout on Windows Junio C Hamano
2015-06-05 20:14       ` Michael Haggerty

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=557039AE.3020107@alum.mit.edu \
    --to=mhagger@alum.mit.edu \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=j6t@kdbg.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).