Bug#487254: manpages-dev: *scanf may set errno to ERANGE
In the GNU and UC versions of the libc (at least), the scanf/fscanf/sscanf... functions seem to be calling strtoxxx internally for number conversions. In doing so, errno may be set to ERANGE when the input doesn't fit in the number size requested Okay -- I verified this. One of the problems here of course is that the scanf.3 page currently doesn't document *any* errors... Okay -- I added an ERRORS section, which documents ERANGE, among others. I also noted that this error is not in POSIX. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#487254: manpages-dev: *scanf may set errno to ERANGE
Hi Stephane, On Mon, Jun 23, 2008 at 10:51 AM, Stephane Chazelas [EMAIL PROTECTED] wrote: On Mon, Jun 23, 2008 at 10:34:14AM +0200, Michael Kerrisk wrote: [...] Okay -- I verified this. One of the problems here of course is that the scanf.3 page currently doesn't document *any* errors... and possibly to EINVAL for a figures not in the requested base. Can you provide an example where this error is produced? I could not see it. Hi Michael, I didn't try that, that's why I said possibly. But the strtol man page says that it may return EINVAL so it could be the case for sscanf as well. Okay. Looks like it's not the case. [...] Also, the %as GNU extension seems not to be documented (it may return ENOMEM) in the man page. It is in the glibc documentation. So, this is a completely unrelated issue (other than the fact that it involves scanf()). Makes it difficult to close the bug and until the two unrelated halves are both fixed. Please don't do that ;-). [...] You're right, sorry about that. Actually I found that other one while writing the bug report. I was looking for other errnos that sscanf may return (here ENOMEM). Yes, I included ENOMEM in the new ERRORS list. But I'm not sure if that's a bug or not as I don't know whether manpages-dev is meant to document the GNU or other version of the libc functions. I don't know that manpages-dev has a policy on that. Upstream man-pages policy is: yes, document glibc specifics (but give context re portability). AFAICT, the %as is a GNU extension that is not supported anywhere else, but is required by the LSB. I don't know what's your policy on that. As above. I can create a separate bug report if you want. No, I'll fix the other part this time. Later today with a bit of luck. But please remember, next time(s). BTW, Michael, I take it you're the maintainer of the manpages-dev debian package, Sometimes one could get that impression ;-). But, no, I'm not. I'm merely the upstream maintainer. (Debain derives the downstream manpages and manpages-dev packages from my upstream man-pages. The Debian maintainer is Joey.) Debian makes it easy to track their downstream man-pages bug reports, so I do that. It's useful for me to get bug reports that way, because Debian users are quite active in reporting documentation bugs. It's useful for Debian, because I shorten the average response time on documentation bug reports considerably (and mostly save Joey the job of pushing fixes upstream). but are you as well the maintainer of the upstreams package, or glibc documentation? Just upstream man-pages, which does document glibc in Section 3. I have nothing to do with info docs though -- that's the glibc folk. What's the debian view on the LSB. I don't know. I discovered it recently. It seems more like an industry initiative to me at first sight rather than a free software initiative and it seems to be somewhat RedHat centered so am not sure what kind of credibility it can be given. I don't think you could call it RH centric. Thre are many parties involved. Perhaps RH is more active than many. Mats might have something to say about this. Cheers, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ man-pages online: http://www.kernel.org/doc/man-pages/online_pages.html Found a bug? http://www.kernel.org/doc/man-pages/reporting_bugs.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#487254: manpages-dev: *scanf may set errno to ERANGE
Hi Stephane, There are at least two logically separate bug reports here. In such cases, *please* file separate reports. See below for why. On Fri, Jun 20, 2008 at 5:35 PM, Stephane Chazelas [EMAIL PROTECTED] wrote: Package: manpages-dev Version: 2.80-1 Severity: normal In the GNU and UC versions of the libc (at least), the scanf/fscanf/sscanf... functions seem to be calling strtoxxx internally for number conversions. In doing so, errno may be set to ERANGE when the input doesn't fit in the number size requested Okay -- I verified this. One of the problems here of course is that the scanf.3 page currently doesn't document *any* errors... and possibly to EINVAL for a figures not in the requested base. Can you provide an example where this error is produced? I could not see it. I think this should be mentionned. It should probably be mentionned that one shouldn't rely on that to check whether an out-of-range number was provided given that it is not clearly specified by POSIX. Yes, thanks for pointing that out. Also, the %as GNU extension seems not to be documented (it may return ENOMEM) in the man page. It is in the glibc documentation. So, this is a completely unrelated issue (other than the fact that it involves scanf()). Makes it difficult to close the bug and until the two unrelated halves are both fixed. Please don't do that ;-). Cheers, Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#487254: manpages-dev: *scanf may set errno to ERANGE
On Mon, Jun 23, 2008 at 10:34:14AM +0200, Michael Kerrisk wrote: [...] Okay -- I verified this. One of the problems here of course is that the scanf.3 page currently doesn't document *any* errors... and possibly to EINVAL for a figures not in the requested base. Can you provide an example where this error is produced? I could not see it. Hi Michael, I didn't try that, that's why I said possibly. But the strtol man page says that it may return EINVAL so it could be the case for sscanf as well. [...] Also, the %as GNU extension seems not to be documented (it may return ENOMEM) in the man page. It is in the glibc documentation. So, this is a completely unrelated issue (other than the fact that it involves scanf()). Makes it difficult to close the bug and until the two unrelated halves are both fixed. Please don't do that ;-). [...] You're right, sorry about that. Actually I found that other one while writing the bug report. I was looking for other errnos that sscanf may return (here ENOMEM). But I'm not sure if that's a bug or not as I don't know whether manpages-dev is meant to document the GNU or other version of the libc functions. AFAICT, the %as is a GNU extension that is not supported anywhere else, but is required by the LSB. I don't know what's your policy on that. I can create a separate bug report if you want. BTW, Michael, I take it you're the maintainer of the manpages-dev debian package, but are you as well the maintainer of the upstreams package, or glibc documentation? What's the debian view on the LSB. I discovered it recently. It seems more like an industry initiative to me at first sight rather than a free software initiative and it seems to be somewhat RedHat centered so am not sure what kind of credibility it can be given. Cheers, Stéphane -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#487254: manpages-dev: *scanf may set errno to ERANGE
On Mon, Jun 23, 2008 at 11:08:45AM +0200, Michael Kerrisk wrote: [...] I don't know that manpages-dev has a policy on that. Upstream man-pages policy is: yes, document glibc specifics (but give context re portability). [...] Thanks a lot Michael for all the details. BTW, I just came accross: http://www.linuxmanpages.com/man3/sscanf.3.php Which documents the a flag (and the a conversion in the wrong section). I'm surprised because that page claims not to have been modified since 1995 and as far as I can remember the glibc was not in common use on Linux at that time. Do you have an idea where that man page comes from? Some early glibc documentation? See also: http://www.rt.com/man/scanf.3.html http://www.linuxvalley.it/encyclopedia/ldp/manpage/man3/scanf.3.php http://www.squarebox.co.uk/cgi-squarebox/manServer/scanf.3 It seems that version of the man page is in some Linux distribution and doesn't come from kernel.org. Okay, after checking, it seems to be found on RedHat, at least RHEL3. -- Stéphane -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#487254: manpages-dev: *scanf may set errno to ERANGE
On Mon, Jun 23, 2008 at 11:33 AM, Stephane Chazelas
[EMAIL PROTECTED] wrote:
On Mon, Jun 23, 2008 at 11:27:39AM +0200, Michael Kerrisk wrote:
[...]
Also, the %as GNU extension seems not to be documented
(it may return ENOMEM) in the man page. It is in the glibc
documentation.
Have you tried using this? I'm trying to test now, but gcc complains
that '%a' expects type 'float *'.
[...]
~$ cat a.c
#include stdio.h
int main(int argc, char **argv)
{
char *a;
sscanf(argv[1], %as, a);
puts(a);
return 0;
}
~$ cc -Wall -c a.c
~$ ./a xx yy
xx
~$ gcc-2.95 -Wall -c a.c
~$ gcc-3.3 -Wall -c a.c
~$ gcc-3.4 -Wall -c a.c
~$ gcc-4.1 -Wall -c a.c
~$ gcc-4.2 -Wall -c a.c
~$ gcc-4.3 -Wall -c a.c
~$
Seems OK.
Maybe you had %a instead of %as?
No, my problem was that my cc alias includes ansi c 99, which disables
this scanf() feature...
Thanks
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
man-pages online: http://www.kernel.org/doc/man-pages/online_pages.html
Found a bug? http://www.kernel.org/doc/man-pages/reporting_bugs.html
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#487254: manpages-dev: *scanf may set errno to ERANGE
On Mon, Jun 23, 2008 at 11:27:39AM +0200, Michael Kerrisk wrote:
[...]
Also, the %as GNU extension seems not to be documented
(it may return ENOMEM) in the man page. It is in the glibc
documentation.
Have you tried using this? I'm trying to test now, but gcc complains
that '%a' expects type 'float *'.
[...]
~$ cat a.c
#include stdio.h
int main(int argc, char **argv)
{
char *a;
sscanf(argv[1], %as, a);
puts(a);
return 0;
}
~$ cc -Wall -c a.c
~$ ./a xx yy
xx
~$ gcc-2.95 -Wall -c a.c
~$ gcc-3.3 -Wall -c a.c
~$ gcc-3.4 -Wall -c a.c
~$ gcc-4.1 -Wall -c a.c
~$ gcc-4.2 -Wall -c a.c
~$ gcc-4.3 -Wall -c a.c
~$
Seems OK.
Maybe you had %a instead of %as?
--
Stéphane
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#487254: manpages-dev: *scanf may set errno to ERANGE
Stephane, Also, the %as GNU extension seems not to be documented (it may return ENOMEM) in the man page. It is in the glibc documentation. Have you tried using this? I'm trying to test now, but gcc complains that '%a' expects type 'float *'. Cheers, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ man-pages online: http://www.kernel.org/doc/man-pages/online_pages.html Found a bug? http://www.kernel.org/doc/man-pages/reporting_bugs.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#487254: manpages-dev: *scanf may set errno to ERANGE
On Mon, Jun 23, 2008 at 11:34 AM, Michael Kerrisk
[EMAIL PROTECTED] wrote:
On Mon, Jun 23, 2008 at 11:33 AM, Stephane Chazelas
[EMAIL PROTECTED] wrote:
On Mon, Jun 23, 2008 at 11:27:39AM +0200, Michael Kerrisk wrote:
[...]
Also, the %as GNU extension seems not to be documented
(it may return ENOMEM) in the man page. It is in the glibc
documentation.
Have you tried using this? I'm trying to test now, but gcc complains
that '%a' expects type 'float *'.
[...]
~$ cat a.c
#include stdio.h
int main(int argc, char **argv)
{
char *a;
sscanf(argv[1], %as, a);
puts(a);
return 0;
}
~$ cc -Wall -c a.c
~$ ./a xx yy
xx
~$ gcc-2.95 -Wall -c a.c
~$ gcc-3.3 -Wall -c a.c
~$ gcc-3.4 -Wall -c a.c
~$ gcc-4.1 -Wall -c a.c
~$ gcc-4.2 -Wall -c a.c
~$ gcc-4.3 -Wall -c a.c
~$
Seems OK.
Maybe you had %a instead of %as?
No, my problem was that my cc alias includes ansi c 99, which disables
this scanf() feature...
Okay -- so %as is available by default, but disabled by -std=c99,
unless _GNU_SOURCE is also specified :-}
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
man-pages online: http://www.kernel.org/doc/man-pages/online_pages.html
Found a bug? http://www.kernel.org/doc/man-pages/reporting_bugs.html
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#487254: manpages-dev: *scanf may set errno to ERANGE
tags 487254 fixed-upstream thanks Stephane, both halves of this bug are now fixed. Could you please review the following new text, which will appear in man-pages 3.01. Cheers, Michael NOTES The GNU C library supports a non-standard extension that causes the library to dynamically allocate a string of sufficient size for input strings for the %s and %a[range] conversion specifiers. To make use of this feature, specify a as a length modifier (thus %as or %a[range]). The caller must free(3) the returned string, as in the following example: char *p; scanf(%a[a-zA-Z], p); printf(%s0, p); free(p); This feature is not available if the program is compiled with cc -std=cc99 or cc -D_ISOC99_SOURCE (unless _GNU_SOURCE is also specified), in which case the a is interpreted as a specifier for floating point numbers (see above). Since version 2.7, glibc also provides the m modifier for the same purpose as the a modifier. The m modifier has the follow- ing advantages: * It may also be applied to %c conversion specifiers (e.g., %3mc). * It avoids ambiguity with respect to the %a floating-point conversion specifier (and is unaffected by cc -std=99 etc.) * It is specified in the upcoming revision of the POSIX.1 stan- dard. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#487254: manpages-dev: *scanf may set errno to ERANGE
On Mon, Jun 23, 2008 at 12:37:50PM +0200, Michael Kerrisk wrote:
[...]
NOTES
The GNU C library supports a non-standard extension that causes
the library to dynamically allocate a string of sufficient size
for input strings for the %s and %a[range] conversion
specifiers. To make use of this feature, specify a as a length
modifier (thus %as or %a[range]). The caller must free(3) the
returned string, as in the following example:
char *p;
scanf(%a[a-zA-Z], p);
You need to check the return value of scanf (could be 0 or EOF,
caused by the absence of letters in the input, or an EOF or read
error or ENOMEM.
printf(%s0, p);
typo? printf(%s\n, p)
free(p);
That might free something unallocated.
This feature is not available if the program is compiled with
cc -std=cc99 or cc -D_ISOC99_SOURCE (unless _GNU_SOURCE is also
specified), in which case the a is interpreted as a specifier
for floating point numbers (see above).
Maybe gcc instead of cc as I don't expect all the cc
implementations to have such a -std option.
Since version 2.7, glibc also provides the m modifier for the
same purpose as the a modifier. The m modifier has the follow-
ing advantages:
* It may also be applied to %c conversion specifiers (e.g.,
%3mc).
* It avoids ambiguity with respect to the %a floating-point
conversion specifier (and is unaffected by cc -std=99 etc.)
* It is specified in the upcoming revision of the POSIX.1 stan-
dard.
Thanks for that, I hadn't thought of checking the draft.
I can see the draft makes it clear that you don't need to free
the buffer if scanf fails. I think it should be mentionned in
the man page as well as it seems to also be the case for %a.
So:
errno = 0;
n = scanf(..., p);
if (n == 1) {
printf(OK: %s\n, p);
free(p);
} else if (errno != 0) {
perror(scanf);
}
else {
fprintf(stderr, expected letters, not \%s\\n, ...);
}
--
Stéphane
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#487254: manpages-dev: *scanf may set errno to ERANGE
On Mon, Jun 23, 2008 at 1:31 PM, Stephane Chazelas [EMAIL PROTECTED] wrote: On Mon, Jun 23, 2008 at 12:37:50PM +0200, Michael Kerrisk wrote: [...] This feature is not available if the program is compiled with cc -std=cc99 or cc -D_ISOC99_SOURCE (unless _GNU_SOURCE is also [...] typo: -std=c99, not cc99. Thanks. Fixed. It sort of balanced out. Elsewhere in the page I wrote another typo: -std=99. ;-) Cheers, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ man-pages online: http://www.kernel.org/doc/man-pages/online_pages.html Found a bug? http://www.kernel.org/doc/man-pages/reporting_bugs.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#487254: manpages-dev: *scanf may set errno to ERANGE
On Mon, Jun 23, 2008 at 12:37:50PM +0200, Michael Kerrisk wrote: [...] This feature is not available if the program is compiled with cc -std=cc99 or cc -D_ISOC99_SOURCE (unless _GNU_SOURCE is also [...] typo: -std=c99, not cc99. -- Stéphane -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#487254: manpages-dev: *scanf may set errno to ERANGE
On Mon, Jun 23, 2008 at 01:34:04PM +0200, Michael Kerrisk wrote:
On Mon, Jun 23, 2008 at 1:31 PM, Stephane Chazelas
[EMAIL PROTECTED] wrote:
On Mon, Jun 23, 2008 at 12:37:50PM +0200, Michael Kerrisk wrote:
[...]
This feature is not available if the program is compiled with
cc -std=cc99 or cc -D_ISOC99_SOURCE (unless _GNU_SOURCE is also
[...]
typo: -std=c99, not cc99.
Thanks. Fixed. It sort of balanced out. Elsewhere in the page I
wrote another typo: -std=99.
[...]
With tcc, you need the -D_GNU_SOURCE:
~$ cat a.c
#include stdio.h
int main()
{
char *a = 0;
int n;
n = sscanf(test, %as, a);
printf(%d %s\n, n, a);
return 0;
}
~$ tcc -run ./a.c
0 (null)
~$ tcc -D_GNU_SOURCE -run ./a.c
1 test
~$ tcc a.c
~$ nm -D a.out | grep scanf
U __isoc99_sscanf
~$ tcc -D_GNU_SOURCE a.c
~$ nm -D a.out | grep scanf
U sscanf
On debian, cc can be tcc.
~$ update-alternatives --list cc
/usr/bin/gcc
/usr/bin/tcc
--
Stéphane
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#487254: manpages-dev: *scanf may set errno to ERANGE
Hi Stephane,
On Mon, Jun 23, 2008 at 1:15 PM, Stephane Chazelas
[EMAIL PROTECTED] wrote:
On Mon, Jun 23, 2008 at 12:37:50PM +0200, Michael Kerrisk wrote:
[...]
NOTES
The GNU C library supports a non-standard extension that causes
the library to dynamically allocate a string of sufficient size
for input strings for the %s and %a[range] conversion
specifiers. To make use of this feature, specify a as a length
modifier (thus %as or %a[range]). The caller must free(3) the
returned string, as in the following example:
char *p;
scanf(%a[a-zA-Z], p);
You need to check the return value of scanf (could be 0 or EOF,
caused by the absence of letters in the input, or an EOF or read
error or ENOMEM.
printf(%s0, p);
typo? printf(%s\n, p)
Thanks for that. Forgot to double the slash in the source.
free(p);
That might free something unallocated.
Good catch! Thanks.
This feature is not available if the program is compiled with
cc -std=cc99 or cc -D_ISOC99_SOURCE (unless _GNU_SOURCE is also
specified), in which case the a is interpreted as a specifier
for floating point numbers (see above).
Maybe gcc instead of cc as I don't expect all the cc
implementations to have such a -std option.
Done.
Since version 2.7, glibc also provides the m modifier for the
same purpose as the a modifier. The m modifier has the follow-
ing advantages:
* It may also be applied to %c conversion specifiers (e.g.,
%3mc).
* It avoids ambiguity with respect to the %a floating-point
conversion specifier (and is unaffected by cc -std=99 etc.)
* It is specified in the upcoming revision of the POSIX.1 stan-
dard.
Thanks for that, I hadn't thought of checking the draft.
I only though of it because for a long time I had a FIXME in the
scanf.3 page saying Document the m modifier!
I can see the draft makes it clear that you don't need to free
the buffer if scanf fails. I think it should be mentionned in
the man page as well as it seems to also be the case for %a.
Yes, good idea.
So:
errno = 0;
n = scanf(..., p);
if (n == 1) {
printf(OK: %s\n, p);
free(p);
} else if (errno != 0) {
perror(scanf);
}
else {
fprintf(stderr, expected letters, not \%s\\n, ...);
}
Thanks for that piece of code. I'll include a version of that in the page.
Cheers,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
man-pages online: http://www.kernel.org/doc/man-pages/online_pages.html
Found a bug? http://www.kernel.org/doc/man-pages/reporting_bugs.html
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#487254: manpages-dev: *scanf may set errno to ERANGE
On Mon, Jun 23, 2008 at 1:43 PM, Stephane Chazelas [EMAIL PROTECTED] wrote: On Mon, Jun 23, 2008 at 01:34:04PM +0200, Michael Kerrisk wrote: On Mon, Jun 23, 2008 at 1:31 PM, Stephane Chazelas [EMAIL PROTECTED] wrote: On Mon, Jun 23, 2008 at 12:37:50PM +0200, Michael Kerrisk wrote: [...] This feature is not available if the program is compiled with cc -std=cc99 or cc -D_ISOC99_SOURCE (unless _GNU_SOURCE is also [...] typo: -std=c99, not cc99. Thanks. Fixed. It sort of balanced out. Elsewhere in the page I wrote another typo: -std=99. [...] With tcc, you need the -D_GNU_SOURCE: Thanks. I don't think I'll worry about documenting that though. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#487254: manpages-dev: *scanf may set errno to ERANGE
Right, here's another version. Could you please have another read
through, Stephane
NOTES
The GNU C library supports a non-standard extension that causes
the library to dynamically allocate a string of sufficient size
for input strings for the %s and %a[range] conversion
specifiers. To make use of this feature, specify a as a length
modifier (thus %as or %a[range]). The caller must free(3) the
returned string, as in the following example:
char *p;
int n;
errno = 0;
n = scanf(%a[a-z], p);
printf(n=%d, errno=%d\n, n, errno);
if (n == 1) {
printf(read: %s\n, p);
free(p);
} else if (errno != 0) {
perror(scanf);
} else {
fprintf(stderr, No matching characters\n):
}
As shown in the above example, it is only necessary to call
free(3) if the scanf() call successfully read a string.
The a modifier is not available if the program is compiled with
gcc -std=c99 or gcc -D_ISOC99_SOURCE (unless _GNU_SOURCE is
also specified), in which case the a is interpreted as a speci-
fier for floating point numbers (see above).
Since version 2.7, glibc also provides the m modifier for the
same purpose as the a modifier. The m modifier has the follow-
ing advantages:
* It may also be applied to %c conversion specifiers (e.g.,
%3mc).
* It avoids ambiguity with respect to the %a floating-point
conversion specifier (and is unaffected by gcc -std=c99 etc.)
* It is specified in the upcoming revision of the POSIX.1 stan-
dard.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#487254: manpages-dev: *scanf may set errno to ERANGE
On Mon, Jun 23, 2008 at 01:43:39PM +0200, Michael Kerrisk wrote:
[...]
errno = 0;
n = scanf(..., p);
if (n == 1) {
printf(OK: %s\n, p);
free(p);
} else if (errno != 0) {
perror(scanf);
}
else {
fprintf(stderr, expected letters, not \%s\\n, ...);
Well, that error message would be OK for sscanf where you could
use the scanned string for the %s above, but not for scanf,
sorry.
}
Thanks for that piece of code. I'll include a version of that in the page.
[...]
One may also want to check for (n == EOF), though it's OK to
treat n == 0 and n == EOF the same when you only need to check
the correctness of the input (n==EOF means empty input).
--
Stéphane
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#487254: manpages-dev: *scanf may set errno to ERANGE
On Mon, Jun 23, 2008 at 01:45:28PM +0200, Michael Kerrisk wrote: On Mon, Jun 23, 2008 at 1:43 PM, Stephane Chazelas [EMAIL PROTECTED] wrote: On Mon, Jun 23, 2008 at 01:34:04PM +0200, Michael Kerrisk wrote: On Mon, Jun 23, 2008 at 1:31 PM, Stephane Chazelas [EMAIL PROTECTED] wrote: On Mon, Jun 23, 2008 at 12:37:50PM +0200, Michael Kerrisk wrote: [...] This feature is not available if the program is compiled with cc -std=cc99 or cc -D_ISOC99_SOURCE (unless _GNU_SOURCE is also [...] typo: -std=c99, not cc99. Thanks. Fixed. It sort of balanced out. Elsewhere in the page I wrote another typo: -std=99. [...] With tcc, you need the -D_GNU_SOURCE: Thanks. I don't think I'll worry about documenting that though. Hmmm, in stdio.h, we have: #if defined __USE_ISOC99 !defined __USE_GNU \ (!defined __LDBL_COMPAT || !defined __REDIRECT) \ (defined __STRICT_ANSI__ || defined __USE_XOPEN2K) # ifdef __REDIRECT /* For strict ISO C99 or POSIX compliance disallow %as, %aS and %a[ GNU extension which conflicts with valid %a followed by letter s, S or [. */ extern int __REDIRECT (fscanf, (FILE *__restrict __stream, __const char *__restrict __format, ...), __isoc99_fscanf) __wur; extern int __REDIRECT (scanf, (__const char *__restrict __format, ...), __isoc99_scanf) __wur; extern int __REDIRECT (sscanf, (__const char *__restrict __s, __const char *__restrict __format, ...), __isoc99_sscanf) __THROW; Which looks a bit bogus to me (see the handling of __REDIRECT for instance). __STRICT_ANSI__ is selected by -std=c99 and -ansi. __USE_XOPEN2K (XPG6) is selected when __POSIX_C_SOURCE = 200112L which is selected by: /* If none of the ANSI/POSIX macros are defined, use POSIX.1 and POSIX.2 (and IEEE Std 1003.1b-1993 unless _XOPEN_SOURCE is defined). */ #if ((!defined __STRICT_ANSI__ || (_XOPEN_SOURCE - 0) = 500) \ !defined _POSIX_SOURCE !defined _POSIX_C_SOURCE) # define _POSIX_SOURCE 1 # if defined _XOPEN_SOURCE (_XOPEN_SOURCE - 0) 500 # define _POSIX_C_SOURCE 2 # elif defined _XOPEN_SOURCE (_XOPEN_SOURCE - 0) 600 # define _POSIX_C_SOURCE 199506L # else # define _POSIX_C_SOURCE 200112L # endif #endif So, %as is not available for instance with: cc -D__STDC_VERSION__=199901L (tcc does set that as a builtin macro http://hg.sharesource.org/mercurialtcc/rev/1e81d5b65878) And it is availabe for instance with cc -D_ISOC99_SOURCE -D_XOPEN_SOURCE=500 Without any implicit define, %as will be enabled I think. -- Stéphane -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#487254: manpages-dev: *scanf may set errno to ERANGE
On Mon, Jun 23, 2008 at 01:47:59PM +0200, Michael Kerrisk wrote:
Right, here's another version. Could you please have another read
through, Stephane
Michael,
it looks good to me.
I suspect it wasn't your intention to leave
printf(n=%d, errno=%d\n, n, errno);
in though. That printf might set errno itself so that the next
check for errno wouldn't be valid.
NOTES
The GNU C library supports a non-standard extension that causes
the library to dynamically allocate a string of sufficient size
for input strings for the %s and %a[range] conversion
specifiers. To make use of this feature, specify a as a length
modifier (thus %as or %a[range]). The caller must free(3) the
returned string, as in the following example:
char *p;
int n;
errno = 0;
n = scanf(%a[a-z], p);
printf(n=%d, errno=%d\n, n, errno);
if (n == 1) {
printf(read: %s\n, p);
free(p);
} else if (errno != 0) {
perror(scanf);
} else {
fprintf(stderr, No matching characters\n):
}
As shown in the above example, it is only necessary to call
free(3) if the scanf() call successfully read a string.
The a modifier is not available if the program is compiled with
gcc -std=c99 or gcc -D_ISOC99_SOURCE (unless _GNU_SOURCE is
also specified), in which case the a is interpreted as a speci-
fier for floating point numbers (see above).
Since version 2.7, glibc also provides the m modifier for the
same purpose as the a modifier. The m modifier has the follow-
ing advantages:
* It may also be applied to %c conversion specifiers (e.g.,
%3mc).
* It avoids ambiguity with respect to the %a floating-point
conversion specifier (and is unaffected by gcc -std=c99 etc.)
* It is specified in the upcoming revision of the POSIX.1 stan-
dard.
Cheers,
Stéphane
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#487254: manpages-dev: *scanf may set errno to ERANGE
On Mon, Jun 23, 2008 at 3:13 PM, Stephane Chazelas [EMAIL PROTECTED] wrote: On Mon, Jun 23, 2008 at 01:47:59PM +0200, Michael Kerrisk wrote: Right, here's another version. Could you please have another read through, Stephane Michael, it looks good to me. I suspect it wasn't your intention to leave printf(n=%d, errno=%d\n, n, errno); D'oh! Thanks. Gone now. -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ man-pages online: http://www.kernel.org/doc/man-pages/online_pages.html Found a bug? http://www.kernel.org/doc/man-pages/reporting_bugs.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#487254: manpages-dev: *scanf may set errno to ERANGE
On Mon, Jun 23, 2008 at 01:52:07PM +0100, Stephane Chazelas wrote: [...] So, %as is not available for instance with: cc -D__STDC_VERSION__=199901L (tcc does set that as a builtin macro http://hg.sharesource.org/mercurialtcc/rev/1e81d5b65878) [...] FYI, and I'm getting off-topic here, the rationale for tcc setting __STDC_VERSION__ to 199901L can be found in glibc's features.h: /* Decide whether a compiler supports the long long datatypes. */ #if defined __GNUC__ \ || (defined __PGI defined __i386__ ) \ || (defined __INTEL_COMPILER (defined __i386__ || defined __ia64__)) \ || (defined __STDC_VERSION__ __STDC_VERSION__ = 199901L) # define __GLIBC_HAVE_LONG_LONG 1 #endif So any non-GNU compiler that supports long long would have to set __STDC_VERSION__ to something = 199901L So with any such compiler, you'd need to #define _GNU_SOURCE to have access to %as. In any case it makes sense to use _GNU_SOURCE given that it *is* a GNU extension. Best regards, Stéphane -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#487254: manpages-dev: *scanf may set errno to ERANGE
Michael Kerrisk wrote: But I'm not sure if that's a bug or not as I don't know whether manpages-dev is meant to document the GNU or other version of the libc functions. I don't know that manpages-dev has a policy on that. Upstream man-pages policy is: yes, document glibc specifics (but give context re portability). For Debian manpages the same policy applies. BTW, Michael, I take it you're the maintainer of the manpages-dev debian package, Sometimes one could get that impression ;-). But, no, I'm not. I'm merely the upstream maintainer. (Debain derives the downstream manpages and manpages-dev packages from my upstream man-pages. The Debian maintainer is Joey.) I'm very glad Michael is so active. A lot of bug reports are not Debian specific and this way the information is passed upstream directly. What's the debian view on the LSB. I don't know. In general the Debian project wishes to support the current version of LSB. However, this is best discussed on the debian-lsb list that runs on lists.debian.org. Regards, Joey -- Everybody talks about it, but nobody does anything about it! -- Mark Twain Please always Cc to me when replying to me on the lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#487254: manpages-dev: *scanf may set errno to ERANGE
On Fri, Jun 20, 2008 at 5:58 PM, Stephane Chazelas [EMAIL PROTECTED] wrote: On Fri, Jun 20, 2008 at 04:35:27PM +0100, Stephane Chazelas wrote: [...] In the GNU and UC versions of the libc (at least), the scanf/fscanf/sscanf... functions seem to be calling strtoxxx internally for number conversions. In doing so, errno may be set to ERANGE when the input doesn't fit in the number size requested and possibly to EINVAL for a figures not in the requested base. [...] For information, dietlibc's scanf doesn't exhibit that behavior. On other Unices, it seems to vary, and it doesn't seem to be often clearly documented. Hi Stephane, Thanks for the note. I will look at this a bit more. I see you sent a note into the Austin list about this. Two things: it's alway worth CCing me on such notes, since I do follow Austin. second: you may make more headway by raising a proper bugreport against the standard -- these bug reports are called Aardvarks. Look on the Austin site for info. Cheers, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ man-pages online: http://www.kernel.org/doc/man-pages/online_pages.html Found a bug? http://www.kernel.org/doc/man-pages/reporting_bugs.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#487254: manpages-dev: *scanf may set errno to ERANGE
Package: manpages-dev Version: 2.80-1 Severity: normal In the GNU and UC versions of the libc (at least), the scanf/fscanf/sscanf... functions seem to be calling strtoxxx internally for number conversions. In doing so, errno may be set to ERANGE when the input doesn't fit in the number size requested and possibly to EINVAL for a figures not in the requested base. I think this should be mentionned. It should probably be mentionned that one shouldn't rely on that to check whether an out-of-range number was provided given that it is not clearly specified by POSIX. Also, the %as GNU extension seems not to be documented (it may return ENOMEM) in the man page. It is in the glibc documentation. It doesn't seem to be supported by ucLibc but is required on LSB 3.2 conformant systems, it would seem (http://refspecs.linux-foundation.org/LSB_3.2.0/LSB-Core-generic/LSB-Core-generic/baselib-scanf.html) -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.25-rc8 (PREEMPT) Locale: LANG=en_GB.ISO-8859-15, LC_CTYPE=en_US.ISO-8859-15 (charmap=ISO-8859-15) Shell: /bin/sh linked to /bin/bash Versions of packages manpages-dev depends on: ii manpages 2.80-1 Manual pages about using a GNU/Lin manpages-dev recommends no packages. -- debconf-show failed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#487254: manpages-dev: *scanf may set errno to ERANGE
On Fri, Jun 20, 2008 at 04:35:27PM +0100, Stephane Chazelas wrote: [...] In the GNU and UC versions of the libc (at least), the scanf/fscanf/sscanf... functions seem to be calling strtoxxx internally for number conversions. In doing so, errno may be set to ERANGE when the input doesn't fit in the number size requested and possibly to EINVAL for a figures not in the requested base. [...] For information, dietlibc's scanf doesn't exhibit that behavior. On other Unices, it seems to vary, and it doesn't seem to be often clearly documented. Best regards, Stéphane -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
