On Wed, Jul 30, 2014 at 3:08 PM, Eric Sunshine <[email protected]> wrote:
>> +static void share_index(struct index_state *istate, struct index_shm *is)
>> +{
>> + void *new_mmap;
>> + if (istate->mmap_size <= 20 ||
>> + hashcmp(istate->sha1,
>> + (unsigned char *)istate->mmap + istate->mmap_size - 20)
>> ||
>> + !hashcmp(istate->sha1, is->sha1) ||
>> + git_shm_map(O_CREAT | O_EXCL | O_RDWR, 0700, istate->mmap_size,
>> + &new_mmap, PROT_READ | PROT_WRITE, MAP_SHARED,
>> + "git-index-%s", sha1_to_hex(istate->sha1)) < 0)
>
> Do any of these failure conditions deserve a diagnostic message to let
> the user know that there was a problem?
Hmm.. diagnostic messages are a problem already. This most likely runs
as a daemon, nowhere to print to. But if running on foreground, some
messages would help.
>> +static int try_shm(struct index_state *istate)
>> +{
>> + void *new_mmap = NULL;
>> + size_t old_size = istate->mmap_size;
>
> Is old_size needed? Can you not simply reference istate->mmap_size
> directly each place old_size is mentioned?
>
>> + ssize_t new_length;
>
> Nit: 'size' vs. 'length' inconsistency in variable name choices.
Leftovers after many iterations. Will fix.
>> +#define SHM_PATH_LEN 72 /* we don't create very long paths..
>> */
>> +
>> +ssize_t git_shm_map(int oflag, int perm, ssize_t length, void **mmap,
>> + int prot, int flags, const char *fmt, ...)
>> +{
>> + va_list ap;
>> + char path[SHM_PATH_LEN];
>
> Is there a reason to avoid strbuf here?
Laziness (which is ironic as I'm working on patches to clean up fixed
size buffers)
--
Duy
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
