Re: [PATCH] ash: avoid GLIBC'ism %m
I wonder if there's a better solution to this. BusyBox has bb_perror_msg() and like. Maybe using these API's are better? On Mon, Jul 17, 2017 at 4:08 AM, Johannes Schindelin wrote: > GLIBC's printf() family supports the extension where the placeholder %m > is interpolated to strerror(errno). > > This is not portable. So don't use it. (It was only used in ash's source > code to begin with.) > > Signed-off-by: Johannes Schindelin > --- > Published-As: > https://github.com/dscho/busybox-w32/releases/tag/busybox-glibc-ism-v1 > Fetch-It-Via: git fetch https://github.com/dscho/busybox-w32 > busybox-glibc-ism-v1 > shell/ash.c | 14 -- > 1 file changed, 8 insertions(+), 6 deletions(-) > > diff --git a/shell/ash.c b/shell/ash.c > index b0c7dac54..e2ff15767 100644 > --- a/shell/ash.c > +++ b/shell/ash.c > @@ -3809,8 +3809,10 @@ freejob(struct job *jp) > static void > xtcsetpgrp(int fd, pid_t pgrp) > { > - if (tcsetpgrp(fd, pgrp)) > - ash_msg_and_raise_error("can't set tty process group (%m)"); > + if (tcsetpgrp(fd, pgrp)) { > + const char *err = strerror(errno); > + ash_msg_and_raise_error("can't set tty process group (%s)", > err); > + } > } > > /* > @@ -5343,7 +5345,7 @@ savefd(int from) > err = newfd < 0 ? errno : 0; > if (err != EBADF) { > if (err) > - ash_msg_and_raise_error("%d: %m", from); > + ash_msg_and_raise_error("%d: %s", from, > strerror(errno)); > close(from); > fcntl(newfd, F_SETFD, FD_CLOEXEC); > } > @@ -5358,7 +5360,7 @@ dup2_or_raise(int from, int to) > newfd = (from != to) ? dup2(from, to) : to; > if (newfd < 0) { > /* Happens when source fd is not open: try "echo >&99" */ > - ash_msg_and_raise_error("%d: %m", from); > + ash_msg_and_raise_error("%d: %s", from, strerror(errno)); > } > return newfd; > } > @@ -5489,7 +5491,7 @@ redirect(union node *redir, int flags) > /* "echo >&10" and 10 is a fd opened to a sh script? > */ > if (is_hidden_fd(sv, right_fd)) { > errno = EBADF; /* as if it is closed */ > - ash_msg_and_raise_error("%d: %m", right_fd); > + ash_msg_and_raise_error("%d: %s", right_fd, > strerror(errno)); > } > newfd = -1; > } else { > @@ -5523,7 +5525,7 @@ redirect(union node *redir, int flags) > if (newfd >= 0) > close(newfd); > errno = i; > - ash_msg_and_raise_error("%d: %m", fd); > + ash_msg_and_raise_error("%d: %s", fd, > strerror(errno)); > /* NOTREACHED */ > } > /* EBADF: it is not open - good, remember to > close it */ > > base-commit: 68e980545af6a8ffb2980f94a6edac4dd89940f3 > -- > 2.13.3.windows.1.13.gaf0c2223da0 > ___ > busybox mailing list > busybox@busybox.net > http://lists.busybox.net/mailman/listinfo/busybox ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] ash: avoid GLIBC'ism %m
Actually last time I checked ‘%m’ is POSIX contrary to glibc’s deprecated '%a’. However, I agree that it should not be used since at least uClibc can be built without support for it. BR, Markus - The panama-hat hacker On 17 Jul 2017, at 04:01 , Kang-Che Sung wrote: > I wonder if there's a better solution to this. > BusyBox has bb_perror_msg() and like. Maybe using these API's are better? > > On Mon, Jul 17, 2017 at 4:08 AM, Johannes Schindelin > wrote: >> GLIBC's printf() family supports the extension where the placeholder %m >> is interpolated to strerror(errno). >> >> This is not portable. So don't use it. (It was only used in ash's source >> code to begin with.) >> >> Signed-off-by: Johannes Schindelin >> --- >> Published-As: >> https://github.com/dscho/busybox-w32/releases/tag/busybox-glibc-ism-v1 >> Fetch-It-Via: git fetch https://github.com/dscho/busybox-w32 >> busybox-glibc-ism-v1 >> shell/ash.c | 14 -- >> 1 file changed, 8 insertions(+), 6 deletions(-) >> >> diff --git a/shell/ash.c b/shell/ash.c >> index b0c7dac54..e2ff15767 100644 >> --- a/shell/ash.c >> +++ b/shell/ash.c >> @@ -3809,8 +3809,10 @@ freejob(struct job *jp) >> static void >> xtcsetpgrp(int fd, pid_t pgrp) >> { >> - if (tcsetpgrp(fd, pgrp)) >> - ash_msg_and_raise_error("can't set tty process group (%m)"); >> + if (tcsetpgrp(fd, pgrp)) { >> + const char *err = strerror(errno); >> + ash_msg_and_raise_error("can't set tty process group (%s)", >> err); >> + } >> } >> >> /* >> @@ -5343,7 +5345,7 @@ savefd(int from) >>err = newfd < 0 ? errno : 0; >>if (err != EBADF) { >>if (err) >> - ash_msg_and_raise_error("%d: %m", from); >> + ash_msg_and_raise_error("%d: %s", from, >> strerror(errno)); >>close(from); >>fcntl(newfd, F_SETFD, FD_CLOEXEC); >>} >> @@ -5358,7 +5360,7 @@ dup2_or_raise(int from, int to) >>newfd = (from != to) ? dup2(from, to) : to; >>if (newfd < 0) { >>/* Happens when source fd is not open: try "echo >&99" */ >> - ash_msg_and_raise_error("%d: %m", from); >> + ash_msg_and_raise_error("%d: %s", from, strerror(errno)); >>} >>return newfd; >> } >> @@ -5489,7 +5491,7 @@ redirect(union node *redir, int flags) >>/* "echo >&10" and 10 is a fd opened to a sh script? >> */ >>if (is_hidden_fd(sv, right_fd)) { >>errno = EBADF; /* as if it is closed */ >> - ash_msg_and_raise_error("%d: %m", right_fd); >> + ash_msg_and_raise_error("%d: %s", right_fd, >> strerror(errno)); >>} >>newfd = -1; >>} else { >> @@ -5523,7 +5525,7 @@ redirect(union node *redir, int flags) >>if (newfd >= 0) >>close(newfd); >>errno = i; >> - ash_msg_and_raise_error("%d: %m", >> fd); >> + ash_msg_and_raise_error("%d: %s", >> fd, strerror(errno)); >>/* NOTREACHED */ >>} >>/* EBADF: it is not open - good, remember to >> close it */ >> >> base-commit: 68e980545af6a8ffb2980f94a6edac4dd89940f3 >> -- >> 2.13.3.windows.1.13.gaf0c2223da0 >> ___ >> busybox mailing list >> busybox@busybox.net >> http://lists.busybox.net/mailman/listinfo/busybox > ___ > busybox mailing list > busybox@busybox.net > http://lists.busybox.net/mailman/listinfo/busybox //Markus - The panama-hat hacker signature.asc Description: Message signed with OpenPGP using GPGMail ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] ash: avoid GLIBC'ism %m
On Wed, Jul 19, 2017 at 2:11 AM, Markus Gothe wrote: > Actually last time I checked ‘%m’ is POSIX contrary to glibc’s deprecated > '%a’. > However, I agree that it should not be used since at least uClibc can be > built without support for it. How come %m is POSIX when I didn't see any mention of it in this page? http://pubs.opengroup.org/onlinepubs/9699919799/functions/fprintf.html ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] ash: avoid GLIBC'ism %m
On 2017-07-18 9:15 PM, Kang-Che Sung wrote: On Wed, Jul 19, 2017 at 2:11 AM, Markus Gothe wrote: Actually last time I checked ‘%m’ is POSIX contrary to glibc’s deprecated '%a’. However, I agree that it should not be used since at least uClibc can be built without support for it. How come %m is POSIX when I didn't see any mention of it in this page? http://pubs.opengroup.org/onlinepubs/9699919799/functions/fprintf.html It does not appear to be part of POSIX or the Single UNIX Specification. The glibc man page (as of 2016-12-12) even indicates that it is a glibc-specific extension: *m *(Glibc extension; supported by uClibc and musl.) Print output of /strerror(errno)/. No argument is required. The Gnulib manual has a pretty nice page mentioning several printf() incompatibilities and the operating systems they don't play nicely with: https://www.gnu.org/software/gnulib/manual/html_node/fprintf.html -Jody Bruchon ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] ash: avoid GLIBC'ism %m
Look over here http://pubs.opengroup.org/onlinepubs/9699919799/functions/scanf.html instead: [CX] The %c, %s, and %[ conversion specifiers shall accept an optional assignment-allocation character 'm', which shall cause a memory buffer to be allocated to hold the string converted including a terminating null character. In such a case, the argument corresponding to the conversion specifier should be a reference to a pointer variable that will receive a pointer to the allocated buffer. The system shall allocate a buffer as if malloc() had been called. The application shall be responsible for freeing the memory after usage. If there is insufficient memory to allocate a buffer, the function shall set errno to [ENOMEM] and a conversion error shall result. If the function returns EOF, any memory successfully allocated for parameters using assignment-allocation character 'm' by this call shall be freed before the function returns. I rest my case… //Markus - The panama-hat hacker On 19 Jul 2017, at 03:47 , Jody Bruchon wrote: > On 2017-07-18 9:15 PM, Kang-Che Sung wrote: >> On Wed, Jul 19, 2017 at 2:11 AM, Markus Gothe >> wrote: >>> Actually last time I checked ‘%m’ is POSIX contrary to glibc’s deprecated >>> '%a’. However, I agree that it should not be used since at least uClibc can >>> be built without support for it. >> How come %m is POSIX when I didn't see any mention of it in this page? >> http://pubs.opengroup.org/onlinepubs/9699919799/functions/fprintf.html > It does not appear to be part of POSIX or the Single UNIX Specification. The > glibc man page (as of 2016-12-12) even indicates that it is a glibc-specific > extension: > > *m *(Glibc extension; supported by uClibc and musl.) Print output of > /strerror(errno)/. No argument is required. > > The Gnulib manual has a pretty nice page mentioning several printf() > incompatibilities and the operating systems they don't play nicely with: > https://www.gnu.org/software/gnulib/manual/html_node/fprintf.html > > > -Jody Bruchon > ___ > busybox mailing list > busybox@busybox.net > http://lists.busybox.net/mailman/listinfo/busybox signature.asc Description: Message signed with OpenPGP using GPGMail ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] ash: avoid GLIBC'ism %m
However it should be noted that this seems not to be the same as glibc %m: "To use the dynamic allocation conversion specifier in C99 and C11, specify m as a length modifier as per POSIX.1-2008. That is, use %ms or %m[…]." So I guess, the basic assumption of not using %m for errors is correct. On 19 Jul 2017, at 20:34 , Markus Gothe wrote: > Look over here > http://pubs.opengroup.org/onlinepubs/9699919799/functions/scanf.html instead: > > [CX] The %c, %s, and %[ conversion specifiers shall accept an > optional assignment-allocation character 'm', which shall cause a memory > buffer to be allocated to hold the string converted including a terminating > null character. In such a case, the argument corresponding to the conversion > specifier should be a reference to a pointer variable that will receive a > pointer to the allocated buffer. The system shall allocate a buffer as if > malloc() had been called. The application shall be responsible for freeing > the memory after usage. If there is insufficient memory to allocate a buffer, > the function shall set errno to [ENOMEM] and a conversion error shall result. > If the function returns EOF, any memory successfully allocated for parameters > using assignment-allocation character 'm' by this call shall be freed before > the function returns. > > I rest my case… > > //Markus - The panama-hat hacker > > On 19 Jul 2017, at 03:47 , Jody Bruchon wrote: > >> On 2017-07-18 9:15 PM, Kang-Che Sung wrote: >>> On Wed, Jul 19, 2017 at 2:11 AM, Markus Gothe >>> wrote: Actually last time I checked ‘%m’ is POSIX contrary to glibc’s deprecated '%a’. However, I agree that it should not be used since at least uClibc can be built without support for it. >>> How come %m is POSIX when I didn't see any mention of it in this page? >>> http://pubs.opengroup.org/onlinepubs/9699919799/functions/fprintf.html >> It does not appear to be part of POSIX or the Single UNIX Specification. The >> glibc man page (as of 2016-12-12) even indicates that it is a glibc-specific >> extension: >> >> *m *(Glibc extension; supported by uClibc and musl.) Print output of >> /strerror(errno)/. No argument is required. >> >> The Gnulib manual has a pretty nice page mentioning several printf() >> incompatibilities and the operating systems they don't play nicely with: >> https://www.gnu.org/software/gnulib/manual/html_node/fprintf.html >> >> >> -Jody Bruchon >> ___ >> busybox mailing list >> busybox@busybox.net >> http://lists.busybox.net/mailman/listinfo/busybox > > ___ > busybox mailing list > busybox@busybox.net > http://lists.busybox.net/mailman/listinfo/busybox //Markus - The panama-hat hacker signature.asc Description: Message signed with OpenPGP using GPGMail ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] ash: avoid GLIBC'ism %m
On 2017-07-19 14:34, Markus Gothe wrote: Look over here http://pubs.opengroup.org/onlinepubs/9699919799/functions/scanf.html instead: The %m in BusyBox is a printf specifier, not a scanf specifier. How is this link relevant to printf("%m")? ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] ash: avoid GLIBC'ism %m
Ah, my mistake! Seems like I mixed the two up and made the assumption that they were the same for both scanf and printf. On 19 Jul 2017, at 20:37 , Jody Bruchon wrote: > On 2017-07-19 14:34, Markus Gothe wrote: >> Look over here >> http://pubs.opengroup.org/onlinepubs/9699919799/functions/scanf.html instead: > The %m in BusyBox is a printf specifier, not a scanf specifier. How is this > link relevant to printf("%m")? > ___ > busybox mailing list > busybox@busybox.net > http://lists.busybox.net/mailman/listinfo/busybox //Markus - The panama-hat hacker signature.asc Description: Message signed with OpenPGP using GPGMail ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] ash: avoid GLIBC'ism %m
On Wed, Jul 19, 2017 at 3:47 AM, Jody Bruchon wrote: > On 2017-07-18 9:15 PM, Kang-Che Sung wrote: >> >> On Wed, Jul 19, 2017 at 2:11 AM, Markus Gothe >> wrote: >>> >>> Actually last time I checked ‘%m’ is POSIX contrary to glibc’s deprecated >>> '%a’. However, I agree that it should not be used since at least uClibc can >>> be built without support for it. >> >> How come %m is POSIX when I didn't see any mention of it in this page? >> http://pubs.opengroup.org/onlinepubs/9699919799/functions/fprintf.html > > It does not appear to be part of POSIX or the Single UNIX Specification. The > glibc man page (as of 2016-12-12) even indicates that it is a glibc-specific > extension: > > *m *(Glibc extension; supported by uClibc and musl.) Print output of > /strerror(errno)/. No argument is required. This sounds like every libc has already conceded to implementing it. Let's benefit from it then? ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] ash: avoid GLIBC'ism %m
Hi Denys, On Fri, 21 Jul 2017, Denys Vlasenko wrote: > On Wed, Jul 19, 2017 at 3:47 AM, Jody Bruchon wrote: > > On 2017-07-18 9:15 PM, Kang-Che Sung wrote: > >> > >> On Wed, Jul 19, 2017 at 2:11 AM, Markus Gothe > >> wrote: > >>> > >>> Actually last time I checked ‘%m’ is POSIX contrary to glibc’s deprecated > >>> '%a’. However, I agree that it should not be used since at least uClibc > >>> can > >>> be built without support for it. > >> > >> How come %m is POSIX when I didn't see any mention of it in this page? > >> http://pubs.opengroup.org/onlinepubs/9699919799/functions/fprintf.html > > > > It does not appear to be part of POSIX or the Single UNIX Specification. The > > glibc man page (as of 2016-12-12) even indicates that it is a glibc-specific > > extension: > > > > *m *(Glibc extension; supported by uClibc and musl.) Print output of > > /strerror(errno)/. No argument is required. > > This sounds like every libc has already conceded to implementing it. > > Let's benefit from it then? No, not every libc. I would not have spent the time and effort to develop the patch, contribute it, rework it and contribute a second iteration if it was not for a good reason now, would I. Ciao, Johannes___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] ash: avoid GLIBC'ism %m
On 7/22/2017 2:56 PM, Johannes Schindelin wrote: Hi Denys, On Fri, 21 Jul 2017, Denys Vlasenko wrote: On Wed, Jul 19, 2017 at 3:47 AM, Jody Bruchon wrote: On 2017-07-18 9:15 PM, Kang-Che Sung wrote: On Wed, Jul 19, 2017 at 2:11 AM, Markus Gothe wrote: Actually last time I checked ‘%m’ is POSIX contrary to glibc’s deprecated '%a’. However, I agree that it should not be used since at least uClibc can be built without support for it. How come %m is POSIX when I didn't see any mention of it in this page? http://pubs.opengroup.org/onlinepubs/9699919799/functions/fprintf.html It does not appear to be part of POSIX or the Single UNIX Specification. The glibc man page (as of 2016-12-12) even indicates that it is a glibc-specific extension: *m *(Glibc extension; supported by uClibc and musl.) Print output of /strerror(errno)/. No argument is required. This sounds like every libc has already conceded to implementing it. Let's benefit from it then? No, not every libc. I would not have spent the time and effort to develop the patch, contribute it, rework it and contribute a second iteration if it was not for a good reason now, would I. Ciao, Johannes I believe his point is that your patch adds size to busybox which is unneeded for most users. (btw, it's recommended to post bloatcheck numbers with a patch. If you show a small number from bloatcheck then there is less to argue about) Which libc are you using? Do you think %m support could be checked with an ifdef? -Mike ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] ash: avoid GLIBC'ism %m
On Sun, Jul 23, 2017 at 4:33 AM, Michael Conrad wrote: > On 7/22/2017 2:56 PM, Johannes Schindelin wrote: >> >> No, not every libc. I would not have spent the time and effort to develop >> the patch, contribute it, rework it and contribute a second iteration if >> it was not for a good reason now, would I. >> > > I believe his point is that your patch adds size to busybox which is > unneeded for most users. (btw, it's recommended to post bloatcheck numbers > with a patch. If you show a small number from bloatcheck then there is less > to argue about) > > Which libc are you using? Do you think %m support could be checked with an > ifdef? > How about wrapping the printf("%m") uses within the __GNU_LIBRARY__ macro? It seems that %m support has been there from the beginning of glibc. ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] ash: avoid GLIBC'ism %m
On Sun, Jul 23, 2017 at 10:03 AM, Kang-Che Sung wrote: > > How about wrapping the printf("%m") uses within the __GNU_LIBRARY__ macro? > It seems that %m support has been there from the beginning of glibc. Correction. It's since glibc 1.06. I've looked in the old ChangeLog entries and saw this: Tue Oct 20 18:36:40 1992 Roland McGrath (rol...@geech.gnu.ai.mit.edu) * configure: Write error message and lose for option with missing arg. * stdio/__vfscanf.c: Add `a' modifier, which makes %s and %[ fill in a char ** with a malloc'd string. (STRING_ADD_CHAR, STRING_ARG): New macros to deal with this hair. (%s, %[): Use them. * posix/gnu/types.h [__GNUC__] (__fsid_t): Define as long long. * stdio/vfprintf.c: Add %m, which is %s of strerror (errno). So... the check would be probably like this: #if __GNU_LIBRARY__ > 1 ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] ash: avoid GLIBC'ism %m
On Sat, Jul 22, 2017 at 8:56 PM, Johannes Schindelin wrote: > On Fri, 21 Jul 2017, Denys Vlasenko wrote: > >> On Wed, Jul 19, 2017 at 3:47 AM, Jody Bruchon wrote: >> > On 2017-07-18 9:15 PM, Kang-Che Sung wrote: >> >> >> >> On Wed, Jul 19, 2017 at 2:11 AM, Markus Gothe >> >> wrote: >> >>> >> >>> Actually last time I checked ‘%m’ is POSIX contrary to glibc’s deprecated >> >>> '%a’. However, I agree that it should not be used since at least uClibc >> >>> can >> >>> be built without support for it. >> >> >> >> How come %m is POSIX when I didn't see any mention of it in this page? >> >> http://pubs.opengroup.org/onlinepubs/9699919799/functions/fprintf.html >> > >> > It does not appear to be part of POSIX or the Single UNIX Specification. >> > The >> > glibc man page (as of 2016-12-12) even indicates that it is a >> > glibc-specific >> > extension: >> > >> > *m *(Glibc extension; supported by uClibc and musl.) Print output of >> > /strerror(errno)/. No argument is required. >> >> This sounds like every libc has already conceded to implementing it. >> >> Let's benefit from it then? > > No, not every libc. I would not have spent the time and effort to develop > the patch, contribute it, rework it and contribute a second iteration if > it was not for a good reason now, would I. Good point. What libc is that? ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] ash: avoid GLIBC'ism %m
On Sun, Jul 23, 2017 at 9:34 PM, Denys Vlasenko wrote: > On Sat, Jul 22, 2017 at 8:56 PM, Johannes Schindelin > wrote: >> On Fri, 21 Jul 2017, Denys Vlasenko wrote: >> >>> On Wed, Jul 19, 2017 at 3:47 AM, Jody Bruchon wrote: >>> > On 2017-07-18 9:15 PM, Kang-Che Sung wrote: >>> >> >>> >> On Wed, Jul 19, 2017 at 2:11 AM, Markus Gothe >>> >> wrote: >>> >>> >>> >>> Actually last time I checked ‘%m’ is POSIX contrary to glibc’s >>> >>> deprecated >>> >>> '%a’. However, I agree that it should not be used since at least uClibc >>> >>> can >>> >>> be built without support for it. >>> >> >>> >> How come %m is POSIX when I didn't see any mention of it in this page? >>> >> http://pubs.opengroup.org/onlinepubs/9699919799/functions/fprintf.html >>> > >>> > It does not appear to be part of POSIX or the Single UNIX Specification. >>> > The >>> > glibc man page (as of 2016-12-12) even indicates that it is a >>> > glibc-specific >>> > extension: >>> > >>> > *m *(Glibc extension; supported by uClibc and musl.) Print output of >>> > /strerror(errno)/. No argument is required. >>> >>> This sounds like every libc has already conceded to implementing it. >>> >>> Let's benefit from it then? >> >> No, not every libc. I would not have spent the time and effort to develop >> the patch, contribute it, rework it and contribute a second iteration if >> it was not for a good reason now, would I. > > Good point. > What libc is that? Ping? ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] ash: avoid GLIBC'ism %m
On Mon, Jul 24, 2017 at 3:34 AM, Denys Vlasenko wrote: > On Sat, Jul 22, 2017 at 8:56 PM, Johannes Schindelin > wrote: >> On Fri, 21 Jul 2017, Denys Vlasenko wrote: >> >>> On Wed, Jul 19, 2017 at 3:47 AM, Jody Bruchon wrote: >>> > On 2017-07-18 9:15 PM, Kang-Che Sung wrote: >>> >> >>> >> On Wed, Jul 19, 2017 at 2:11 AM, Markus Gothe >>> >> wrote: >>> >>> >>> >>> Actually last time I checked ‘%m’ is POSIX contrary to glibc’s >>> >>> deprecated >>> >>> '%a’. However, I agree that it should not be used since at least uClibc >>> >>> can >>> >>> be built without support for it. >>> >> >>> >> How come %m is POSIX when I didn't see any mention of it in this page? >>> >> http://pubs.opengroup.org/onlinepubs/9699919799/functions/fprintf.html >>> > >>> > It does not appear to be part of POSIX or the Single UNIX Specification. >>> > The >>> > glibc man page (as of 2016-12-12) even indicates that it is a >>> > glibc-specific >>> > extension: >>> > >>> > *m *(Glibc extension; supported by uClibc and musl.) Print output of >>> > /strerror(errno)/. No argument is required. >>> >>> This sounds like every libc has already conceded to implementing it. >>> >>> Let's benefit from it then? >> >> No, not every libc. I would not have spent the time and effort to develop >> the patch, contribute it, rework it and contribute a second iteration if >> it was not for a good reason now, would I. > > Good point. > What libc is that? Perhaps FreeBSD counts here. https://www.freebsd.org/cgi/man.cgi?printf(3) ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] ash: avoid GLIBC'ism %m
Hi Denys, On Sun, 23 Jul 2017, Denys Vlasenko wrote: > On Sat, Jul 22, 2017 at 8:56 PM, Johannes Schindelin > wrote: > > On Fri, 21 Jul 2017, Denys Vlasenko wrote: > > > >> On Wed, Jul 19, 2017 at 3:47 AM, Jody Bruchon wrote: > >> > On 2017-07-18 9:15 PM, Kang-Che Sung wrote: > >> >> > >> >> On Wed, Jul 19, 2017 at 2:11 AM, Markus Gothe > >> >> wrote: > >> >>> > >> >>> Actually last time I checked ‘%m’ is POSIX contrary to glibc’s > >> >>> deprecated > >> >>> '%a’. However, I agree that it should not be used since at least > >> >>> uClibc can > >> >>> be built without support for it. > >> >> > >> >> How come %m is POSIX when I didn't see any mention of it in this page? > >> >> http://pubs.opengroup.org/onlinepubs/9699919799/functions/fprintf.html > >> > > >> > It does not appear to be part of POSIX or the Single UNIX Specification. > >> > The > >> > glibc man page (as of 2016-12-12) even indicates that it is a > >> > glibc-specific > >> > extension: > >> > > >> > *m *(Glibc extension; supported by uClibc and musl.) Print output of > >> > /strerror(errno)/. No argument is required. > >> > >> This sounds like every libc has already conceded to implementing it. > >> > >> Let's benefit from it then? > > > > No, not every libc. I would not have spent the time and effort to develop > > the patch, contribute it, rework it and contribute a second iteration if > > it was not for a good reason now, would I. > > Good point. > What libc is that? MSVC runtime. I see that Ron got a cleaner patch in already. Thanks, Johannes___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] ash: avoid GLIBC'ism %m
Hi Markus, On Wed, 19 Jul 2017, Markus Gothe wrote: > However it should be noted that this [scanf's %m format] seems not to be > the same as glibc %m: "To use the dynamic allocation conversion > specifier in C99 and C11, specify m as a length modifier as per > POSIX.1-2008. That is, use %ms or %m[…]." It would have been very surprising if scanf could interpret %m as reading strerror(errno)... How would that work, to begin with? Ciao, Johannes___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox