It only calls fgets() when the input is ASCII, as it is in the case of reading from cnt. I do call fread() for loading binary input.
-G > From: "Randolph M. Fritz" <rmfri...@gmail.com> > Subject: Re: [Radiance-dev] Pipe problems on Windows > Date: March 26, 2016 11:48:18 AM PDT > > Maybe we should change that to fread()? fgets() is text-oriented. > > -- > Randolph M. Fritz, Lighting Design and Simulation > +1 206 659-8617 || rmfri...@gmail.com > > On Sat, Mar 26, 2016 at 8:33 AM, Gregory J. Ward <gregoryjw...@gmail.com> > wrote: > Input is read from stdin by rcalc using this line in getinputrec(): > > return(fgets(inpbuf, INBSIZ, fp) != NULL); > > I don't know why fgets() would fail on a pipe of ASCII data, but it sounds > like that's what is happening in some cases. > > -Greg > > > From: Georg Mischler <schor...@schorsch.com> > > Subject: Re: [Radiance-dev] Pipe problems on Windows > > Date: March 26, 2016 2:49:05 AM PDT > > > > Am 2016-03-26 08:27, schrieb Randolph Fritz: > >> On Mar 26, 2016, at 12:09 AM, Georg Mischler <schor...@schorsch.com> wrote: > >>> I tend to agree with Randolph. This is likely a problem that comes to > >>> the surface due to the different memory layout applied by the MS > >>> compiler. > >> I suppose it could also be a timing problem. Perhaps the Windows stdio > >> library is multi-threaded and this somehow interacts with pipes. > > > > For a while I also had that suspicion, especially since in cmd.exe, > > things go right (or at least slightly less wrong) once in a while. > > But memory alignment doesn't have to be identical on each run, and I > > don't see a a reason for making straight stdio calls multi-threaded, > > unless you explicitly use the "overlapping io" functions. > > We would also find lots of complaints online, if correct use of > > stdio could lead to intermittent failure. > > > > > >> Hmmm…or perhaps MSVC’s code generation “optimizer” is creating > >> problems. Might be worth setting it to the lowest level and see if > >> that helps. > > > > This is a debug build with zero optimization. > > > > > >>> Then I'll have to figure out how I can get the MS debugger to invoke > >>> such a chained pipeline for stepping through the process. > >>> So far I could only take a glance when rcalc output was blocked for > >>> some reason, so I had time to attach the debugger from the outside. > >>> But that only gave me a static picture, which didn't really help. > >> I wonder if the Dr. Memory debugging tool (http://www.drmemory.org/) would > >> help? > > > > I'll look into it, thanks! > > > > -schorsch
_______________________________________________ Radiance-dev mailing list Radiance-dev@radiance-online.org http://www.radiance-online.org/mailman/listinfo/radiance-dev
