From: Corey Bryant <coreyb@linux.vnet.ibm.com>
To: Eric Blake <eblake@redhat.com>
Cc: kwolf@redhat.com, aliguori@us.ibm.com, qemu-devel@nongnu.org,
stefanha@linux.vnet.ibm.com
Subject: Re: [Qemu-devel] [PATCH 2/3] block: Add support to "open" /dev/fd/X filenames
Date: Mon, 04 Jun 2012 12:40:21 -0400 [thread overview]
Message-ID: <4FCCE4F5.50000@linux.vnet.ibm.com> (raw)
In-Reply-To: <4FCCE411.3020509@redhat.com>
On 06/04/2012 12:36 PM, Eric Blake wrote:
> On 06/04/2012 10:28 AM, Corey Bryant wrote:
>
>>> But at least strtol lets you detect errors:
>>>
>>> char *tmp;
>>> errno = 0;
>>> fd = strtol(p,&tmp, 10);
>>> if (errno || tmp == p) {
>>> /* raise your error here */
>>> }
>>
>> I don't think this is legitimate. errno can be set under the covers of
>> library calls even if the strtol() call is successful.
>
> Wrong. POSIX _specifically_ requires that strtol() leave errno
> unchanged unless strtol() is reporting a failure, no matter what other
> library calls (if any) are made under the covers by strtol().
>
> In other words, pre-setting errno to 0, then calling strtol(), then
> checking errno, _is_ the documented way to check for strtol() failures,
> and a correct usage of strtol() MUST use this method. See also commit
> 6b0e33be88bbccc3bcb987026089aa09f9622de9. atoi() does not have this
> same guarantee, which makes atoi() worthless at detecting errors in
> relation to strtol().
>
Great! I see it now (excerpt below is from the opengroup
specification). This is definitely an exception from normal behavior of
C APIs.
"The strtol() function will not change the setting of errno if successful."
>>
>> I was thinking if strtol returns 0 and errno is 0, perhaps we could
>> assume success, but I don't think this is guaranteed either.
>
> Actually, it _is_ guaranteed - if you pre-set errno to 0, then call
> strtol(), then errno is still 0, then the result did not encounter an
> error, so a result of 0 at that point means that you indeed parsed a 0.
>
>>
>> Maybe a combination of isdigit() then strtol() will give a better idea
>> of success.
>
> Not necessary.
>
--
Regards,
Corey
next prev parent reply other threads:[~2012-06-04 16:40 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-04 13:10 [Qemu-devel] [PATCH 0/3] file descriptor passing using getfd over QMP Corey Bryant
2012-06-04 13:10 ` [Qemu-devel] [PATCH 1/3] qmp/hmp: Add QMP getfd command that returns fd Corey Bryant
2012-06-04 14:45 ` Kevin Wolf
2012-06-04 15:57 ` Corey Bryant
2012-06-05 18:30 ` Luiz Capitulino
2012-06-06 14:04 ` Corey Bryant
2012-06-06 17:50 ` Luiz Capitulino
2012-06-06 19:42 ` Corey Bryant
2012-06-08 10:46 ` Daniel P. Berrange
2012-06-08 13:17 ` Corey Bryant
2012-06-04 13:10 ` [Qemu-devel] [PATCH 2/3] block: Add support to "open" /dev/fd/X filenames Corey Bryant
2012-06-04 14:32 ` Eric Blake
2012-06-04 15:51 ` Corey Bryant
2012-06-04 16:03 ` Eric Blake
2012-06-04 16:28 ` Corey Bryant
2012-06-04 16:36 ` Eric Blake
2012-06-04 16:40 ` Corey Bryant [this message]
2012-06-04 14:54 ` Kevin Wolf
2012-06-04 16:07 ` Corey Bryant
2012-06-04 13:10 ` [Qemu-devel] [PATCH 3/3] Sample server that opens image files for QEMU Corey Bryant
2012-06-04 15:01 ` Kevin Wolf
2012-06-04 16:15 ` Corey Bryant
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=4FCCE4F5.50000@linux.vnet.ibm.com \
--to=coreyb@linux.vnet.ibm.com \
--cc=aliguori@us.ibm.com \
--cc=eblake@redhat.com \
--cc=kwolf@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@linux.vnet.ibm.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.