I agree this is probably not the error we have seen before, though it is an
important one. We might think about writing an fgets() replacement for
Windows, rather than using fgetline(), which has slightly different semantics.
We should replace it at the library level, so it will propagate to a
It looks like we're dealing with a broken fgets() included
with Visual Studio 2015 Community edition.
When a newline character falls exactly to the end of the
pipe buffer, it will be ignored. This means that instead of
"\t1328\n" the received string will be "\t1328\t1329\n".
Any time that happens
It seems that Windows fread() sometimes returns a short record when reading
from a pipe. See
https://github.com/jmacd/xdelta/issues/101#issuecomment-85332549.
I still don't understand rcalc's behavior; it seems to me like the short
record should be treated as EOF, but maybe I'm missing something.
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"
> Subject: Re: [Radiance-dev] Pipe problems on Windows
> Date: March 26, 2016 11:48:18 AM PDT
>
> Maybe we should change that to
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
wrote:
> Input is read from stdin by rcalc using this line in getinputrec():
>
>
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
> Subject: Re: [Radiance-
Am 2016-03-26 08:27, schrieb Randolph Fritz:
On Mar 26, 2016, at 12:09 AM, Georg Mischler
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. Perha
On Mar 26, 2016, at 12:09 AM, Georg Mischler 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-th
Turns out the GitHub console brings a nice set of unix utilities.
The tee-d output of cnt is correct in all tested cases.
Reading that file via filename argument in rcalc gives
the correct output again.
Feeding the same data via a pipe from cat causes rcalc to
exhibit the bug.
So it's definitively
No problems with the gcc binaries on Windows either.
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.
So far it only fails when cnt and rcalc are directly connected via
a pipe. When cnt writes to a fi
10 matches
Mail list logo
