Re: Hello fdclose
Does this patch allow perl to stop writing to FILE._file? As pointed out
in
http://lists.freebsd.org/pipermail/freebsd-current/2013-January/039024.html
perlio.c in the perl source contains a function
PerlIOStdio_invalidate_fileno() that should modify a FILE such that
fclose() does not close the file descriptor but still frees all memory
(Perl has already called fflush()). Although using fdclose() could solve
this without touching the internals of FILE, this will make perlio.c
uglier with even more #ifdefs.
Yes it should help. I start some work on it but i have some troubles
with perl (I'm not perl hacker :(), so I will try to prepare some
patch for it in the nearest feature. There are some other places also
where we could use it.
[snip]
--- //depot/user/oshogbo/capsicum/lib/libc/stdio/Symbol.map 2013-06-28
08:51:28.0
+++ /home/oshogbo/p4/capsicum/lib/libc/stdio/Symbol.map 2013-06-28
08:51:28.0
@@ -156,6 +156,7 @@
putwc_l;
putwchar_l;
fmemopen;
+ fdclose;
open_memstream;
open_wmemstream;
};
This should be in the FBSD_1.4 namespace (which does not exist yet).
Oh - thx, so this will be good now?
@@ -160,6 +160,10 @@
open_wmemstream;
};
+FBSD_1.4 {
+ fdclose;
+};
+
[snip]
--- //depot/user/oshogbo/capsicum/lib/libc/stdio/fclose.c 2013-06-28
08:51:28.0
+++ /home/oshogbo/p4/capsicum/lib/libc/stdio/fclose.c 2013-06-28
08:51:28.0
[snip]
+int
+fdclose(FILE *fp)
+{
+ int fd, r, err;
+
+ if (fp-_flags == 0) { /* not open! */
+ errno = EBADF;
+ return (EOF);
+ }
+
+ r = 0;
+ FLOCKFILE(fp);
+ fd = fp-_file;
+ if (fp-_close != __sclose) {
+ r = EOF;
+ errno = EOPNOTSUPP;
+ } else if (fd 0) {
+ r = EOF;
+ errno = EBADF;
+ }
+ if (r == EOF) {
+ err = errno;
+ (void)cleanfile(fp, true);
+ errno = err;
+ } else {
+ r = cleanfile(fp, false);
+ }
FUNLOCKFILE(fp);
+
+ return (r == 0 ? fd : r);
If a file descriptor would be returned but cleanfile() returns an error
(e.g. write error on flush), the file descriptor is not returned and not
closed.
I think that in cases where fdclose() would be used, it is essential
that the file descriptor is never closed. This means that the API needs
to be different so it can report a write error but still return a file
descriptor. One way to do this is to return the file descriptor by
reference. Another is to expect the application to call fileno() and not
return the descriptor from the new function.
You have very good point. The first question is where function will
return error:
1* When there is different _close function from std (it will behave
like fclose with some errno)
2* When __sflush fails (and it will free structure)
3* When fd in structure is not correct (it will behave like fclose
with some errno)
I think those assumptions about when close fd are reasonable. When I
wrote this function I discouse this with Pawel, and we decided that if
_close function is different from std we should work same as fclose
function plus return errno about EOPNOTSUPP.
So in my opinion only second point is unwanted by us. So if __sflush
fails we could not return any err (I don't thing this is wanted
solution) or we could return error returned by __sflush and not free
structure. In my opinion last option will be the best one. What you
think Jilles?
In this moment I don't like idea of changing API of this function.
Cheers,
Mariusz
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Hello fdclose
On 22 March 2014 08:04, Kevin Oberman rkober...@gmail.com wrote: On Fri, Mar 21, 2014 at 5:51 PM, Dag-Erling Smørgrav d...@des.no wrote: Warner Losh i...@bsdimp.com writes: It does serve a useful purpose, though, which is why it has endured. If you were to have a man page that said 'Putc(3) returns ...' then the automated tools (and web links) that find Putc.3 wouldn't be able to since it doesn't exist. Moreover - if FreeBSD were written in Pascal, it might not matter, but in C, _exit(2) and _Exit(3) are two different functions. (I'm sure there are other examples without a leading underscore) (eww, starting a sentence with a non-alphabetic character would be even worse...) 3Com was once a very important networking company. 3M still is. /me duck and runs. -- R. Kevin Oberman, Network Engineer, Retired E-mail: rkober...@gmail.com Hello, Thx guys for such big interested of the fdclose function :) When we decide how API will look and how the fdclose function will behave then I will correct man page. Thx, Mariusz ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Hello fdclose
On Tue, Mar 25, 2014 at 11:25:28PM +0100, Mariusz Zaborski wrote:
[snip]
--- //depot/user/oshogbo/capsicum/lib/libc/stdio/Symbol.map 2013-06-28
08:51:28.0
+++ /home/oshogbo/p4/capsicum/lib/libc/stdio/Symbol.map 2013-06-28
08:51:28.0
@@ -156,6 +156,7 @@
putwc_l;
putwchar_l;
fmemopen;
+ fdclose;
open_memstream;
open_wmemstream;
};
This should be in the FBSD_1.4 namespace (which does not exist yet).
Oh - thx, so this will be good now?
@@ -160,6 +160,10 @@
open_wmemstream;
};
+FBSD_1.4 {
+ fdclose;
+};
+
You also need to update the lib/libc/Versions.def file. Look e.g. at
the r226217 for the proper way to introduce new version.
pgp0_xHr6UbB1.pgp
Description: PGP signature
Re: Hello fdclose
+FBSD_1.4 {
+ fdclose;
+};
+
You also need to update the lib/libc/Versions.def file. Look e.g. at
the r226217 for the proper way to introduce new version.
Updated - thank you.
Cheers,
Mariusz
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Hello fdclose
On Fri, Mar 21, 2014 at 5:51 PM, Dag-Erling Smørgrav d...@des.no wrote: Warner Losh i...@bsdimp.com writes: It does serve a useful purpose, though, which is why it has endured. If you were to have a man page that said ‘Putc(3) returns …’ then the automated tools (and web links) that find Putc.3 wouldn’t be able to since it doesn’t exist. Moreover - if FreeBSD were written in Pascal, it might not matter, but in C, _exit(2) and _Exit(3) are two different functions. (I'm sure there are other examples without a leading underscore) (eww, starting a sentence with a non-alphabetic character would be even worse...) 3Com was once a very important networking company. 3M still is. /me duck and runs. -- R. Kevin Oberman, Network Engineer, Retired E-mail: rkober...@gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Hello fdclose
On 03/21/14 20:51, Dag-Erling Smørgrav wrote: Warner Losh i...@bsdimp.com writes: It does serve a useful purpose, though, which is why it has endured. If you were to have a man page that said ‘Putc(3) returns …’ then the automated tools (and web links) that find Putc.3 wouldn’t be able to since it doesn’t exist. Moreover - if FreeBSD were written in Pascal, it might not matter, but in C, _exit(2) and _Exit(3) are two different functions. (I'm sure there are other examples without a leading underscore) (eww, starting a sentence with a non-alphabetic character would be even worse...) DES Etc., etc., etc. Wouldn't it be more productive to spend this effort on recasting the sentence in question so that it doesn't start with a word that starts with a small letter? -- George ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Hello fdclose
The call to Done. Moving on! -a On 22 March 2014 06:40, George Mitchell george+free...@m5p.com wrote: On 03/21/14 20:51, Dag-Erling Smørgrav wrote: Warner Losh i...@bsdimp.com writes: It does serve a useful purpose, though, which is why it has endured. If you were to have a man page that said 'Putc(3) returns ...' then the automated tools (and web links) that find Putc.3 wouldn't be able to since it doesn't exist. Moreover - if FreeBSD were written in Pascal, it might not matter, but in C, _exit(2) and _Exit(3) are two different functions. (I'm sure there are other examples without a leading underscore) (eww, starting a sentence with a non-alphabetic character would be even worse...) DES Etc., etc., etc. Wouldn't it be more productive to spend this effort on recasting the sentence in question so that it doesn't start with a word that starts with a small letter? -- George ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Hello fdclose
Hello, I'm using as MUA the famous 'mutt' and from time to time I'm missing a feature in 'mutt': mark a thread as unwanted to present any new messages in this thread. This is one I would mark for this. Thanks matthias -- Sent from my FreeBSD netbook Matthias Apitz, g...@unixarea.de, http://www.unixarea.de/ f: +49-170-4527211 UNIX since V7 on PDP-11, UNIX on mainframe since ESER 1055 (IBM /370) UNIX on x86 since SVR4.2 UnixWare 2.1.2, FreeBSD since 2.2.5 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Hello fdclose
On Thu, 20 Mar 2014, Dag-Erling Smørgrav wrote: Warren Block wbl...@wonkity.com writes: John Baldwin j...@freebsd.org writes: Warren Block wbl...@wonkity.com writes: .Fn fdclose is equivalent to .Fn fclose , but the file descriptor is returned rather than closed. Yes, but this has the 'no capital letter at the start of a sentence' problem. I've heard that mentioned before, but have never seen any actual rule regarding it. And we do have actual rules about avoiding redundant phrases: http://www.freebsd.org/doc/en_US.ISO8859-1/books/fdp-primer/book.html#writing-style-guidelines We always use The .Nm foo utility or The .Fn foo function instead of just .Nm or .Fn at the start of a sentence, but never (or rarely) within a sentence. By we, do you mean the FreeBSD project or your local organization? Is there a specific reason the redundant wording, or is it just customary? I suspect that usage is similar to that for an acronym, defining it on the first usage but only then. Both mdoc and DocBook markup should accomplish the same thing. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Hello fdclose
Warren Block wbl...@wonkity.com writes: Dag-Erling Smørgrav d...@des.no writes: We always use [The .Nm foo utility or The .Fn foo function] instead of just .Nm or .Fn at the start of a sentence, but never (or rarely) within a sentence. By we, do you mean the FreeBSD project or your local organization? Is there a specific reason the redundant wording, or is it just customary? I mean the FreeBSD project, and the reason is as John stated: all sentences must start with a capital letter. I've gotten so used to this over the past 15 years that I even do it in email and other non-FreeBSD written material. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Hello fdclose
On Mar 21, 2014, at 8:18 AM, Dag-Erling Smørgrav d...@des.no wrote: Warren Block wbl...@wonkity.com writes: Dag-Erling Smørgrav d...@des.no writes: We always use [The .Nm foo utility or The .Fn foo function] instead of just .Nm or .Fn at the start of a sentence, but never (or rarely) within a sentence. By we, do you mean the FreeBSD project or your local organization? Is there a specific reason the redundant wording, or is it just customary? I mean the FreeBSD project, and the reason is as John stated: all sentences must start with a capital letter. I've gotten so used to this over the past 15 years that I even do it in email and other non-FreeBSD written material. Yes, it is style that was settled upon 15 years ago or so in the FreeBSD project. Even more than finding myself using this in email, etc, I find that when I see people using other conventions it just looks wrong to my eyes. Warner ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Hello fdclose
On Fri, 21 Mar 2014, Dag-Erling Smørgrav wrote: Warren Block wbl...@wonkity.com writes: Dag-Erling Smørgrav d...@des.no writes: We always use [The .Nm foo utility or The .Fn foo function] instead of just .Nm or .Fn at the start of a sentence, but never (or rarely) within a sentence. By we, do you mean the FreeBSD project or your local organization? Is there a specific reason the redundant wording, or is it just customary? I mean the FreeBSD project, and the reason is as John stated: all sentences must start with a capital letter. I've gotten so used to this over the past 15 years that I even do it in email and other non-FreeBSD written material. DES Because it's been that way for 15 years is not always a justification (consider BIND in base, for example :). I'll let this drop for now, but still find it interesting that it is not mentioned in the FDP Primer, and those style guide rules date back at least 15 years. It may be that the original doc project members felt that capitalizing the first word of a sentence was so obvious that it did not need to be stated. Or possibly, that it was a rule that could be usefully broken at times. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Hello fdclose
Warren Block wbl...@wonkity.com writes: Dag-Erling Smørgrav d...@des.no writes: I mean the FreeBSD project, and the reason is as John stated: all sentences must start with a capital letter. I've gotten so used to this over the past 15 years that I even do it in email and other non-FreeBSD written material. Because it's been that way for 15 years is not always a justification (consider BIND in base, for example :). I don't like your answer, so I will ignore it is not a justification either. It's kindergarden behavior and beneath the dignity of a FreeBSD committer. We have a rule that sentences must always start with a capital letter. The fact that this rule was instituted 15 years ago does not automatically invalidate it, and neither does the fact that Joe Random Committer disagrees with it. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Hello fdclose
On Fri, 2014-03-21 at 17:54 +0100, Dag-Erling Smørgrav wrote: Warren Block wbl...@wonkity.com writes: Dag-Erling Smørgrav d...@des.no writes: I mean the FreeBSD project, and the reason is as John stated: all sentences must start with a capital letter. I've gotten so used to this over the past 15 years that I even do it in email and other non-FreeBSD written material. Because it's been that way for 15 years is not always a justification (consider BIND in base, for example :). I don't like your answer, so I will ignore it is not a justification either. It's kindergarden behavior and beneath the dignity of a FreeBSD committer. We have a rule that sentences must always start with a capital letter. The fact that this rule was instituted 15 years ago does not automatically invalidate it, and neither does the fact that Joe Random Committer disagrees with it. DES Just as the age of a moronic rule such as this doesn't in any way justify the idea that it could never be changed. Especially when the rule appears to be an undocumented prejudice. People love to throw around assertions about rules of the English language. It doesn't have many rules (subject has to agree in number with the verb, that's about it for unbreakable rules), but it has as many opinions on proper style as there are readers and writers. -- Ian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Hello fdclose
On Mar 21, 2014, at 11:20 AM, Ian Lepore i...@freebsd.org wrote: On Fri, 2014-03-21 at 17:54 +0100, Dag-Erling Smørgrav wrote: Warren Block wbl...@wonkity.com writes: Dag-Erling Smørgrav d...@des.no writes: I mean the FreeBSD project, and the reason is as John stated: all sentences must start with a capital letter. I've gotten so used to this over the past 15 years that I even do it in email and other non-FreeBSD written material. Because it's been that way for 15 years is not always a justification (consider BIND in base, for example :). I don't like your answer, so I will ignore it is not a justification either. It's kindergarden behavior and beneath the dignity of a FreeBSD committer. We have a rule that sentences must always start with a capital letter. The fact that this rule was instituted 15 years ago does not automatically invalidate it, and neither does the fact that Joe Random Committer disagrees with it. DES Just as the age of a moronic rule such as this doesn't in any way justify the idea that it could never be changed. Especially when the rule appears to be an undocumented prejudice. It has been the way things have been for a long time, and everybody that has been writing man pages in the project for any length of time knows it. Ruslan was especially good about fixing this issue back in the day. This rule was hashed out and there’s really no compelling reason to change it. Unlike BIND, we have had no complaints about it in the almost two decades it has been around… It does serve a useful purpose, though, which is why it has endured. If you were to have a man page that said ‘Putc(3) returns …’ then the automated tools (and web links) that find Putc.3 wouldn’t be able to since it doesn’t exist. People love to throw around assertions about rules of the English language. It doesn't have many rules (subject has to agree in number with the verb, that's about it for unbreakable rules), but it has as many opinions on proper style as there are readers and writers. This is the proper style for FreeBSD man page, by convention. It is so basic that it doesn’t surprise me it isn’t in the docs, but it also surprises me that it isn’t. There’s numerous instances of this rule being mentioned in commit messages: http://lists.freebsd.org/pipermail/cvs-doc/2008-February/017562.html http://osdir.com/ml/os.freebsd.devel.cvs.doc/2004-07/msg00284.html http://blog.gmane.org/gmane.os.freebsd.devel.documentation/month=20050201/page=6 or the discussions in the archives like: http://osdir.com/ml/freebsd.devel.documentation/2002-05/msg00589.html http://markmail.org/thread/jx2jr5myngp5jg5d#query:+page:1+mid:lasvnzqoojxfeoet+state:results or a few other places. These discussions span the last 15 years (the oldest one is 1999, but the convention is easily a few years older than that). Warner ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Hello fdclose
Ian Lepore i...@freebsd.org writes: Just as the age of a moronic rule such as this doesn't in any way justify the idea that it could never be changed. I never claimed it did, but I can see how it would be convenient to pretend that I did so you can attack that instead of discussing the actual issue. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Hello fdclose
Warner Losh i...@bsdimp.com writes: It does serve a useful purpose, though, which is why it has endured. If you were to have a man page that said ‘Putc(3) returns …’ then the automated tools (and web links) that find Putc.3 wouldn’t be able to since it doesn’t exist. Moreover - if FreeBSD were written in Pascal, it might not matter, but in C, _exit(2) and _Exit(3) are two different functions. (I'm sure there are other examples without a leading underscore) (eww, starting a sentence with a non-alphabetic character would be even worse...) DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Hello fdclose
On Tuesday, March 18, 2014 5:35:16 pm Jilles Tjoelker wrote: On Tue, Mar 18, 2014 at 12:23:19AM +0100, Mariusz Zaborski wrote: After our previous discuss [1] I prepare fdclosedir(3) function which was committed by Pawel (cc'ed) in commit r254499. A while ago I also prepare the fdclose function. Unfortunately, this new function is a little bit more tricky then previous one. Can I ask you for a review of this patch? Does this patch allow perl to stop writing to FILE._file? As pointed out in http://lists.freebsd.org/pipermail/freebsd-current/2013-January/039024.html perlio.c in the perl source contains a function PerlIOStdio_invalidate_fileno() that should modify a FILE such that fclose() does not close the file descriptor but still frees all memory (Perl has already called fflush()). Although using fdclose() could solve this without touching the internals of FILE, this will make perlio.c uglier with even more #ifdefs. I hope it does. I want to have some sort of API for Perl to use so it stops (ab)using _file before I move forward with full int _file. I think that in cases where fdclose() would be used, it is essential that the file descriptor is never closed. This means that the API needs to be different so it can report a write error but still return a file descriptor. One way to do this is to return the file descriptor by reference. Another is to expect the application to call fileno() and not return the descriptor from the new function. I would prefer the latter of requiring the application to use fileno(). -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Hello fdclose
On Wednesday, March 19, 2014 4:28:15 pm Warren Block wrote: On Wed, 19 Mar 2014, John Baldwin wrote: On Wednesday, March 19, 2014 12:38:57 am Warren Block wrote: On Tue, 18 Mar 2014, John Baldwin wrote: On Monday, March 17, 2014 7:23:19 pm Mariusz Zaborski wrote: Hi, After our previous discuss [1] I prepare fdclosedir(3) function which was committed by Pawel (cc'ed) in commit r254499. A while ago I also prepare the fdclose function. Unfortunately, this new function is a little bit more tricky then previous one. Can I ask you for a review of this patch? I think the code is fine. I have a few suggestions on the manpage wording: The +.Fn fdclose +function is equivalent to the +.Fn fclose +function except that this function returns file descriptor instead of +closing it. +.Pp +The I would move fdclose() to its own paragraph and reword this sentence as: The fdclose() function is equivalent to fclose() except that it does not close the underlying file descriptor. .Fn fdclose is equivalent to .Fn fclose , but the file descriptor is returned rather than closed. Likewise in other sections, the markup is supposed to do the job of pointing out that something is a function. Yes, but this has the 'no capital letter at the start of a sentence' problem. I've heard that mentioned before, but have never seen any actual rule regarding it. All of my rules for that come from elementary school. :) -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Hello fdclose
Warren Block wbl...@wonkity.com writes: John Baldwin j...@freebsd.org writes: Warren Block wbl...@wonkity.com writes: .Fn fdclose is equivalent to .Fn fclose , but the file descriptor is returned rather than closed. Yes, but this has the 'no capital letter at the start of a sentence' problem. I've heard that mentioned before, but have never seen any actual rule regarding it. And we do have actual rules about avoiding redundant phrases: http://www.freebsd.org/doc/en_US.ISO8859-1/books/fdp-primer/book.html#writing-style-guidelines We always use The .Nm foo utility or The .Fn foo function instead of just .Nm or .Fn at the start of a sentence, but never (or rarely) within a sentence. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Hello fdclose
On Wednesday, March 19, 2014 12:38:57 am Warren Block wrote: On Tue, 18 Mar 2014, John Baldwin wrote: On Monday, March 17, 2014 7:23:19 pm Mariusz Zaborski wrote: Hi, After our previous discuss [1] I prepare fdclosedir(3) function which was committed by Pawel (cc'ed) in commit r254499. A while ago I also prepare the fdclose function. Unfortunately, this new function is a little bit more tricky then previous one. Can I ask you for a review of this patch? I think the code is fine. I have a few suggestions on the manpage wording: The +.Fn fdclose +function is equivalent to the +.Fn fclose +function except that this function returns file descriptor instead of +closing it. +.Pp +The I would move fdclose() to its own paragraph and reword this sentence as: The fdclose() function is equivalent to fclose() except that it does not close the underlying file descriptor. .Fn fdclose is equivalent to .Fn fclose , but the file descriptor is returned rather than closed. Likewise in other sections, the markup is supposed to do the job of pointing out that something is a function. Yes, but this has the 'no capital letter at the start of a sentence' problem. Also, I do think reusing the 'underlying file descriptor' language is important in the context of the earlier description of fclose(). -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Hello fdclose
On Wed, 19 Mar 2014, John Baldwin wrote: On Wednesday, March 19, 2014 12:38:57 am Warren Block wrote: On Tue, 18 Mar 2014, John Baldwin wrote: On Monday, March 17, 2014 7:23:19 pm Mariusz Zaborski wrote: Hi, After our previous discuss [1] I prepare fdclosedir(3) function which was committed by Pawel (cc'ed) in commit r254499. A while ago I also prepare the fdclose function. Unfortunately, this new function is a little bit more tricky then previous one. Can I ask you for a review of this patch? I think the code is fine. I have a few suggestions on the manpage wording: The +.Fn fdclose +function is equivalent to the +.Fn fclose +function except that this function returns file descriptor instead of +closing it. +.Pp +The I would move fdclose() to its own paragraph and reword this sentence as: The fdclose() function is equivalent to fclose() except that it does not close the underlying file descriptor. .Fn fdclose is equivalent to .Fn fclose , but the file descriptor is returned rather than closed. Likewise in other sections, the markup is supposed to do the job of pointing out that something is a function. Yes, but this has the 'no capital letter at the start of a sentence' problem. I've heard that mentioned before, but have never seen any actual rule regarding it. And we do have actual rules about avoiding redundant phrases: http://www.freebsd.org/doc/en_US.ISO8859-1/books/fdp-primer/book.html#writing-style-guidelines While normal words should be capitalized as the first word in a sentence, special words that are case-sensitive override that (IMO). Also, I do think reusing the 'underlying file descriptor' language is important in the context of the earlier description of fclose(). Sorry, a problem with my micro-optimization: .Fn fdclose is equivalent to .Fn fclose , but does not close the underlying file descriptor. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Hello fdclose
On Monday, March 17, 2014 7:23:19 pm Mariusz Zaborski wrote: Hi, After our previous discuss [1] I prepare fdclosedir(3) function which was committed by Pawel (cc'ed) in commit r254499. A while ago I also prepare the fdclose function. Unfortunately, this new function is a little bit more tricky then previous one. Can I ask you for a review of this patch? I think the code is fine. I have a few suggestions on the manpage wording: The +.Fn fdclose +function is equivalent to the +.Fn fclose +function except that this function returns file descriptor instead of +closing it. +.Pp +The I would move fdclose() to its own paragraph and reword this sentence as: The fdclose() function is equivalent to fclose() except that it does not close the underlying file descriptor. .Sh RETURN VALUES -Upon successful completion 0 is returned. +The +.Fn fcloseall +function return no value. +.Pp +Upon successful completion +.Fn fclose +return 0. +Otherwise, +.Dv EOF +is returned and the global variable +.Va errno +is set to indicate the error. +.Pp +The +.Fn fdclose +function return the file descriptor if successfull. Otherwise, .Dv EOF One of English's arcane rules is that most verbs append an 's' when used with singular subjects, so function returns shoud be used instead of function return, etc. I do think for this section it would be good to combine the descriptions of fclose() and fdclose() when possible, so perhaps something like: The fcloseall() function returns no value. Upon successful completion, fclose() returns 0 and fdclose() returns the file descriptor of the underlying file. Otherwise, EOF is returned and the global variable errno is set to indicate the error. In either case no further access to the stream is possible. This allows in either case to still read correctly and makes it clear it applies to both fclose() and fdclose(). .Sh ERRORS +.Bl -tag -width Er +.It Bq Er EOPNOTSUPP The +.Fa _close +method in +.Fa stream +argument to +.Fn fdclose , +was not default. +.It Bq Er EBADF +The +.Fa stream +argument to +.Fn fdclose , +does not contains valid file descriptor. +.El +.Pp +The .Fn fclose -function +and +.Fn fdclose +functions may also fail and set .Va errno For the errors section, the first error list needs some sort of introductory text. Also, this shouldn't claim that fdclose() can return an errno value for close(2). ERRORS The fdclose() function may will fail if: [EOPNOTSUPP] The stream to close uses a non-default close method. [EBADF]The stream is not backed by a valid file descriptor. The fclose() and fdclose() functions may also fail and set errno for any of the errors specified for fflush(3). The fclose() functino may also fail and set errno for any of the errors specified for close(2). @@ -84,7 +130,9 @@ .Sh NOTES The .Fn fclose -function +and +.Fn fdclose +functions does not handle NULL arguments; they will result in a segmentation violation. This is intentional - it makes it easier to make sure programs written do not handle. -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Hello fdclose
On Tue, Mar 18, 2014 at 12:23:19AM +0100, Mariusz Zaborski wrote:
After our previous discuss [1] I prepare fdclosedir(3) function which
was committed by Pawel (cc'ed) in commit r254499.
A while ago I also prepare the fdclose function. Unfortunately, this
new function is a little bit more tricky then previous one. Can I ask
you for a review of this patch?
Does this patch allow perl to stop writing to FILE._file? As pointed out
in
http://lists.freebsd.org/pipermail/freebsd-current/2013-January/039024.html
perlio.c in the perl source contains a function
PerlIOStdio_invalidate_fileno() that should modify a FILE such that
fclose() does not close the file descriptor but still frees all memory
(Perl has already called fflush()). Although using fdclose() could solve
this without touching the internals of FILE, this will make perlio.c
uglier with even more #ifdefs.
[snip]
--- //depot/user/oshogbo/capsicum/lib/libc/stdio/Symbol.map 2013-06-28
08:51:28.0
+++ /home/oshogbo/p4/capsicum/lib/libc/stdio/Symbol.map 2013-06-28
08:51:28.0
@@ -156,6 +156,7 @@
putwc_l;
putwchar_l;
fmemopen;
+ fdclose;
open_memstream;
open_wmemstream;
};
This should be in the FBSD_1.4 namespace (which does not exist yet).
[snip]
--- //depot/user/oshogbo/capsicum/lib/libc/stdio/fclose.c 2013-06-28
08:51:28.0
+++ /home/oshogbo/p4/capsicum/lib/libc/stdio/fclose.c 2013-06-28
08:51:28.0
[snip]
+int
+fdclose(FILE *fp)
+{
+ int fd, r, err;
+
+ if (fp-_flags == 0) { /* not open! */
+ errno = EBADF;
+ return (EOF);
+ }
+
+ r = 0;
+ FLOCKFILE(fp);
+ fd = fp-_file;
+ if (fp-_close != __sclose) {
+ r = EOF;
+ errno = EOPNOTSUPP;
+ } else if (fd 0) {
+ r = EOF;
+ errno = EBADF;
+ }
+ if (r == EOF) {
+ err = errno;
+ (void)cleanfile(fp, true);
+ errno = err;
+ } else {
+ r = cleanfile(fp, false);
+ }
FUNLOCKFILE(fp);
+
+ return (r == 0 ? fd : r);
If a file descriptor would be returned but cleanfile() returns an error
(e.g. write error on flush), the file descriptor is not returned and not
closed.
I think that in cases where fdclose() would be used, it is essential
that the file descriptor is never closed. This means that the API needs
to be different so it can report a write error but still return a file
descriptor. One way to do this is to return the file descriptor by
reference. Another is to expect the application to call fileno() and not
return the descriptor from the new function.
--
Jilles Tjoelker
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Hello fdclose
On Tue, 18 Mar 2014, John Baldwin wrote: On Monday, March 17, 2014 7:23:19 pm Mariusz Zaborski wrote: ... I think the code is fine. I have a few suggestions on the manpage wording: .Sh RETURN VALUES -Upon successful completion 0 is returned. +The +.Fn fcloseall +function return no value. +.Pp +Upon successful completion +.Fn fclose +return 0. +Otherwise, +.Dv EOF +is returned and the global variable +.Va errno +is set to indicate the error. The .Rv macro should be used whenever possible. Unfortunately, it doesn't support the EOF return, but only -1, so stdio man pages can rarely use it, and this one is no exception. Using it gives standard wording that is quite different from the above: standard wording: The close() function returns the value 0 if successful; otherwise the value -1 is returned and the global variable errno is set to indicate the error. above wording (previous): Upon successful completion 0 is returned.Otherwise, EOF is returned and the global variable errno is set to indicate the error. above wording (new): Upon successful completion fclose() return [sic] 0. Otherwise, EOF is returned and the global variable errno is set to indicate the error. These are excessively formal in different ways: - I don't like the foo() function. Why not just foo()? The standard wording uses this, and so does the new wording, but the previous wording omits the function name (that only works for man pages that only have a single function, as they should). - I don't like the value N. Why not just N? The standard wording uses this, but the previous and new wordings don't. - returns N is better than N is returned. Some man pages use worse wordings like N will be returned. - the global variable errno is excessively detailed/verbose, without the details even being correct. Why not just errno, with this identifier documented elsewhere? errno isn't a global variable in most implementations. It is can be, and usually is, a macro that expands to a modifiable lvalue of type int. In FreeBSD, the macro expands to a function that returns a pointer to int. - Upon sucessful completion is correct but verbose. The standard wording doesn't even use it. - the standard wording uses a conjunction instead of a new sentence before otherwise (this is better). It is missing a comma after otherwise (this is worse). +.Pp +The +.Fn fdclose +function return the file descriptor if successfull. Otherwise, .Dv EOF successfull is consistently misspelled. One of English's arcane rules is that most verbs append an 's' when used with singular subjects, so function returns shoud be used instead of function return, etc. I do think for this section it would be good to combine the descriptions of fclose() and fdclose() when possible, so perhaps something like: The fcloseall() function returns no value. Upon successful completion, fclose() returns 0 and fdclose() returns the file descriptor of the underlying file. Otherwise, EOF is returned and the global variable errno is set to indicate the error. In either case no further access to the stream is possible. OK. You kept return[s] N and and deverbosified the foo() function. Upon successful completion is needed more with several functions. the global variable errno remains consistently bad. There should be a comma after In either case. This allows in either case to still read correctly and makes it clear it applies to both fclose() and fdclose(). Better In every case. .Sh ERRORS +.Bl -tag -width Er +.It Bq Er EOPNOTSUPP The +.Fa _close +method in +.Fa stream +argument to +.Fn fdclose , +was not default. +.It Bq Er EBADF The ERRORS section should be sorted. For the errors section, the first error list needs some sort of introductory text. Also, this shouldn't claim that fdclose() can return an errno value for close(2). ERRORS The fdclose() function may will fail if: I don't like the tense given by will in man pages. POSIX says shall fail in similar contexts, and will fail is a mistranslation of this (shall is a technical term that doesn't suggest future tense). deshallify.sh does the not-incorrect translation s/shall fail/fails/ (I think this is too simple to always work). It doesn't translate anything to will. I can't parse may will :-). deshallify.txt doesn't translate may or should to anything (these are also technical terms in some contexts, so they might need translation. IIRC, may is optional behaviour, mostly for the implementation, while shall is required behaviour, only for the implementation, but should is recommended practice, mostly for applications). Man pages are very unlikely to be as consistent as POSIX with these terms. [EOPNOTSUPP] The stream to close uses a non-default close method. [EBADF]The stream is not backed by a valid file descriptor. The fclose() and fdclose() functions may also fail and
Re: Hello fdclose
On Tue, 18 Mar 2014, John Baldwin wrote: On Monday, March 17, 2014 7:23:19 pm Mariusz Zaborski wrote: Hi, After our previous discuss [1] I prepare fdclosedir(3) function which was committed by Pawel (cc'ed) in commit r254499. A while ago I also prepare the fdclose function. Unfortunately, this new function is a little bit more tricky then previous one. Can I ask you for a review of this patch? I think the code is fine. I have a few suggestions on the manpage wording: The +.Fn fdclose +function is equivalent to the +.Fn fclose +function except that this function returns file descriptor instead of +closing it. +.Pp +The I would move fdclose() to its own paragraph and reword this sentence as: The fdclose() function is equivalent to fclose() except that it does not close the underlying file descriptor. .Fn fdclose is equivalent to .Fn fclose , but the file descriptor is returned rather than closed. Likewise in other sections, the markup is supposed to do the job of pointing out that something is a function. textproc/igor can identify some problems with wording. It also checks for rudimentary mdoc(7) requirements. If desired, I'm willing to edit this man page. (I've learned far too recently that most people do not want to be consulted on wording, they just want it fixed. That's now the approach I take: make all the corrections and return it, rather than a back-and-forth with the danger of edit fatigue.) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Hello fdclose
Hi,
After our previous discuss [1] I prepare fdclosedir(3) function which
was committed by Pawel (cc'ed) in commit r254499.
A while ago I also prepare the fdclose function. Unfortunately, this
new function is a little bit more tricky then previous one. Can I ask
you for a review of this patch?
Thanks,
Mariusz
[1] http://lists.freebsd.org/pipermail/freebsd-arch/2013-August/014688.html
--- //depot/user/oshogbo/capsicum/include/stdio.h 2013-06-28 08:51:28.0
+++ /home/oshogbo/p4/capsicum/include/stdio.h 2013-06-28 08:51:28.0
@@ -396,6 +396,7 @@
int asprintf(char **, const char *, ...) __printflike(2, 3);
char *ctermid_r(char *);
void fcloseall(void);
+int fdclose(FILE *);
char *fgetln(FILE *, size_t *);
const char *fmtcheck(const char *, const char *) __format_arg(2);
int fpurge(FILE *);
--- //depot/user/oshogbo/capsicum/lib/libc/stdio/Symbol.map 2013-06-28 08:51:28.0
+++ /home/oshogbo/p4/capsicum/lib/libc/stdio/Symbol.map 2013-06-28 08:51:28.0
@@ -156,6 +156,7 @@
putwc_l;
putwchar_l;
fmemopen;
+ fdclose;
open_memstream;
open_wmemstream;
};
--- //depot/user/oshogbo/capsicum/lib/libc/stdio/fclose.3 2013-06-28 08:51:28.0
+++ /home/oshogbo/p4/capsicum/lib/libc/stdio/fclose.3 2013-06-28 08:51:28.0
@@ -1,5 +1,6 @@
-.\ Copyright (c) 1990, 1991, 1993
-.\ The Regents of the University of California. All rights reserved.
+.\ Copyright (c) 1990, 1991, 1993 The Regents of the University of California.
+.\ Copyright (c) 2014 Mariusz Zaborski osho...@freebsd.org
+.\ All rights reserved.
.\
.\ This code is derived from software contributed to Berkeley by
.\ Chris Torek and the American National Standards Committee X3,
@@ -32,11 +33,12 @@
.\ @(#)fclose.3 8.1 (Berkeley) 6/4/93
.\ $FreeBSD: head/lib/libc/stdio/fclose.3 165903 2007-01-09 00:28:16Z imp $
.\
-.Dd April 22, 2006
+.Dd March 17, 2014
.Dt FCLOSE 3
.Os
.Sh NAME
.Nm fclose ,
+.Nm fdclose ,
.Nm fcloseall
.Nd close a stream
.Sh LIBRARY
@@ -45,6 +47,8 @@
.In stdio.h
.Ft int
.Fn fclose FILE *stream
+.Ft int
+.Fn fdclose FILE *stream
.Ft void
.Fn fcloseall void
.Sh DESCRIPTION
@@ -59,22 +63,64 @@
.Xr fflush 3 .
.Pp
The
+.Fn fdclose
+function is equivalent to the
+.Fn fclose
+function except that this function returns file descriptor instead of
+closing it.
+.Pp
+The
.Fn fcloseall
function calls
.Fn fclose
on all open streams.
.Sh RETURN VALUES
-Upon successful completion 0 is returned.
+The
+.Fn fcloseall
+function return no value.
+.Pp
+Upon successful completion
+.Fn fclose
+return 0.
+Otherwise,
+.Dv EOF
+is returned and the global variable
+.Va errno
+is set to indicate the error.
+.Pp
+The
+.Fn fdclose
+function return the file descriptor if successfull.
Otherwise,
.Dv EOF
is returned and the global variable
.Va errno
is set to indicate the error.
+.Pp
In either case no further access to the stream is possible.
.Sh ERRORS
+.Bl -tag -width Er
+.It Bq Er EOPNOTSUPP
The
+.Fa _close
+method in
+.Fa stream
+argument to
+.Fn fdclose ,
+was not default.
+.It Bq Er EBADF
+The
+.Fa stream
+argument to
+.Fn fdclose ,
+does not contains valid file descriptor.
+.El
+.Pp
+The
.Fn fclose
-function
+and
+.Fn fdclose
+functions
may also fail and set
.Va errno
for any of the errors specified for the routines
@@ -84,7 +130,9 @@
.Sh NOTES
The
.Fn fclose
-function
+and
+.Fn fdclose
+functions
does not handle NULL arguments; they will result in a segmentation
violation.
This is intentional - it makes it easier to make sure programs written
@@ -104,8 +152,13 @@
function
conforms to
.St -isoC .
-.Pp
+.Sh History
The
.Fn fcloseall
function first appeared in
.Fx 7.0 .
+.Pp
+The
+.Fn fdclose
+function first appeared in
+.Fx 11.0 .
--- //depot/user/oshogbo/capsicum/lib/libc/stdio/fclose.c 2013-06-28 08:51:28.0
+++ /home/oshogbo/p4/capsicum/lib/libc/stdio/fclose.c 2013-06-28 08:51:28.0
@@ -1,6 +1,7 @@
/*-
- * Copyright (c) 1990, 1993
- * The Regents of the University of California. All rights reserved.
+ * Copyright (c) 1990, 1993 The Regents of the University of California.
+ * Copyright (c) 2014 Mariusz Zaborski osho...@freebsd.org
+ * All rights reserved.
*
* This code is derived from software contributed to Berkeley by
* Chris Torek.
@@ -38,6 +39,7 @@
#include namespace.h
#include errno.h
+#include stdbool.h
#include stdio.h
#include stdlib.h
#include un-namespace.h
@@ -45,19 +47,17 @@
#include libc_private.h
#include local.h
-int
-fclose(FILE *fp)
+static int
+cleanfile(FILE *fp, bool c)
{
int r;
- if (fp-_flags == 0) { /* not open! */
- errno = EBADF;
- return (EOF);
+ r = fp-_flags __SWR ? __sflush(fp) : 0;
+ if (c) {
+ if (fp-_close != NULL (*fp-_close)(fp-_cookie) 0)
+ r = EOF;
}
- FLOCKFILE(fp);
- r = fp-_flags __SWR ? __sflush(fp) : 0;
- if (fp-_close != NULL (*fp-_close)(fp-_cookie) 0)
- r = EOF;
+
if (fp-_flags __SMBF)
free((char *)fp-_bf._base);
if
