Re: svn commit: r368714 - head/lib/libc/string
Konstantin Belousov wrote in : |On Sat, Dec 19, 2020 at 02:52:25PM +0100, Steffen Nurpmeso wrote: |> Kevin Bowling wrote in |> : |>|On Thu, Dec 17, 2020 at 9:33 AM Ian Lepore wrote: |>|> On Thu, 2020-12-17 at 18:22 +0200, Konstantin Belousov wrote: |>|>> On Thu, Dec 17, 2020 at 01:01:01PM +, Jessica Clarke wrote: |>|>>> On 17 Dec 2020, at 12:53, Konstantin Belousov |>|>>> wrote: |>| On Thu, Dec 17, 2020 at 12:41:47PM +, Mateusz Piotrowski |>| wrote: |>|> Author: 0mp (doc,ports committer) |>|> Date: Thu Dec 17 12:41:47 2020 |>|> New Revision: 368714 |>|> URL: https://svnweb.freebsd.org/changeset/base/368714 |> ... |>|> + return (0); |>| |>| return (0) is redundand. |> ... |>|>> Why it is bad practice ? |>|>> |>|>> C is a small language, and while knowing some quirks (like this one) |>|>> seems to be optional, others are not. And worse, that other quirks are |> ... |>|> How obscure is this quirk? I've been writing C code since 1983, |>|> including having released a freeware compiler (pre-gcc days) and |>|> working on a commercial C compiler. I used to moderate the c_language |>|> conference on BIX (back when that was a thing). I make my living |>|> writing C and C++ code every day. And yet, I had completely forgotten |>|> about this quirk. |> ... |>|In Kib’s defense I think this is commonly mentioned in C99 books \ |>|(at least |>|that’s where I learned of it) so it depends on when and where someone |>|learned. There are merits approaches of being explicit or brief. I have |> |> Nicely said. K&R C 2nd Ed. explicitly uses return(0) many times. | |We are long after K&R in any of its form. | |My point was that the example if of very low quality, and return (0); is |an indicator. Perhaps even more interesting point to make is the mix of |return from main() and exit(3) use in same 4 lines. Besides inconsistency, |exit(3) from main() should probably not used in examples or recommended |to novices at all. I .. cannot see this from the context above? I personally use _?exit only if execution must not continue aka control cannot be given back to code flow. For me .. not. C89 can be used here. (It is annoying only for field initializers, and there especially that the order must be correct in C89 mode, when FIELD_INIT[IN]() expands to nothing.) (Yes, one of the things i personally was out for was restartability without leaks for at least development, ie, it was only "fine" if one could have entered sf_main() multiple times without causing problems. This required "atexit_uninstall" and two distinct priorities for exit handlers, and a clean order of the "final" ones, also atcrash_uninstall, but it was nice to see "SF: memcache empty!" messages in debug code, knowing it is nice. Today i only do this a bit as i link other libraries anyway, and everybody uses ctors and dtors and it is all dynamically linked, .. and all that.) --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r368714 - head/lib/libc/string
On Sat, Dec 19, 2020 at 02:52:25PM +0100, Steffen Nurpmeso wrote: > Kevin Bowling wrote in > : > |On Thu, Dec 17, 2020 at 9:33 AM Ian Lepore wrote: > |> On Thu, 2020-12-17 at 18:22 +0200, Konstantin Belousov wrote: > |>> On Thu, Dec 17, 2020 at 01:01:01PM +, Jessica Clarke wrote: > |>>> On 17 Dec 2020, at 12:53, Konstantin Belousov > |>>> wrote: > | On Thu, Dec 17, 2020 at 12:41:47PM +, Mateusz Piotrowski > | wrote: > |> Author: 0mp (doc,ports committer) > |> Date: Thu Dec 17 12:41:47 2020 > |> New Revision: 368714 > |> URL: https://svnweb.freebsd.org/changeset/base/368714 > ... > |> + return (0); > | > | return (0) is redundand. > ... > |>> Why it is bad practice ? > |>> > |>> C is a small language, and while knowing some quirks (like this one) > |>> seems to be optional, others are not. And worse, that other quirks are > ... > |> How obscure is this quirk? I've been writing C code since 1983, > |> including having released a freeware compiler (pre-gcc days) and > |> working on a commercial C compiler. I used to moderate the c_language > |> conference on BIX (back when that was a thing). I make my living > |> writing C and C++ code every day. And yet, I had completely forgotten > |> about this quirk. > ... > |In Kib’s defense I think this is commonly mentioned in C99 books (at least > |that’s where I learned of it) so it depends on when and where someone > |learned. There are merits approaches of being explicit or brief. I have > > Nicely said. K&R C 2nd Ed. explicitly uses return(0) many times. We are long after K&R in any of its form. My point was that the example if of very low quality, and return (0); is an indicator. Perhaps even more interesting point to make is the mix of return from main() and exit(3) use in same 4 lines. Besides inconsistency, exit(3) from main() should probably not used in examples or recommended to novices at all. ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r368714 - head/lib/libc/string
Kevin Bowling wrote in : |On Thu, Dec 17, 2020 at 9:33 AM Ian Lepore wrote: |> On Thu, 2020-12-17 at 18:22 +0200, Konstantin Belousov wrote: |>> On Thu, Dec 17, 2020 at 01:01:01PM +, Jessica Clarke wrote: |>>> On 17 Dec 2020, at 12:53, Konstantin Belousov |>>> wrote: | On Thu, Dec 17, 2020 at 12:41:47PM +, Mateusz Piotrowski | wrote: |> Author: 0mp (doc,ports committer) |> Date: Thu Dec 17 12:41:47 2020 |> New Revision: 368714 |> URL: https://svnweb.freebsd.org/changeset/base/368714 ... |> + return (0); | | return (0) is redundand. ... |>> Why it is bad practice ? |>> |>> C is a small language, and while knowing some quirks (like this one) |>> seems to be optional, others are not. And worse, that other quirks are ... |> How obscure is this quirk? I've been writing C code since 1983, |> including having released a freeware compiler (pre-gcc days) and |> working on a commercial C compiler. I used to moderate the c_language |> conference on BIX (back when that was a thing). I make my living |> writing C and C++ code every day. And yet, I had completely forgotten |> about this quirk. ... |In Kib’s defense I think this is commonly mentioned in C99 books (at least |that’s where I learned of it) so it depends on when and where someone |learned. There are merits approaches of being explicit or brief. I have Nicely said. K&R C 2nd Ed. explicitly uses return(0) many times. --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r368714 - head/lib/libc/string
On Thu, Dec 17, 2020 at 9:33 AM Ian Lepore wrote:
> On Thu, 2020-12-17 at 18:22 +0200, Konstantin Belousov wrote:
> > On Thu, Dec 17, 2020 at 01:01:01PM +, Jessica Clarke wrote:
> > > On 17 Dec 2020, at 12:53, Konstantin Belousov
> > > wrote:
> > > >
> > > > On Thu, Dec 17, 2020 at 12:41:47PM +, Mateusz Piotrowski
> > > > wrote:
> > > > > Author: 0mp (doc,ports committer)
> > > > > Date: Thu Dec 17 12:41:47 2020
> > > > > New Revision: 368714
> > > > > URL: https://svnweb.freebsd.org/changeset/base/368714
> > > > >
> > > > > Log:
> > > > > strerror.3: Add an example for perror()
> > > > >
> > > > > This is a nice and quick reference.
> > > > >
> > > > > Reviewed by: jilles, yuripv
> > > > > MFC after: 2 weeks
> > > > > Differential Revision: https://reviews.freebsd.org/D27623
> > > > >
> > > > > Modified:
> > > > > head/lib/libc/string/strerror.3
> > > > >
> > > > > Modified: head/lib/libc/string/strerror.3
> > > > > ===
> > > > > ===
> > > > > --- head/lib/libc/string/strerror.3 Thu Dec 17 03:42:54
> > > > > 2020(r368713)
> > > > > +++ head/lib/libc/string/strerror.3 Thu Dec 17 12:41:47
> > > > > 2020(r368714)
> > > > > @@ -32,7 +32,7 @@
> > > > > .\" @(#)strerror.3 8.1 (Berkeley) 6/9/93
> > > > > .\" $FreeBSD$
> > > > > .\"
> > > > > -.Dd December 7, 2020
> > > > > +.Dd December 17, 2020
> > > > > .Dt STRERROR 3
> > > > > .Os
> > > > > .Sh NAME
> > > > > @@ -170,6 +170,31 @@ The use of these variables is deprecated;
> > > > > or
> > > > > .Fn strerror_r
> > > > > should be used instead.
> > > > > +.Sh EXAMPLES
> > > > > +The following example shows how to use
> > > > > +.Fn perror
> > > > > +to report an error.
> > > > > +.Bd -literal -offset 2n
> > > > > +#include
> > > > > +#include
> > > > > +#include
> > > > > +
> > > > > +int
> > > > > +main(void)
> > > > > +{
> > > > > + int fd;
> > > > > +
> > > > > + if ((fd = open("/nonexistent", O_RDONLY)) == -1) {
> > > > > + perror("open()");
> > > > > + exit(1);
> > > > > + }
> > > > > +printf("File descriptor: %d\en", fd);
> > > >
> > > > This lines is indented with spaces, while other lines have tabs.
> > > >
> > > > > + return (0);
> > > >
> > > > return (0) is redundand.
> > >
> > > It's not required as per the standard, but omitting it is needlessly
> > > obfuscating it and bad practice. C lets you do a whole load of things
> > > that are a bad idea, and whilst this one is harmless, it is nonetheless
> > > confusing to anyone who is not intimately acquainted quirks like this
> > > special case in the standard.
> >
> > Why it is bad practice ?
> >
> > C is a small language, and while knowing some quirks (like this one)
> > seems to be optional, others are not. And worse, that other quirks are
> > essential for writing correct code at all. Consequence is that ignoring
> > details indicates insufficient knowledge of the fundamentals and lowers
> > the trust in the provided suggestion.
>
> I completely disagree. Writing example code where you fail to return a
> value and just fall out the bottom of some function that declares it
> returns an int is just Bad Code. Using some obscure quirk of the
> language as justification for that bad code doesn't help the situation
> at all.
>
> How obscure is this quirk? I've been writing C code since 1983,
> including having released a freeware compiler (pre-gcc days) and
> working on a commercial C compiler. I used to moderate the c_language
> conference on BIX (back when that was a thing). I make my living
> writing C and C++ code every day. And yet, I had completely forgotten
> about this quirk.
>
> Example code shouldn't be used to establish how much more clever you
> are than the reader, it should be as easy to understand as possible.
>
> -- Ian
In Kib’s defense I think this is commonly mentioned in C99 books (at least
that’s where I learned of it) so it depends on when and where someone
learned. There are merits approaches of being explicit or brief. I have
no preference directly but we should probably try to be uniform in our
examples with whatever is most common in the docs already.
>
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r368714 - head/lib/libc/string
On 17 Dec 2020, at 16:22, Konstantin Belousov wrote:
> On Thu, Dec 17, 2020 at 01:01:01PM +, Jessica Clarke wrote:
>> On 17 Dec 2020, at 12:53, Konstantin Belousov wrote:
>>>
>>> On Thu, Dec 17, 2020 at 12:41:47PM +, Mateusz Piotrowski wrote:
Author: 0mp (doc,ports committer)
Date: Thu Dec 17 12:41:47 2020
New Revision: 368714
URL: https://svnweb.freebsd.org/changeset/base/368714
Log:
strerror.3: Add an example for perror()
This is a nice and quick reference.
Reviewed by: jilles, yuripv
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D27623
Modified:
head/lib/libc/string/strerror.3
Modified: head/lib/libc/string/strerror.3
==
--- head/lib/libc/string/strerror.3Thu Dec 17 03:42:54 2020
(r368713)
+++ head/lib/libc/string/strerror.3Thu Dec 17 12:41:47 2020
(r368714)
@@ -32,7 +32,7 @@
.\" @(#)strerror.3 8.1 (Berkeley) 6/9/93
.\" $FreeBSD$
.\"
-.Dd December 7, 2020
+.Dd December 17, 2020
.Dt STRERROR 3
.Os
.Sh NAME
@@ -170,6 +170,31 @@ The use of these variables is deprecated;
or
.Fn strerror_r
should be used instead.
+.Sh EXAMPLES
+The following example shows how to use
+.Fn perror
+to report an error.
+.Bd -literal -offset 2n
+#include
+#include
+#include
+
+int
+main(void)
+{
+ int fd;
+
+ if ((fd = open("/nonexistent", O_RDONLY)) == -1) {
+ perror("open()");
+ exit(1);
+ }
+printf("File descriptor: %d\en", fd);
>>> This lines is indented with spaces, while other lines have tabs.
>>>
+ return (0);
>>> return (0) is redundand.
>>
>> It's not required as per the standard, but omitting it is needlessly
>> obfuscating it and bad practice. C lets you do a whole load of things
>> that are a bad idea, and whilst this one is harmless, it is nonetheless
>> confusing to anyone who is not intimately acquainted quirks like this
>> special case in the standard.
> Why it is bad practice ?
>
> C is a small language, and while knowing some quirks (like this one)
> seems to be optional, others are not. And worse, that other quirks are
> essential for writing correct code at all. Consequence is that ignoring
> details indicates insufficient knowledge of the fundamentals and lowers
> the trust in the provided suggestion.
Small does not mean simple. You admit that the language has quirks you
need to know in order to be able to write correct code, so why should
we confound the problem by forcing people to be aware of additional
optional quirks? This is just another kind of code golfing that
achieves nothing other than confuse some people (how many C courses do
you know of that actually teach you that you can omit the final return
statement from main?) and possibly mask a bug if you meant to return a
non-zero value (generally unlikely as error conditions will be handled
early, but maybe you have a final ret value lying around you meant to
return), when the alternative is just to add a single extra line to be
explicit about what you want. Especially since this is example code, we
should be seeking to provide as simple and clear code as is possible,
though I would not like to see this kind of code enter the base system
either.
Jess
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r368714 - head/lib/libc/string
On Thu, 2020-12-17 at 18:22 +0200, Konstantin Belousov wrote:
> On Thu, Dec 17, 2020 at 01:01:01PM +, Jessica Clarke wrote:
> > On 17 Dec 2020, at 12:53, Konstantin Belousov
> > wrote:
> > >
> > > On Thu, Dec 17, 2020 at 12:41:47PM +, Mateusz Piotrowski
> > > wrote:
> > > > Author: 0mp (doc,ports committer)
> > > > Date: Thu Dec 17 12:41:47 2020
> > > > New Revision: 368714
> > > > URL: https://svnweb.freebsd.org/changeset/base/368714
> > > >
> > > > Log:
> > > > strerror.3: Add an example for perror()
> > > >
> > > > This is a nice and quick reference.
> > > >
> > > > Reviewed by: jilles, yuripv
> > > > MFC after: 2 weeks
> > > > Differential Revision: https://reviews.freebsd.org/D27623
> > > >
> > > > Modified:
> > > > head/lib/libc/string/strerror.3
> > > >
> > > > Modified: head/lib/libc/string/strerror.3
> > > > ===
> > > > ===
> > > > --- head/lib/libc/string/strerror.3 Thu Dec 17 03:42:54
> > > > 2020(r368713)
> > > > +++ head/lib/libc/string/strerror.3 Thu Dec 17 12:41:47
> > > > 2020(r368714)
> > > > @@ -32,7 +32,7 @@
> > > > .\" @(#)strerror.3 8.1 (Berkeley) 6/9/93
> > > > .\" $FreeBSD$
> > > > .\"
> > > > -.Dd December 7, 2020
> > > > +.Dd December 17, 2020
> > > > .Dt STRERROR 3
> > > > .Os
> > > > .Sh NAME
> > > > @@ -170,6 +170,31 @@ The use of these variables is deprecated;
> > > > or
> > > > .Fn strerror_r
> > > > should be used instead.
> > > > +.Sh EXAMPLES
> > > > +The following example shows how to use
> > > > +.Fn perror
> > > > +to report an error.
> > > > +.Bd -literal -offset 2n
> > > > +#include
> > > > +#include
> > > > +#include
> > > > +
> > > > +int
> > > > +main(void)
> > > > +{
> > > > + int fd;
> > > > +
> > > > + if ((fd = open("/nonexistent", O_RDONLY)) == -1) {
> > > > + perror("open()");
> > > > + exit(1);
> > > > + }
> > > > +printf("File descriptor: %d\en", fd);
> > >
> > > This lines is indented with spaces, while other lines have tabs.
> > >
> > > > + return (0);
> > >
> > > return (0) is redundand.
> >
> > It's not required as per the standard, but omitting it is needlessly
> > obfuscating it and bad practice. C lets you do a whole load of things
> > that are a bad idea, and whilst this one is harmless, it is nonetheless
> > confusing to anyone who is not intimately acquainted quirks like this
> > special case in the standard.
>
> Why it is bad practice ?
>
> C is a small language, and while knowing some quirks (like this one)
> seems to be optional, others are not. And worse, that other quirks are
> essential for writing correct code at all. Consequence is that ignoring
> details indicates insufficient knowledge of the fundamentals and lowers
> the trust in the provided suggestion.
I completely disagree. Writing example code where you fail to return a
value and just fall out the bottom of some function that declares it
returns an int is just Bad Code. Using some obscure quirk of the
language as justification for that bad code doesn't help the situation
at all.
How obscure is this quirk? I've been writing C code since 1983,
including having released a freeware compiler (pre-gcc days) and
working on a commercial C compiler. I used to moderate the c_language
conference on BIX (back when that was a thing). I make my living
writing C and C++ code every day. And yet, I had completely forgotten
about this quirk.
Example code shouldn't be used to establish how much more clever you
are than the reader, it should be as easy to understand as possible.
-- Ian
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r368714 - head/lib/libc/string
On Thu, Dec 17, 2020 at 01:01:01PM +, Jessica Clarke wrote:
> On 17 Dec 2020, at 12:53, Konstantin Belousov wrote:
> >
> > On Thu, Dec 17, 2020 at 12:41:47PM +, Mateusz Piotrowski wrote:
> >> Author: 0mp (doc,ports committer)
> >> Date: Thu Dec 17 12:41:47 2020
> >> New Revision: 368714
> >> URL: https://svnweb.freebsd.org/changeset/base/368714
> >>
> >> Log:
> >> strerror.3: Add an example for perror()
> >>
> >> This is a nice and quick reference.
> >>
> >> Reviewed by: jilles, yuripv
> >> MFC after:2 weeks
> >> Differential Revision:https://reviews.freebsd.org/D27623
> >>
> >> Modified:
> >> head/lib/libc/string/strerror.3
> >>
> >> Modified: head/lib/libc/string/strerror.3
> >> ==
> >> --- head/lib/libc/string/strerror.3Thu Dec 17 03:42:54 2020
> >> (r368713)
> >> +++ head/lib/libc/string/strerror.3Thu Dec 17 12:41:47 2020
> >> (r368714)
> >> @@ -32,7 +32,7 @@
> >> .\" @(#)strerror.3 8.1 (Berkeley) 6/9/93
> >> .\" $FreeBSD$
> >> .\"
> >> -.Dd December 7, 2020
> >> +.Dd December 17, 2020
> >> .Dt STRERROR 3
> >> .Os
> >> .Sh NAME
> >> @@ -170,6 +170,31 @@ The use of these variables is deprecated;
> >> or
> >> .Fn strerror_r
> >> should be used instead.
> >> +.Sh EXAMPLES
> >> +The following example shows how to use
> >> +.Fn perror
> >> +to report an error.
> >> +.Bd -literal -offset 2n
> >> +#include
> >> +#include
> >> +#include
> >> +
> >> +int
> >> +main(void)
> >> +{
> >> + int fd;
> >> +
> >> + if ((fd = open("/nonexistent", O_RDONLY)) == -1) {
> >> + perror("open()");
> >> + exit(1);
> >> + }
> >> +printf("File descriptor: %d\en", fd);
> > This lines is indented with spaces, while other lines have tabs.
> >
> >> + return (0);
> > return (0) is redundand.
>
> It's not required as per the standard, but omitting it is needlessly
> obfuscating it and bad practice. C lets you do a whole load of things
> that are a bad idea, and whilst this one is harmless, it is nonetheless
> confusing to anyone who is not intimately acquainted quirks like this
> special case in the standard.
Why it is bad practice ?
C is a small language, and while knowing some quirks (like this one)
seems to be optional, others are not. And worse, that other quirks are
essential for writing correct code at all. Consequence is that ignoring
details indicates insufficient knowledge of the fundamentals and lowers
the trust in the provided suggestion.
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r368714 - head/lib/libc/string
On 17 Dec 2020, at 12:53, Konstantin Belousov wrote:
>
> On Thu, Dec 17, 2020 at 12:41:47PM +, Mateusz Piotrowski wrote:
>> Author: 0mp (doc,ports committer)
>> Date: Thu Dec 17 12:41:47 2020
>> New Revision: 368714
>> URL: https://svnweb.freebsd.org/changeset/base/368714
>>
>> Log:
>> strerror.3: Add an example for perror()
>>
>> This is a nice and quick reference.
>>
>> Reviewed by:jilles, yuripv
>> MFC after: 2 weeks
>> Differential Revision: https://reviews.freebsd.org/D27623
>>
>> Modified:
>> head/lib/libc/string/strerror.3
>>
>> Modified: head/lib/libc/string/strerror.3
>> ==
>> --- head/lib/libc/string/strerror.3 Thu Dec 17 03:42:54 2020
>> (r368713)
>> +++ head/lib/libc/string/strerror.3 Thu Dec 17 12:41:47 2020
>> (r368714)
>> @@ -32,7 +32,7 @@
>> .\" @(#)strerror.3 8.1 (Berkeley) 6/9/93
>> .\" $FreeBSD$
>> .\"
>> -.Dd December 7, 2020
>> +.Dd December 17, 2020
>> .Dt STRERROR 3
>> .Os
>> .Sh NAME
>> @@ -170,6 +170,31 @@ The use of these variables is deprecated;
>> or
>> .Fn strerror_r
>> should be used instead.
>> +.Sh EXAMPLES
>> +The following example shows how to use
>> +.Fn perror
>> +to report an error.
>> +.Bd -literal -offset 2n
>> +#include
>> +#include
>> +#include
>> +
>> +int
>> +main(void)
>> +{
>> +int fd;
>> +
>> +if ((fd = open("/nonexistent", O_RDONLY)) == -1) {
>> +perror("open()");
>> +exit(1);
>> +}
>> +printf("File descriptor: %d\en", fd);
> This lines is indented with spaces, while other lines have tabs.
>
>> +return (0);
> return (0) is redundand.
It's not required as per the standard, but omitting it is needlessly
obfuscating it and bad practice. C lets you do a whole load of things
that are a bad idea, and whilst this one is harmless, it is nonetheless
confusing to anyone who is not intimately acquainted quirks like this
special case in the standard.
Jess
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r368714 - head/lib/libc/string
On Thu, Dec 17, 2020 at 12:41:47PM +, Mateusz Piotrowski wrote:
> Author: 0mp (doc,ports committer)
> Date: Thu Dec 17 12:41:47 2020
> New Revision: 368714
> URL: https://svnweb.freebsd.org/changeset/base/368714
>
> Log:
> strerror.3: Add an example for perror()
>
> This is a nice and quick reference.
>
> Reviewed by:jilles, yuripv
> MFC after: 2 weeks
> Differential Revision: https://reviews.freebsd.org/D27623
>
> Modified:
> head/lib/libc/string/strerror.3
>
> Modified: head/lib/libc/string/strerror.3
> ==
> --- head/lib/libc/string/strerror.3 Thu Dec 17 03:42:54 2020
> (r368713)
> +++ head/lib/libc/string/strerror.3 Thu Dec 17 12:41:47 2020
> (r368714)
> @@ -32,7 +32,7 @@
> .\" @(#)strerror.3 8.1 (Berkeley) 6/9/93
> .\" $FreeBSD$
> .\"
> -.Dd December 7, 2020
> +.Dd December 17, 2020
> .Dt STRERROR 3
> .Os
> .Sh NAME
> @@ -170,6 +170,31 @@ The use of these variables is deprecated;
> or
> .Fn strerror_r
> should be used instead.
> +.Sh EXAMPLES
> +The following example shows how to use
> +.Fn perror
> +to report an error.
> +.Bd -literal -offset 2n
> +#include
> +#include
> +#include
> +
> +int
> +main(void)
> +{
> + int fd;
> +
> + if ((fd = open("/nonexistent", O_RDONLY)) == -1) {
> + perror("open()");
> + exit(1);
> + }
> +printf("File descriptor: %d\en", fd);
This lines is indented with spaces, while other lines have tabs.
> + return (0);
return (0) is redundand.
> +}
> +.Ed
> +.Pp
> +When executed, the program will print an error message along the lines of
> +.Ql "open(): No such file or directory" .
> .Sh SEE ALSO
> .Xr intro 2 ,
> .Xr err 3 ,
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r368714 - head/lib/libc/string
Author: 0mp (doc,ports committer)
Date: Thu Dec 17 12:41:47 2020
New Revision: 368714
URL: https://svnweb.freebsd.org/changeset/base/368714
Log:
strerror.3: Add an example for perror()
This is a nice and quick reference.
Reviewed by: jilles, yuripv
MFC after:2 weeks
Differential Revision:https://reviews.freebsd.org/D27623
Modified:
head/lib/libc/string/strerror.3
Modified: head/lib/libc/string/strerror.3
==
--- head/lib/libc/string/strerror.3 Thu Dec 17 03:42:54 2020
(r368713)
+++ head/lib/libc/string/strerror.3 Thu Dec 17 12:41:47 2020
(r368714)
@@ -32,7 +32,7 @@
.\" @(#)strerror.3 8.1 (Berkeley) 6/9/93
.\" $FreeBSD$
.\"
-.Dd December 7, 2020
+.Dd December 17, 2020
.Dt STRERROR 3
.Os
.Sh NAME
@@ -170,6 +170,31 @@ The use of these variables is deprecated;
or
.Fn strerror_r
should be used instead.
+.Sh EXAMPLES
+The following example shows how to use
+.Fn perror
+to report an error.
+.Bd -literal -offset 2n
+#include
+#include
+#include
+
+int
+main(void)
+{
+ int fd;
+
+ if ((fd = open("/nonexistent", O_RDONLY)) == -1) {
+ perror("open()");
+ exit(1);
+ }
+printf("File descriptor: %d\en", fd);
+ return (0);
+}
+.Ed
+.Pp
+When executed, the program will print an error message along the lines of
+.Ql "open(): No such file or directory" .
.Sh SEE ALSO
.Xr intro 2 ,
.Xr err 3 ,
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
