[CMake] Problem writing on GPFS.

[P. A. Cheeseman]

> Do you intentionally removed or just forgot to CC the list?

     I failed to 'reply-all'.

     One additional note.  Turning off optimization didn't help, among
the other things I tried.

     My own read of the issue is that there is room to trap the bad
pointer at every layer in its handling.  I suspect the run-time ignores
them because that was easier than watching 'working' codes
break wholesale if the existing convention were to throw an
error (as write(2) does).

				Best regards,
				Phil

				P. A. Cheeseman
				aai at purdue.edu
				765.496.8224


> -----Original Message-----
> From: Rolf Eike Beer [mailto:eike at sf-mail.de]
> Sent: Tuesday, February 10, 2015 14:18
> To: aai at purdue.edu
> Subject: Re: [CMake] Problem writing on GPFS.
> 
> P. A. Cheeseman wrote:
> >      RedHat and GNU support are on the todo list once I can identify
> > what's in the Cmake source that tricks the run-time into using writev().
> >
> >      Several gdb(1) sessions led me to the top end source of the calls
> > which is cmFileCommand::HandleWriteCommand().  I've not traced
> through
> > the multiple layers of run-time to see where the iovec array is
> > created from the 'file << message' line.
> 
> Ah, but that's a good clue. g++ may just optimize the message writing into
> that, or libstdc++ may. You may try with CXXFLAGS=-O0 to see it it works
> then.
> 
> >      The fact that the run-time from either GNU or Redhat generates
> > the marginal call is bothersome.  I suspect the fundamental problem
> > has existed for some time.  Have also not found any reference to what
> > is 'correct' behavior for writev() when a pointer is NULL but I'm not
> > a dedicated student of POSIX etc.
> 
> I don't know, but given the fact that it works in a latter place and on
all other
> fs makes it look like a bug to me.
> 
> Do you intentionally removed or just forgot to CC the list?
> 
> Eike
> --