Bug 205029 - [exp-run] Hide most of stdio's FILE object
Summary: [exp-run] Hide most of stdio's FILE object
Status: In Progress
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Ports Framework (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: John Baldwin
URL:
Keywords:
Depends on: 205230
Blocks: 172332
  Show dependency treegraph
 
Reported: 2015-12-04 23:01 UTC by John Baldwin
Modified: 2018-02-01 19:09 UTC (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description John Baldwin freebsd_committer freebsd_triage 2015-12-04 23:01:11 UTC
I think I'd like to take a different approach to expanding _file in FILE to an int, and as the first step I'd like to "hide" most of FILE from outside of libc to prevent applications from accessing FILE internals without jumping through hoops.

To that end, please run an exp-run of the patch at the URL below.  I've done my own runtime tests of it (kyua run of /usr/tests), but it would be good to ensure this doesn't break ports.

https://github.com/freebsd/freebsd/compare/master...bsdjhb:stdio_file.patch
Comment 1 Antoine Brodin freebsd_committer 2015-12-06 11:02:35 UTC
The patch is identical to the one that was exp-ran in october,  is it normal?
Comment 2 John Baldwin freebsd_committer freebsd_triage 2015-12-07 17:30:57 UTC
Bah, the URL is wrong.  It should be s/file/hide/:

https://github.com/freebsd/freebsd/compare/master...bsdjhb:stdio_hide.patch
Comment 3 Antoine Brodin freebsd_committer 2015-12-09 08:25:54 UTC
Exp-run results:

http://package18.nyi.freebsd.org/jail.html?mastername=headamd64PR205029-default

13 new failures,  and around 10500 ports skipped due to those failures:

+ {"origin"=>"archivers/gzip", "pkgname"=>"gzip-1.6", "phase"=>"build", "errortype"=>"clang"}
+ {"origin"=>"archivers/sharutils", "pkgname"=>"sharutils-4.15.2_1", "phase"=>"build", "errortype"=>"clang"}
+ {"origin"=>"deskutils/gcal", "pkgname"=>"gcal-4", "phase"=>"build", "errortype"=>"clang"}
+ {"origin"=>"devel/idutils", "pkgname"=>"idutils-4.6_1", "phase"=>"build", "errortype"=>"clang"}
+ {"origin"=>"devel/m4", "pkgname"=>"m4-1.4.17_1,1", "phase"=>"build", "errortype"=>"clang"}
+ {"origin"=>"misc/findutils", "pkgname"=>"findutils-4.5.14_1", "phase"=>"build", "errortype"=>"clang"}
+ {"origin"=>"misc/gnuls", "pkgname"=>"gnuls-8.22", "phase"=>"build", "errortype"=>"clang"}
+ {"origin"=>"net/dhcpd-pools", "pkgname"=>"dhcpd-pools-2.27", "phase"=>"build", "errortype"=>"clang"}
+ {"origin"=>"security/oath-toolkit", "pkgname"=>"oath-toolkit-2.6.1", "phase"=>"build", "errortype"=>"clang"}
+ {"origin"=>"security/slurpie", "pkgname"=>"slurpie-2.0b", "phase"=>"build", "errortype"=>"clang"}
+ {"origin"=>"sysutils/coreutils", "pkgname"=>"coreutils-8.23", "phase"=>"build", "errortype"=>"clang"}
+ {"origin"=>"sysutils/dc3dd", "pkgname"=>"dc3dd-7.2.641", "phase"=>"build", "errortype"=>"clang"}
+ {"origin"=>"sysutils/doinkd", "pkgname"=>"doinkd-0.01_6", "phase"=>"build", "errortype"=>"clang"}

Failure logs:

http://package18.nyi.freebsd.org/data/headamd64PR205029-default/2015-12-09_06h46m54s/logs/errors/gzip-1.6.log 
http://package18.nyi.freebsd.org/data/headamd64PR205029-default/2015-12-09_06h46m54s/logs/errors/sharutils-4.15.2_1.log 
http://package18.nyi.freebsd.org/data/headamd64PR205029-default/2015-12-09_06h46m54s/logs/errors/gcal-4.log 
http://package18.nyi.freebsd.org/data/headamd64PR205029-default/2015-12-09_06h46m54s/logs/errors/idutils-4.6_1.log 
http://package18.nyi.freebsd.org/data/headamd64PR205029-default/2015-12-09_06h46m54s/logs/errors/m4-1.4.17_1,1.log 
http://package18.nyi.freebsd.org/data/headamd64PR205029-default/2015-12-09_06h46m54s/logs/errors/findutils-4.5.14_1.log 
http://package18.nyi.freebsd.org/data/headamd64PR205029-default/2015-12-09_06h46m54s/logs/errors/gnuls-8.22.log 
http://package18.nyi.freebsd.org/data/headamd64PR205029-default/2015-12-09_06h46m54s/logs/errors/dhcpd-pools-2.27.log 
http://package18.nyi.freebsd.org/data/headamd64PR205029-default/2015-12-09_06h46m54s/logs/errors/oath-toolkit-2.6.1.log 
http://package18.nyi.freebsd.org/data/headamd64PR205029-default/2015-12-09_06h46m54s/logs/errors/slurpie-2.0b.log 
http://package18.nyi.freebsd.org/data/headamd64PR205029-default/2015-12-09_06h46m54s/logs/errors/coreutils-8.23.log 
http://package18.nyi.freebsd.org/data/headamd64PR205029-default/2015-12-09_06h46m54s/logs/errors/dc3dd-7.2.641.log 
http://package18.nyi.freebsd.org/data/headamd64PR205029-default/2015-12-09_06h46m54s/logs/errors/doinkd-0.01_6.log
Comment 4 John Baldwin freebsd_committer freebsd_triage 2018-02-01 19:09:42 UTC
Since Ed added himself.  The current state of this is that gnulib currently tries to read several fields in FILE that are in the middle due to a workaround for what it claims is broken behavior in FreeBSD's stdio with ungetc.  What I have been wanting to do (but not yet done), is verify if gnulib even needs that workaround, and if it does fix the bug in our stdio so that gnulib can stop using the workaround.  Then I'd like to be able to make most of FILE opaque (though for ABI reasons we would have to leave the fields gnulib currently accesses in place for old binaries), and then commit the large _file patch.  I just haven't figured out how to run gnulib's tests as the first step.