Front page | perl.perl5.porters |
Postings from May 2015
On Tue, May 05, 2015 at 07:00:10AM -0400, A. Sinan Unur wrote: > On Tue, May 5, 2015 at 6:17 AM, bulk88 <bulk88@hotmail.com> wrote: > > > So a FILE * is now a C++ object (probably based on the above if my C++ > > knowledge is good enough), hence it is opaque. Now what? file a MS bug > > report? Or is perl going to require a C++ shim .o file and #include > > non-public corecrt_internal_stdio.h to access those members? > > Yes, and that is what gave me pause. One could certainly plow ahead, > figuring out the new internal details, trying to hook things up, but > it feels wrong to depend on specific members of the FILE structure. > > All C99 has to say (7.19.1) on this is: > > "FILE ... is an object type capable of recording all the information > needed to control a stream, including its file position indicator, a > pointer to its associated buffer (if any), an error indicator that > records whether a read/write error has occurred, and an end-of-file > indicator that records whether the end of the file has been reached;" > > Is it a bug to replace this with a pointer to something that is > capable of doing those things? > > Should perlio really depend on compiler specific implementation details? > > There are the answers one would give to these questions if we lived in > an ideal world. And, then there is the world we live in. > > The way this issue resolved, or whether it is resolved, may have > implications for Perl on all platforms. > > Hence, my inability to figure out how to proceed. Please try the tonyc/vc2015-file branch. On a POSIXish[1] system Configure detects whether FILE has the right pointers, on Win32 we use canned configs, which reflect the pre-VC2015 C runtime. Assuming it helps, for a full fix this will probably become something controlled by CCTYPE, with the canned config.vc setting both d_stdstdio and d_stdiobase to undef so miniperl will build. Tony [1] eg. Haiku is POSIXish enoughThread Previous | Thread Next