A NOTE has been added to this issue. ====================================================================== http://austingroupbugs.net/view.php?id=1054 ====================================================================== Reported By: EdSchouten Assigned To: ajosey ====================================================================== Project: 1003.1(2008)/Issue 7 Issue ID: 1054 Category: Base Definitions and Headers Type: Omission Severity: Editorial Priority: normal Status: Under Review Name: Ed Schouten Organization: Nuxi User Reference: Section: stdio.h Page Number: n/a Line Number: n/a Interp Status: --- Final Accepted Text: ====================================================================== Date Submitted: 2016-05-31 09:45 UTC Last Modified: 2017-06-29 15:39 UTC ====================================================================== Summary: stdio.h doesn't allow FILE to be opaque? ======================================================================
---------------------------------------------------------------------- (0003805) eblake (manager) - 2017-06-29 15:39 http://austingroupbugs.net/view.php?id=1054#c3805 ---------------------------------------------------------------------- The gnulib source-code library used in a lot of GNU (and other) software implements several useful extension functions on top of stdio. For example: http://git.savannah.gnu.org/cgit/gnulib.git/tree/lib/fpending.c declares fpending(FILE *fp), which lets an application probe whether a file has unflushed data. Applications using this extension (including various GNU coreutils) can then be written in a more efficient manner. Some libc already offer an __fpending(), which gnulib uses instead of poking into FILE internals; and it may be worth standardizing under the fpending() name (probably as a separate bug report from this one). The gnulib implementation is rather complicated _because_ it pokes at FILE internals, and has to deal with incomplete types on a per-libc basis for how to poke at those internals (there are regularly reports on the gnulib mailing list about yet-another libc that needs porting to provide all of the stdio extensions). So writing such extensions are already quite aware of the non-portability of probing at FILE internals, and making FILE opaque does not (greatly) change the situation. So I'm not opposed to this change; however, we probably want to make sure that we have enough building-blocks on top of stdio (even if it means standardizing some of the gnulib extensions and/or the __f*() counterparts that various BSDs have added to help gnulib write such extensions without probing in FILE guts), so that applications can still access optimizations in a more portable manner. Issue History Date Modified Username Field Change ====================================================================== 2016-05-31 09:45 EdSchouten New Issue 2016-05-31 09:45 EdSchouten Status New => Under Review 2016-05-31 09:45 EdSchouten Assigned To => ajosey 2016-05-31 09:45 EdSchouten Name => Ed Schouten 2016-05-31 09:45 EdSchouten Organization => Nuxi 2016-05-31 09:45 EdSchouten Section => stdio.h 2016-05-31 09:45 EdSchouten Page Number => n/a 2016-05-31 09:45 EdSchouten Line Number => n/a 2016-05-31 10:08 geoffclare Note Added: 0003238 2016-05-31 15:25 shware_systems Note Added: 0003239 2016-05-31 15:40 shware_systems Note Edited: 0003239 2016-05-31 15:54 shware_systems Note Edited: 0003239 2017-06-29 15:39 eblake Note Added: 0003805 ======================================================================
