Hi,
> > const char *p = _tcsrchr(find->cFileName, TEXT('.'));
> > return p && p != find->cFileName && !_tcsicmp(p+1, ext);
> >
> > No _tcslen() and no offending size variables.
> > And that convoluted original is then gone.
>
> The resulting code would look a lot nicer indeed. Stay tuned for v2 of
> this patch.
>
>
Yes that was the point -- not that we cant do arithmetic, but we need not
and in the end the code could be cleaner...
>
> > - WritePipeAsync(pipe, buf, wcslen(buf) * 2, count, events);
> > + WritePipeAsync(pipe, buf, (DWORD)(wcslen(buf) * 2), count, events);
> >
> > Isn't this identical to the original automatic conversion from size_t to
> > DWORD?
> > An overly paranoid assert(_countof(buf) < MAXDWORD/2) may catch an
> > extremely
> > unlikely future coding error, but in what way a cast safer?
>
> I didn't say it is safer. The buf is WCHAR[33] on the stack. There is a
> safety zero termination a line before the WritePipeAsync(). Therefore,
> wcslen(buf) will always return between 0 and 32. Times two (if I was coding
> this, I'd use *sizeof(WCHAR) instead of 2, to make a clear statement, what
> is multiplication by 2 about), making it between 0 and 64. Unfortunately,
> result is size_t where Win32 API expects a DWORD.
>
> This will always produce a false compiler warning. I muted it by an
> explicit cast, so we can focus on more important warnings.
Agreed, reducing compiler warnings is a useful side effect and we know the
type coercion here is safe.
cheers,
Selva
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
