Fix up clang build, and presubmit warnings about strcpy.

Fix up clang build, and presubmit warnings about strcpy.
Also fixes typo in comment.

BUG=none
TEST=build

Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=66364

[dmac, 2010-11-16 23:16:54]

This should clean up the issue (and a warning about strcpy that presubmit gave
me)

[Nico, 2010-11-16 23:23:31]

everything except the snprintf change LGTM. Maybe you can submit this without
the snprintf change to get the bot green.

http://codereview.chromium.org/5100001/diff/1/chrome/common/multi_process_loc...
File chrome/common/multi_process_lock_linux.cc (right):

http://codereview.chromium.org/5100001/diff/1/chrome/common/multi_process_loc...
chrome/common/multi_process_lock_linux.cc:47: "%s", name.c_str()) < 0) {
from `man snprintf`:


     These functions return the number of characters printed (not including the
trailing `\0' used to end output to strings) or a negative
     value if an output error occurs, except for snprintf() and vsnprintf(),
which return the number of characters that would have been printed
     if the n were unlimited (again, not including the final `\0').


I haven't seen the presubmit warning, maybe it gives bad advice?

[dmac, 2010-11-16 23:30:07]

On 2010/11/16 23:23:31, Nico wrote:
> everything except the snprintf change LGTM. Maybe you can submit this without
> the snprintf change to get the bot green.
> 
>
http://codereview.chromium.org/5100001/diff/1/chrome/common/multi_process_loc...
> File chrome/common/multi_process_lock_linux.cc (right):
> 
>
http://codereview.chromium.org/5100001/diff/1/chrome/common/multi_process_loc...
> chrome/common/multi_process_lock_linux.cc:47: "%s", name.c_str()) < 0) {
> from `man snprintf`:
> 
> 
>      These functions return the number of characters printed (not including
the
> trailing `\0' used to end output to strings) or a negative
>      value if an output error occurs, except for snprintf() and vsnprintf(),
> which return the number of characters that would have been printed
>      if the n were unlimited (again, not including the final `\0').
> 
> 
> I haven't seen the presubmit warning, maybe it gives bad advice?

You are looking at the OS X man page, please check out the linux man page which
is much clearer:

http://linux.die.net/man/3/snprintf

"Upon successful return, these functions return the number of characters printed
(not including the trailing '\0' used to end output to strings). The functions
snprintf() and vsnprintf() do not write more than size bytes (including the
trailing '\0'). If the output was truncated due to this limit then the return
value is the number of characters (not including the trailing '\0') which would
have been written to the final string if enough space had been available. Thus,
a return value of size or more means that the output was truncated. (See also
below under NOTES.) If an output error is encountered, a negative value is
returned."

[Nico, 2010-11-16 23:39:14]

On Tue, Nov 16, 2010 at 3:30 PM,  <dmaclach@chromium.org> wrote:
> On 2010/11/16 23:23:31, Nico wrote:
>>
>> everything except the snprintf change LGTM. Maybe you can submit this
>> without
>> the snprintf change to get the bot green.
>
>
>
http://codereview.chromium.org/5100001/diff/1/chrome/common/multi_process_loc...
>>
>> File chrome/common/multi_process_lock_linux.cc (right):
>
>
>
http://codereview.chromium.org/5100001/diff/1/chrome/common/multi_process_loc...
>>
>> chrome/common/multi_process_lock_linux.cc:47: "%s", name.c_str()) < 0) {
>> from `man snprintf`:
>
>
>>      These functions return the number of characters printed (not
>> including
>
> the
>>
>> trailing `\0' used to end output to strings) or a negative
>>      value if an output error occurs, except for snprintf() and
>> vsnprintf(),
>> which return the number of characters that would have been printed
>>      if the n were unlimited (again, not including the final `\0').
>
>
>> I haven't seen the presubmit warning, maybe it gives bad advice?
>
> You are looking at the OS X man page, please check out the linux man page
> which
> is much clearer:
>
> http://linux.die.net/man/3/snprintf
>
> "Upon successful return, these functions return the number of characters
> printed
> (not including the trailing '\0' used to end output to strings). The
> functions
> snprintf() and vsnprintf() do not write more than size bytes (including the
> trailing '\0'). If the output was truncated due to this limit then the
> return
> value is the number of characters (not including the trailing '\0') which
> would
> have been written to the final string if enough space had been available.
> Thus,
> a return value of size or more means that the output was truncated. (See
> also
> below under NOTES.) If an output error is encountered, a negative value is
> returned."

This seems to say the same:

> Thus, a return value of size or more means that the output was truncated.

Don't you have to check if (snprintf(..) >
MULTI_PROCESS_LOCK_NAME_MAX_LEN) instead of < 0 to detect that your
buffer was too small?

[dmaclach1, 2010-11-16 23:51:50]

Ah, I thought you were confused about the function returning < 0. I
check the length on line 31, and then verify at compile time the size
of the buffer that I am compiling into on line 42-43.

New patch up though that checks it again after snprintf has been called.

On Tue, Nov 16, 2010 at 3:39 PM, Nico Weber <thakis@chromium.org> wrote:
> On Tue, Nov 16, 2010 at 3:30 PM,  <dmaclach@chromium.org> wrote:
>> On 2010/11/16 23:23:31, Nico wrote:
>>>
>>> everything except the snprintf change LGTM. Maybe you can submit this
>>> without
>>> the snprintf change to get the bot green.
>>
>>
>>
http://codereview.chromium.org/5100001/diff/1/chrome/common/multi_process_loc...
>>>
>>> File chrome/common/multi_process_lock_linux.cc (right):
>>
>>
>>
http://codereview.chromium.org/5100001/diff/1/chrome/common/multi_process_loc...
>>>
>>> chrome/common/multi_process_lock_linux.cc:47: "%s", name.c_str()) < 0) {
>>> from `man snprintf`:
>>
>>
>>>      These functions return the number of characters printed (not
>>> including
>>
>> the
>>>
>>> trailing `\0' used to end output to strings) or a negative
>>>      value if an output error occurs, except for snprintf() and
>>> vsnprintf(),
>>> which return the number of characters that would have been printed
>>>      if the n were unlimited (again, not including the final `\0').
>>
>>
>>> I haven't seen the presubmit warning, maybe it gives bad advice?
>>
>> You are looking at the OS X man page, please check out the linux man page
>> which
>> is much clearer:
>>
>> http://linux.die.net/man/3/snprintf
>>
>> "Upon successful return, these functions return the number of characters
>> printed
>> (not including the trailing '\0' used to end output to strings). The
>> functions
>> snprintf() and vsnprintf() do not write more than size bytes (including the
>> trailing '\0'). If the output was truncated due to this limit then the
>> return
>> value is the number of characters (not including the trailing '\0') which
>> would
>> have been written to the final string if enough space had been available.
>> Thus,
>> a return value of size or more means that the output was truncated. (See
>> also
>> below under NOTES.) If an output error is encountered, a negative value is
>> returned."
>
> This seems to say the same:
>
>> Thus, a return value of size or more means that the output was truncated.
>
> Don't you have to check if (snprintf(..) >
> MULTI_PROCESS_LOCK_NAME_MAX_LEN) instead of < 0 to detect that your
> buffer was too small?
>

[Nico, 2010-11-16 23:56:44]

LG