Well, that is some interesting stuff. So, in POSIX, the child gets the
same FD in the same place and it is actually a second reference to the
kernels open file table. The same entry as the parent uses (via FD) to
determine the offset, flags, etc.
That would explain why the child calling exit() flus
On 01/17/2014 01:10 PM, Eric Blake wrote:
>> However..
>>
>> Do I understand that to say that if the first thing my child does is
>>
>> fclose(fp);
>>
>> everything should be hunky-dory?
>
> No. You have to fix things _in the parent, before the fork()_ for
> everything to be hunky-dory. The
In message <52d98e1d.8010...@redhat.com>you write:
>
>No. You have to fix things _in the parent, before the fork()_ for
>everything to be hunky-dory. The easiest way to do that is to
>fflush(NULL) before fork()ing.
>
You learn something new every day.
Usually just after you needed to know it.
On 01/14/2014 08:50 AM, tedno...@bellsouth.net wrote:
> In message <52d55d96.8070...@redhat.com>you write:
>>
>> Your program may be violating POSIX, which would trigger undefined behavior.
>>
>> Quoting POSIX:
>> pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_05
>>
>
> [
On 01/15/2014 08:28 AM, tedno...@bellsouth.net wrote:
> Well, all I can say in this instance, is that arguably conforming to
> the bare letter of the standard (if that's in fact what is happening)
> is not "the right thing". People certainly don't expect that stdio
> file pointers that exist at f
On 01/14/2014 09:53 PM, Lord Laraby wrote:
> My two cents say, since the child is not referencing 'fp' at all,
> there is no violation of the POSIX semantics in this situation.
But the child _IS_ referencing 'fp', via the implicit fflush(NULL) done
by exit(). If you use _exit() to bypass that imp
On 01/13/2014 09:06 AM, tedno...@bellsouth.net wrote:
> while( fgets(buf, sizeof(buf), fp) ) {
> ++i;
>
> if(sscanf(buf, "%s %s", infile, outfile) != 2) {
>
> switch (fork()) {
>
> case 0:
>
On Jan 16 23:53, tedno...@bellsouth.net wrote:
> In message <20140116085026.ga26...@calimero.vinschen.de>you write:
> >
> >Can you change your testcase another bit, please? Enable your
> >`ftell' printf, but rather than printing the result of ftell,
> >print the result of lseek:
> >
> > fprintf(s
In message <20140116085026.ga26...@calimero.vinschen.de>you write:
>
>Can you change your testcase another bit, please? Enable your
>`ftell' printf, but rather than printing the result of ftell,
>print the result of lseek:
>
> fprintf(stderr, "(%s) (%s) %d %ld\n", infile,
>outfile, i, lse
On Jan 15 23:42, tedno...@bellsouth.net wrote:
> >> FWIW, FreeBSD, Linux and Solaris all compile and run the test program
> >> with the behavoir I expect..
> >
> >Just for completeness: I can test on Linux, but not on FreeBSD and
> >Solaris. Does the testcase also work as expected on both of them
In message <20140115163354.ga30...@calimero.vinschen.de>you write:
>--ew6BAiZeqk4r7MaW
>Content-Type: text/plain; charset=utf-8
>Content-Disposition: inline
>Content-Transfer-Encoding: quoted-printable
>
>On Jan 15 10:28, tedno...@bellsouth.net wrote:
>> In message <52d63ce2.9060...@lysator.liu.se>
On Jan 15 11:39, Tom Honermann wrote:
> On 01/13/2014 11:06 AM, tedno...@bellsouth.net wrote:
> ...
> > switch (fork()) {
> >
> > /* error */
> > case -1:
> ...
> > /* child */
> > case
On 01/13/2014 11:06 AM, tedno...@bellsouth.net wrote:
...
switch (fork()) {
/* error */
case -1:
...
/* child */
case 0:
fprin
On Jan 15 10:28, tedno...@bellsouth.net wrote:
> In message <52d63ce2.9060...@lysator.liu.se>you write:
> >On 2014-01-15 05:53, Lord Laraby wrote:
> >> On Tue, Jan 14, 2014 at 10:50 AM, Ted Nolan wrote:
> >>> In message <52d55d96.8070...@redhat.com> you write:
>
> Your program may be viol
In message <52d63ce2.9060...@lysator.liu.se>you write:
>On 2014-01-15 05:53, Lord Laraby wrote:
>> On Tue, Jan 14, 2014 at 10:50 AM, Ted Nolan wrote:
>>> In message <52d55d96.8070...@redhat.com> you write:
Your program may be violating POSIX, which would trigger undefined behavio
>r.
On 2014-01-15 05:53, Lord Laraby wrote:
> On Tue, Jan 14, 2014 at 10:50 AM, Ted Nolan wrote:
>> In message <52d55d96.8070...@redhat.com> you write:
>>>
>>> Your program may be violating POSIX, which would trigger undefined behavior.
>>>
>>> Quoting POSIX:
>>> pubs.opengroup.org/onlinepubs/969991979
Please forgive my TOFU above. This gmail client really has no manners at all.
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
My two cents say, since the child is not referencing 'fp' at all,
there is no violation of the POSIX semantics in this situation. It
actually does seem, however, that the fork is closing, or at least
forgetting the stdio file position of, fp when it forks. A possible
memory corruption during fork f
In message <52d55d96.8070...@redhat.com>you write:
>
>Your program may be violating POSIX, which would trigger undefined behavior.
>
>Quoting POSIX:
> pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_05
>
[long quote elided]
Yikes! That's pretty impenatrable. And if it s
On 01/13/2014 09:06 AM, tedno...@bellsouth.net wrote:
> Hello,
>
> I'm running:
>
> CYGWIN_NT-6.1 prog5 1.7.27(0.271/5/3) 2013-12-09 11:54 x86_64 Cygwin
> gcc (GCC) 4.8.2
>
> on a 64 bit Win7 system.
>
> I have just run into an odd bug, which I have boiled down into the program
> below (which s
On Jan 13 11:06, tedno...@bellsouth.net wrote:
> Hello,
>
> I'm running:
>
> CYGWIN_NT-6.1 prog5 1.7.27(0.271/5/3) 2013-12-09 11:54 x86_64 Cygwin
> gcc (GCC) 4.8.2
>
> on a 64 bit Win7 system.
>
> I have just run into an odd bug, which I have boiled down into the program
> below (which started
Hello,
I'm running:
CYGWIN_NT-6.1 prog5 1.7.27(0.271/5/3) 2013-12-09 11:54 x86_64 Cygwin
gcc (GCC) 4.8.2
on a 64 bit Win7 system.
I have just run into an odd bug, which I have boiled down into the program
below (which started as a mod to tiff2ps).
If you compile this program:
22 matches
Mail list logo
