Re: [Oorexx-devel] A possible fix for bug 3274050
Committed an adjustment. Using this script : -- file append.rex use arg file call lineout file, one call lineout file, two rexx append.rex read_write.txt rexx append.rex read_write.txt cat read_write.txt one two one two The same actions with read_only.txt gave one twoone two Now with the adjusment, I get one two one two Jean Louis 2011/11/12 Jean-Louis Faucher jfaucher...@gmail.com forget my comment about isopen... It is at the right place in both cases. The difference between implicit open and explicit open comes from the test isDevice(), done only when explicit open. Can't tell if this test is needed also in implicit open... I suppose we should have the same behavior in both cases ? Jean-Louis 2011/11/12 Jean-Louis Faucher jfaucher...@gmail.com sorry, I wrote charout[2], this is charout[1]. Jean Louis 2011/11/12 Jean-Louis Faucher jfaucher...@gmail.com Still working on the test cases... From the script below, I see that : The charout [2] succeeds in implicit opening of the stream, but fails in the ctrl_z stuff. If the file is empty then the charout [2] succeeds since there is no ctrl_z stuff. The following char/lineout are ok. So there is a workaround : use an implicit open and write a dummy line. The following writes will be ok. A last point, I was curious to understand why the first write fails after the command open, and why it succeeds afer : In implicitOpen, the attribute isopen is set to true before testing ctrl_z, so not impacted by a write-only file. In streamOpen, the attribute isopen is set to true after testing ctrl_z, so impacted by a write-only file. To be consistent, in streamOpen, the attribute isopen should be assigned true before the ctrl_z stuff (in my opinion). file = write_only.txt -- permissions : --w--w--w- say stream(file, c, open write append) -- error 13 say charout(file, [1] || some chars)-- 13 characters remaining to write (no error if file is empty) say charout(file, [2] || more chars)-- 0correctly written... say lineout(file, [3] || line1) -- 0 say lineout(file, [4] || line2) -- 0 say charout(file, [5] || EOF) -- 0 say charout(file, [6] || 1Ax) -- eof-- 0 Jean Louis 2011/11/11 CVBruce cvbr...@gmail.com ctrl_z is a hold over from CP/M-80 at least. CP/M didn't have any sort of counter or pointer to tell where the data ended in the last allocated disk block, so a marker was used. I don't know why ctrl_z was chosen. Ctrl_\ , the ASCII file separator charter would have seemed to be a better choice. I'm sure they had their reasons. Bruce On Nov 11, 2011, at 9:43 AM, Mark Miesfeld wrote: On Fri, Nov 11, 2011 at 8:08 AM, Jean-Louis Faucher jfaucher...@gmail.com wrote: After replacing the test isDevice() by true, the open is ok, but... ... Tested under MacOs, looks good. Not tested under Linux or Windows. Not sure if I break something by not testing ctrl_z... For me, ctrl_z is Windows specific, no ? is the write-only mode supported under Windows ? Opening a file for write only is supported under Windows. ctrl_z is a hold over from DOS I think. I believe I read that the operating system ignores it now and goes by the size of the file. I.e. if you have a ctrl-z at position 100, but the file size is 200, the OS uses 200. I say commit the fix and I'll try to get some time to test it on Windows / look more closely at the ctrl-z issue. -- Mark Miesfeld -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] A possible fix for bug 3274050
Still working on the test cases... From the script below, I see that : The charout [2] succeeds in implicit opening of the stream, but fails in the ctrl_z stuff. If the file is empty then the charout [2] succeeds since there is no ctrl_z stuff. The following char/lineout are ok. So there is a workaround : use an implicit open and write a dummy line. The following writes will be ok. A last point, I was curious to understand why the first write fails after the command open, and why it succeeds afer : In implicitOpen, the attribute isopen is set to true before testing ctrl_z, so not impacted by a write-only file. In streamOpen, the attribute isopen is set to true after testing ctrl_z, so impacted by a write-only file. To be consistent, in streamOpen, the attribute isopen should be assigned true before the ctrl_z stuff (in my opinion). file = write_only.txt -- permissions : --w--w--w- say stream(file, c, open write append) -- error 13 say charout(file, [1] || some chars)-- 13 characters remaining to write (no error if file is empty) say charout(file, [2] || more chars)-- 0correctly written... say lineout(file, [3] || line1) -- 0 say lineout(file, [4] || line2) -- 0 say charout(file, [5] || EOF) -- 0 say charout(file, [6] || 1Ax) -- eof-- 0 Jean Louis 2011/11/11 CVBruce cvbr...@gmail.com ctrl_z is a hold over from CP/M-80 at least. CP/M didn't have any sort of counter or pointer to tell where the data ended in the last allocated disk block, so a marker was used. I don't know why ctrl_z was chosen. Ctrl_\ , the ASCII file separator charter would have seemed to be a better choice. I'm sure they had their reasons. Bruce On Nov 11, 2011, at 9:43 AM, Mark Miesfeld wrote: On Fri, Nov 11, 2011 at 8:08 AM, Jean-Louis Faucher jfaucher...@gmail.com wrote: After replacing the test isDevice() by true, the open is ok, but... ... Tested under MacOs, looks good. Not tested under Linux or Windows. Not sure if I break something by not testing ctrl_z... For me, ctrl_z is Windows specific, no ? is the write-only mode supported under Windows ? Opening a file for write only is supported under Windows. ctrl_z is a hold over from DOS I think. I believe I read that the operating system ignores it now and goes by the size of the file. I.e. if you have a ctrl-z at position 100, but the file size is 200, the OS uses 200. I say commit the fix and I'll try to get some time to test it on Windows / look more closely at the ctrl-z issue. -- Mark Miesfeld -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] A possible fix for bug 3274050
sorry, I wrote charout[2], this is charout[1]. Jean Louis 2011/11/12 Jean-Louis Faucher jfaucher...@gmail.com Still working on the test cases... From the script below, I see that : The charout [2] succeeds in implicit opening of the stream, but fails in the ctrl_z stuff. If the file is empty then the charout [2] succeeds since there is no ctrl_z stuff. The following char/lineout are ok. So there is a workaround : use an implicit open and write a dummy line. The following writes will be ok. A last point, I was curious to understand why the first write fails after the command open, and why it succeeds afer : In implicitOpen, the attribute isopen is set to true before testing ctrl_z, so not impacted by a write-only file. In streamOpen, the attribute isopen is set to true after testing ctrl_z, so impacted by a write-only file. To be consistent, in streamOpen, the attribute isopen should be assigned true before the ctrl_z stuff (in my opinion). file = write_only.txt -- permissions : --w--w--w- say stream(file, c, open write append) -- error 13 say charout(file, [1] || some chars)-- 13 characters remaining to write (no error if file is empty) say charout(file, [2] || more chars)-- 0correctly written... say lineout(file, [3] || line1) -- 0 say lineout(file, [4] || line2) -- 0 say charout(file, [5] || EOF) -- 0 say charout(file, [6] || 1Ax) -- eof-- 0 Jean Louis 2011/11/11 CVBruce cvbr...@gmail.com ctrl_z is a hold over from CP/M-80 at least. CP/M didn't have any sort of counter or pointer to tell where the data ended in the last allocated disk block, so a marker was used. I don't know why ctrl_z was chosen. Ctrl_\ , the ASCII file separator charter would have seemed to be a better choice. I'm sure they had their reasons. Bruce On Nov 11, 2011, at 9:43 AM, Mark Miesfeld wrote: On Fri, Nov 11, 2011 at 8:08 AM, Jean-Louis Faucher jfaucher...@gmail.com wrote: After replacing the test isDevice() by true, the open is ok, but... ... Tested under MacOs, looks good. Not tested under Linux or Windows. Not sure if I break something by not testing ctrl_z... For me, ctrl_z is Windows specific, no ? is the write-only mode supported under Windows ? Opening a file for write only is supported under Windows. ctrl_z is a hold over from DOS I think. I believe I read that the operating system ignores it now and goes by the size of the file. I.e. if you have a ctrl-z at position 100, but the file size is 200, the OS uses 200. I say commit the fix and I'll try to get some time to test it on Windows / look more closely at the ctrl-z issue. -- Mark Miesfeld -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] A possible fix for bug 3274050
forget my comment about isopen... It is at the right place in both cases. The difference between implicit open and explicit open comes from the test isDevice(), done only when explicit open. Can't tell if this test is needed also in implicit open... I suppose we should have the same behavior in both cases ? Jean-Louis 2011/11/12 Jean-Louis Faucher jfaucher...@gmail.com sorry, I wrote charout[2], this is charout[1]. Jean Louis 2011/11/12 Jean-Louis Faucher jfaucher...@gmail.com Still working on the test cases... From the script below, I see that : The charout [2] succeeds in implicit opening of the stream, but fails in the ctrl_z stuff. If the file is empty then the charout [2] succeeds since there is no ctrl_z stuff. The following char/lineout are ok. So there is a workaround : use an implicit open and write a dummy line. The following writes will be ok. A last point, I was curious to understand why the first write fails after the command open, and why it succeeds afer : In implicitOpen, the attribute isopen is set to true before testing ctrl_z, so not impacted by a write-only file. In streamOpen, the attribute isopen is set to true after testing ctrl_z, so impacted by a write-only file. To be consistent, in streamOpen, the attribute isopen should be assigned true before the ctrl_z stuff (in my opinion). file = write_only.txt -- permissions : --w--w--w- say stream(file, c, open write append) -- error 13 say charout(file, [1] || some chars)-- 13 characters remaining to write (no error if file is empty) say charout(file, [2] || more chars)-- 0correctly written... say lineout(file, [3] || line1) -- 0 say lineout(file, [4] || line2) -- 0 say charout(file, [5] || EOF) -- 0 say charout(file, [6] || 1Ax) -- eof-- 0 Jean Louis 2011/11/11 CVBruce cvbr...@gmail.com ctrl_z is a hold over from CP/M-80 at least. CP/M didn't have any sort of counter or pointer to tell where the data ended in the last allocated disk block, so a marker was used. I don't know why ctrl_z was chosen. Ctrl_\ , the ASCII file separator charter would have seemed to be a better choice. I'm sure they had their reasons. Bruce On Nov 11, 2011, at 9:43 AM, Mark Miesfeld wrote: On Fri, Nov 11, 2011 at 8:08 AM, Jean-Louis Faucher jfaucher...@gmail.com wrote: After replacing the test isDevice() by true, the open is ok, but... ... Tested under MacOs, looks good. Not tested under Linux or Windows. Not sure if I break something by not testing ctrl_z... For me, ctrl_z is Windows specific, no ? is the write-only mode supported under Windows ? Opening a file for write only is supported under Windows. ctrl_z is a hold over from DOS I think. I believe I read that the operating system ignores it now and goes by the size of the file. I.e. if you have a ctrl-z at position 100, but the file size is 200, the OS uses 200. I say commit the fix and I'll try to get some time to test it on Windows / look more closely at the ctrl-z issue. -- Mark Miesfeld -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
[Oorexx-devel] A possible fix for bug 3274050
The problem comes from
StreamNative.cpp
const char *StreamInfo::streamOpen(const char *options)
When the O_WRONLY flag is set, ooRexx tries read-write first,
but does not fallback to write-only in case of failure (limited to device)
After replacing the test isDevice() by true, the open is ok, but...
another problem in this method, when testing if the last character is
ctrl_z.
Since the handle is write-only, the attempt to read the last character
fails and notReadyError is called.
Fixed by not testing if ctrl_z when write-only.
The same workaround for ctrl_z must be done in
StreamInfo::implicitOpen
StreamInfo::handleOpen
Tested under MacOs, looks good.
Not tested under Linux or Windows.
Not sure if I break something by not testing ctrl_z... For me, ctrl_z is
Windows specific, no ? is the write-only mode supported under Windows ?
Jean-Louis
-- Forwarded message --
From: jfauc...@users.sourceforge.net
Date: 2011/11/11
Subject: [Oorexx-svn] SF.net SVN: oorexx:[7286]
sandbox/jlf/trunk/interpreter/streamLibrary/ StreamNative.cpp
To: oorexx-...@lists.sourceforge.net
Revision: 7286
http://oorexx.svn.sourceforge.net/oorexx/?rev=7286view=rev
Author: jfaucher
Date: 2011-11-11 16:04:41 + (Fri, 11 Nov 2011)
Log Message:
---
A possible fix for bug 3274050 (to discuss on the dev list)
Modified Paths:
--
sandbox/jlf/trunk/interpreter/streamLibrary/StreamNative.cpp
Modified: sandbox/jlf/trunk/interpreter/streamLibrary/StreamNative.cpp
===
--- sandbox/jlf/trunk/interpreter/streamLibrary/StreamNative.cpp
2011-11-11 04:23:38 UTC (rev 7285)
+++ sandbox/jlf/trunk/interpreter/streamLibrary/StreamNative.cpp
2011-11-11 16:04:41 UTC (rev 7286)
@@ -632,6 +632,8 @@
// position at the end, and set the write position
setPosition(size(), charWritePosition);
+if (!write_only)
+{
char char_buffer;
size_t bytesRead;
// read the last character of the buffer.
@@ -651,6 +653,7 @@
/* explicitly set the position */
setPosition(charWritePosition, charWritePosition);
}
+}
}
lineWritePosition = 0;
lineWriteCharPosition = 0;
@@ -793,6 +796,8 @@
// position at the end, and set the write position
setPosition(size(), charWritePosition);
+if (!write_only)
+{
char char_buffer;
size_t bytesRead;
// read the last character of the buffer.
@@ -812,6 +817,7 @@
/* explicitly set the position */
setPosition(charWritePosition, charWritePosition);
}
+}
}
// set default line positioning
lineWritePosition = 0;
@@ -2384,7 +2390,8 @@
{
// if this is some sort of device, it might be output only (i.e., a
// printer). Try opening again write only
-if (fileInfo.isDevice())
+// bug 3274050 : no longer limited to device, a regular file can
have write-only permissions
+if (true /*fileInfo.isDevice()*/)
{
if (!open(WR_CREAT, S_IWRITE, shared))
{
@@ -2428,6 +2435,8 @@
// position at the end, and set the write position
setPosition(size(), charWritePosition);
+if (!write_only)
+{
char char_buffer;
size_t bytesRead;
// read the last character of the buffer.
@@ -2447,6 +2456,7 @@
/* explicitly set the position */
setPosition(charWritePosition, charWritePosition);
}
+}
}
/* set default line positioning */
lineWritePosition = 0;
This was sent by the SourceForge.net collaborative development platform,
the world's largest Open Source development site.
--
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
___
Oorexx-svn mailing list
oorexx-...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-svn
--
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] A possible fix for bug 3274050
I was looking at something similar, but my Linux system is castors up
at the moment, so I haven't really been able to test anything. I'm
not totally comfortable with the isDevice() test just being commented
out. I think this should be if (write_only || fileInfo.isDevice())
rather than just being an unconditional. It would be wrong to open
any stream as write only if the options were requesting otherwise.
Rick
On Fri, Nov 11, 2011 at 11:08 AM, Jean-Louis Faucher
jfaucher...@gmail.com wrote:
The problem comes from
StreamNative.cpp
const char *StreamInfo::streamOpen(const char *options)
When the O_WRONLY flag is set, ooRexx tries read-write first,
but does not fallback to write-only in case of failure (limited to device)
After replacing the test isDevice() by true, the open is ok, but...
another problem in this method, when testing if the last character is
ctrl_z.
Since the handle is write-only, the attempt to read the last character fails
and notReadyError is called.
Fixed by not testing if ctrl_z when write-only.
The same workaround for ctrl_z must be done in
StreamInfo::implicitOpen
StreamInfo::handleOpen
Tested under MacOs, looks good.
Not tested under Linux or Windows.
Not sure if I break something by not testing ctrl_z... For me, ctrl_z is
Windows specific, no ? is the write-only mode supported under Windows ?
Jean-Louis
-- Forwarded message --
From: jfauc...@users.sourceforge.net
Date: 2011/11/11
Subject: [Oorexx-svn] SF.net SVN: oorexx:[7286]
sandbox/jlf/trunk/interpreter/streamLibrary/ StreamNative.cpp
To: oorexx-...@lists.sourceforge.net
Revision: 7286
http://oorexx.svn.sourceforge.net/oorexx/?rev=7286view=rev
Author: jfaucher
Date: 2011-11-11 16:04:41 + (Fri, 11 Nov 2011)
Log Message:
---
A possible fix for bug 3274050 (to discuss on the dev list)
Modified Paths:
--
sandbox/jlf/trunk/interpreter/streamLibrary/StreamNative.cpp
Modified: sandbox/jlf/trunk/interpreter/streamLibrary/StreamNative.cpp
===
--- sandbox/jlf/trunk/interpreter/streamLibrary/StreamNative.cpp
2011-11-11 04:23:38 UTC (rev 7285)
+++ sandbox/jlf/trunk/interpreter/streamLibrary/StreamNative.cpp
2011-11-11 16:04:41 UTC (rev 7286)
@@ -632,6 +632,8 @@
// position at the end, and set the write position
setPosition(size(), charWritePosition);
+ if (!write_only)
+ {
char char_buffer;
size_t bytesRead;
// read the last character of the buffer.
@@ -651,6 +653,7 @@
/* explicitly set the position */
setPosition(charWritePosition, charWritePosition);
}
+ }
}
lineWritePosition = 0;
lineWriteCharPosition = 0;
@@ -793,6 +796,8 @@
// position at the end, and set the write position
setPosition(size(), charWritePosition);
+ if (!write_only)
+ {
char char_buffer;
size_t bytesRead;
// read the last character of the buffer.
@@ -812,6 +817,7 @@
/* explicitly set the position */
setPosition(charWritePosition, charWritePosition);
}
+ }
}
// set default line positioning
lineWritePosition = 0;
@@ -2384,7 +2390,8 @@
{
// if this is some sort of device, it might be output only (i.e., a
// printer). Try opening again write only
- if (fileInfo.isDevice())
+ // bug 3274050 : no longer limited to device, a regular file can
have write-only permissions
+ if (true /*fileInfo.isDevice()*/)
{
if (!open(WR_CREAT, S_IWRITE, shared))
{
@@ -2428,6 +2435,8 @@
// position at the end, and set the write position
setPosition(size(), charWritePosition);
+ if (!write_only)
+ {
char char_buffer;
size_t bytesRead;
// read the last character of the buffer.
@@ -2447,6 +2456,7 @@
/* explicitly set the position */
setPosition(charWritePosition, charWritePosition);
}
+ }
}
/* set default line positioning */
lineWritePosition = 0;
This was sent by the SourceForge.net collaborative development platform, the
world's largest Open Source development site.
--
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
___
Oorexx-svn mailing list
oorexx-...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-svn
--
RSA(R)
Re: [Oorexx-devel] A possible fix for bug 3274050
ok.
on my side I don't plan to commit in trunk, was just an experimentation.
I prefer to leave you decide what to do :-)
Jean-Louis
2011/11/11 Rick McGuire object.r...@gmail.com
I was looking at something similar, but my Linux system is castors up
at the moment, so I haven't really been able to test anything. I'm
not totally comfortable with the isDevice() test just being commented
out. I think this should be if (write_only || fileInfo.isDevice())
rather than just being an unconditional. It would be wrong to open
any stream as write only if the options were requesting otherwise.
Rick
On Fri, Nov 11, 2011 at 11:08 AM, Jean-Louis Faucher
jfaucher...@gmail.com wrote:
The problem comes from
StreamNative.cpp
const char *StreamInfo::streamOpen(const char *options)
When the O_WRONLY flag is set, ooRexx tries read-write first,
but does not fallback to write-only in case of failure (limited to
device)
After replacing the test isDevice() by true, the open is ok, but...
another problem in this method, when testing if the last character is
ctrl_z.
Since the handle is write-only, the attempt to read the last character
fails
and notReadyError is called.
Fixed by not testing if ctrl_z when write-only.
The same workaround for ctrl_z must be done in
StreamInfo::implicitOpen
StreamInfo::handleOpen
Tested under MacOs, looks good.
Not tested under Linux or Windows.
Not sure if I break something by not testing ctrl_z... For me, ctrl_z is
Windows specific, no ? is the write-only mode supported under Windows ?
Jean-Louis
-- Forwarded message --
From: jfauc...@users.sourceforge.net
Date: 2011/11/11
Subject: [Oorexx-svn] SF.net SVN: oorexx:[7286]
sandbox/jlf/trunk/interpreter/streamLibrary/ StreamNative.cpp
To: oorexx-...@lists.sourceforge.net
Revision: 7286
http://oorexx.svn.sourceforge.net/oorexx/?rev=7286view=rev
Author: jfaucher
Date: 2011-11-11 16:04:41 + (Fri, 11 Nov 2011)
Log Message:
---
A possible fix for bug 3274050 (to discuss on the dev list)
Modified Paths:
--
sandbox/jlf/trunk/interpreter/streamLibrary/StreamNative.cpp
Modified: sandbox/jlf/trunk/interpreter/streamLibrary/StreamNative.cpp
===
--- sandbox/jlf/trunk/interpreter/streamLibrary/StreamNative.cpp
2011-11-11 04:23:38 UTC (rev 7285)
+++ sandbox/jlf/trunk/interpreter/streamLibrary/StreamNative.cpp
2011-11-11 16:04:41 UTC (rev 7286)
@@ -632,6 +632,8 @@
// position at the end, and set the write position
setPosition(size(), charWritePosition);
+if (!write_only)
+{
char char_buffer;
size_t bytesRead;
// read the last character of the buffer.
@@ -651,6 +653,7 @@
/* explicitly set the position */
setPosition(charWritePosition, charWritePosition);
}
+}
}
lineWritePosition = 0;
lineWriteCharPosition = 0;
@@ -793,6 +796,8 @@
// position at the end, and set the write position
setPosition(size(), charWritePosition);
+if (!write_only)
+{
char char_buffer;
size_t bytesRead;
// read the last character of the buffer.
@@ -812,6 +817,7 @@
/* explicitly set the position */
setPosition(charWritePosition, charWritePosition);
}
+}
}
// set default line positioning
lineWritePosition = 0;
@@ -2384,7 +2390,8 @@
{
// if this is some sort of device, it might be output only
(i.e., a
// printer). Try opening again write only
-if (fileInfo.isDevice())
+// bug 3274050 : no longer limited to device, a regular file can
have write-only permissions
+if (true /*fileInfo.isDevice()*/)
{
if (!open(WR_CREAT, S_IWRITE, shared))
{
@@ -2428,6 +2435,8 @@
// position at the end, and set the write position
setPosition(size(), charWritePosition);
+if (!write_only)
+{
char char_buffer;
size_t bytesRead;
// read the last character of the buffer.
@@ -2447,6 +2456,7 @@
/* explicitly set the position */
setPosition(charWritePosition, charWritePosition);
}
+}
}
/* set default line positioning */
lineWritePosition = 0;
This was sent by the SourceForge.net collaborative development platform,
the
world's largest Open Source development site.
--
RSA(R) Conference 2012
Save $700 by
Re: [Oorexx-devel] A possible fix for bug 3274050
Unfortunately, I don't have a means at the moment to try out potential
fixes. If you have something that appears to fix the problem, then go
ahead and commit the fix and we can adjust as needed.
Rick
On Fri, Nov 11, 2011 at 11:27 AM, Jean-Louis Faucher
jfaucher...@gmail.com wrote:
ok.
on my side I don't plan to commit in trunk, was just an experimentation.
I prefer to leave you decide what to do :-)
Jean-Louis
2011/11/11 Rick McGuire object.r...@gmail.com
I was looking at something similar, but my Linux system is castors up
at the moment, so I haven't really been able to test anything. I'm
not totally comfortable with the isDevice() test just being commented
out. I think this should be if (write_only || fileInfo.isDevice())
rather than just being an unconditional. It would be wrong to open
any stream as write only if the options were requesting otherwise.
Rick
On Fri, Nov 11, 2011 at 11:08 AM, Jean-Louis Faucher
jfaucher...@gmail.com wrote:
The problem comes from
StreamNative.cpp
const char *StreamInfo::streamOpen(const char *options)
When the O_WRONLY flag is set, ooRexx tries read-write first,
but does not fallback to write-only in case of failure (limited to
device)
After replacing the test isDevice() by true, the open is ok, but...
another problem in this method, when testing if the last character is
ctrl_z.
Since the handle is write-only, the attempt to read the last character
fails
and notReadyError is called.
Fixed by not testing if ctrl_z when write-only.
The same workaround for ctrl_z must be done in
StreamInfo::implicitOpen
StreamInfo::handleOpen
Tested under MacOs, looks good.
Not tested under Linux or Windows.
Not sure if I break something by not testing ctrl_z... For me, ctrl_z is
Windows specific, no ? is the write-only mode supported under Windows ?
Jean-Louis
-- Forwarded message --
From: jfauc...@users.sourceforge.net
Date: 2011/11/11
Subject: [Oorexx-svn] SF.net SVN: oorexx:[7286]
sandbox/jlf/trunk/interpreter/streamLibrary/ StreamNative.cpp
To: oorexx-...@lists.sourceforge.net
Revision: 7286
http://oorexx.svn.sourceforge.net/oorexx/?rev=7286view=rev
Author: jfaucher
Date: 2011-11-11 16:04:41 + (Fri, 11 Nov 2011)
Log Message:
---
A possible fix for bug 3274050 (to discuss on the dev list)
Modified Paths:
--
sandbox/jlf/trunk/interpreter/streamLibrary/StreamNative.cpp
Modified: sandbox/jlf/trunk/interpreter/streamLibrary/StreamNative.cpp
===
--- sandbox/jlf/trunk/interpreter/streamLibrary/StreamNative.cpp
2011-11-11 04:23:38 UTC (rev 7285)
+++ sandbox/jlf/trunk/interpreter/streamLibrary/StreamNative.cpp
2011-11-11 16:04:41 UTC (rev 7286)
@@ -632,6 +632,8 @@
// position at the end, and set the write position
setPosition(size(), charWritePosition);
+ if (!write_only)
+ {
char char_buffer;
size_t bytesRead;
// read the last character of the buffer.
@@ -651,6 +653,7 @@
/* explicitly set the position */
setPosition(charWritePosition, charWritePosition);
}
+ }
}
lineWritePosition = 0;
lineWriteCharPosition = 0;
@@ -793,6 +796,8 @@
// position at the end, and set the write position
setPosition(size(), charWritePosition);
+ if (!write_only)
+ {
char char_buffer;
size_t bytesRead;
// read the last character of the buffer.
@@ -812,6 +817,7 @@
/* explicitly set the position */
setPosition(charWritePosition, charWritePosition);
}
+ }
}
// set default line positioning
lineWritePosition = 0;
@@ -2384,7 +2390,8 @@
{
// if this is some sort of device, it might be output only
(i.e., a
// printer). Try opening again write only
- if (fileInfo.isDevice())
+ // bug 3274050 : no longer limited to device, a regular file
can
have write-only permissions
+ if (true /*fileInfo.isDevice()*/)
{
if (!open(WR_CREAT, S_IWRITE, shared))
{
@@ -2428,6 +2435,8 @@
// position at the end, and set the write position
setPosition(size(), charWritePosition);
+ if (!write_only)
+ {
char char_buffer;
size_t bytesRead;
// read the last character of the buffer.
@@ -2447,6 +2456,7 @@
/* explicitly set the position */
setPosition(charWritePosition, charWritePosition);
}
+ }
}
/* set default line positioning
Re: [Oorexx-devel] A possible fix for bug 3274050
ok, I will do that.
I see that there is one test case in Stream.testGroup which uses chmod. I
will do something similar to add a test case for the write-only bug.
Jean-Louis
2011/11/11 Rick McGuire object.r...@gmail.com
Unfortunately, I don't have a means at the moment to try out potential
fixes. If you have something that appears to fix the problem, then go
ahead and commit the fix and we can adjust as needed.
Rick
On Fri, Nov 11, 2011 at 11:27 AM, Jean-Louis Faucher
jfaucher...@gmail.com wrote:
ok.
on my side I don't plan to commit in trunk, was just an experimentation.
I prefer to leave you decide what to do :-)
Jean-Louis
2011/11/11 Rick McGuire object.r...@gmail.com
I was looking at something similar, but my Linux system is castors up
at the moment, so I haven't really been able to test anything. I'm
not totally comfortable with the isDevice() test just being commented
out. I think this should be if (write_only || fileInfo.isDevice())
rather than just being an unconditional. It would be wrong to open
any stream as write only if the options were requesting otherwise.
Rick
On Fri, Nov 11, 2011 at 11:08 AM, Jean-Louis Faucher
jfaucher...@gmail.com wrote:
The problem comes from
StreamNative.cpp
const char *StreamInfo::streamOpen(const char *options)
When the O_WRONLY flag is set, ooRexx tries read-write first,
but does not fallback to write-only in case of failure (limited to
device)
After replacing the test isDevice() by true, the open is ok, but...
another problem in this method, when testing if the last character is
ctrl_z.
Since the handle is write-only, the attempt to read the last character
fails
and notReadyError is called.
Fixed by not testing if ctrl_z when write-only.
The same workaround for ctrl_z must be done in
StreamInfo::implicitOpen
StreamInfo::handleOpen
Tested under MacOs, looks good.
Not tested under Linux or Windows.
Not sure if I break something by not testing ctrl_z... For me, ctrl_z
is
Windows specific, no ? is the write-only mode supported under Windows
?
Jean-Louis
-- Forwarded message --
From: jfauc...@users.sourceforge.net
Date: 2011/11/11
Subject: [Oorexx-svn] SF.net SVN: oorexx:[7286]
sandbox/jlf/trunk/interpreter/streamLibrary/ StreamNative.cpp
To: oorexx-...@lists.sourceforge.net
Revision: 7286
http://oorexx.svn.sourceforge.net/oorexx/?rev=7286view=rev
Author: jfaucher
Date: 2011-11-11 16:04:41 + (Fri, 11 Nov 2011)
Log Message:
---
A possible fix for bug 3274050 (to discuss on the dev list)
Modified Paths:
--
sandbox/jlf/trunk/interpreter/streamLibrary/StreamNative.cpp
Modified: sandbox/jlf/trunk/interpreter/streamLibrary/StreamNative.cpp
===
--- sandbox/jlf/trunk/interpreter/streamLibrary/StreamNative.cpp
2011-11-11 04:23:38 UTC (rev 7285)
+++ sandbox/jlf/trunk/interpreter/streamLibrary/StreamNative.cpp
2011-11-11 16:04:41 UTC (rev 7286)
@@ -632,6 +632,8 @@
// position at the end, and set the write position
setPosition(size(), charWritePosition);
+if (!write_only)
+{
char char_buffer;
size_t bytesRead;
// read the last character of the buffer.
@@ -651,6 +653,7 @@
/* explicitly set the position */
setPosition(charWritePosition, charWritePosition);
}
+}
}
lineWritePosition = 0;
lineWriteCharPosition = 0;
@@ -793,6 +796,8 @@
// position at the end, and set the write position
setPosition(size(), charWritePosition);
+if (!write_only)
+{
char char_buffer;
size_t bytesRead;
// read the last character of the buffer.
@@ -812,6 +817,7 @@
/* explicitly set the position */
setPosition(charWritePosition, charWritePosition);
}
+}
}
// set default line positioning
lineWritePosition = 0;
@@ -2384,7 +2390,8 @@
{
// if this is some sort of device, it might be output only
(i.e., a
// printer). Try opening again write only
-if (fileInfo.isDevice())
+// bug 3274050 : no longer limited to device, a regular file
can
have write-only permissions
+if (true /*fileInfo.isDevice()*/)
{
if (!open(WR_CREAT, S_IWRITE, shared))
{
@@ -2428,6 +2435,8 @@
// position at the end, and set the write position
setPosition(size(), charWritePosition);
+if (!write_only)
+{
Re: [Oorexx-devel] A possible fix for bug 3274050
On Fri, Nov 11, 2011 at 8:20 AM, Rick McGuire object.r...@gmail.com wrote:
I was looking at something similar, but my Linux system is castors up
at the moment, so I haven't really been able to test anything. I'm
not totally comfortable with the isDevice() test just being commented
out. I think this should be if (write_only || fileInfo.isDevice())
rather than just being an unconditional.
I agree with Rick here 100% Jean-Louis.
+if (true /*fileInfo.isDevice()*/)
just looks wrong on the face of it. grin
--
Mark Miesfeld
It would be wrong to open
any stream as write only if the options were requesting otherwise.
Rick
On Fri, Nov 11, 2011 at 11:08 AM, Jean-Louis Faucher
jfaucher...@gmail.com wrote:
The problem comes from
StreamNative.cpp
const char *StreamInfo::streamOpen(const char *options)
When the O_WRONLY flag is set, ooRexx tries read-write first,
but does not fallback to write-only in case of failure (limited to
device)
After replacing the test isDevice() by true, the open is ok, but...
another problem in this method, when testing if the last character is
ctrl_z.
Since the handle is write-only, the attempt to read the last character
fails
and notReadyError is called.
Fixed by not testing if ctrl_z when write-only.
The same workaround for ctrl_z must be done in
StreamInfo::implicitOpen
StreamInfo::handleOpen
Tested under MacOs, looks good.
Not tested under Linux or Windows.
Not sure if I break something by not testing ctrl_z... For me, ctrl_z is
Windows specific, no ? is the write-only mode supported under Windows ?
Jean-Louis
-- Forwarded message --
From: jfauc...@users.sourceforge.net
Date: 2011/11/11
Subject: [Oorexx-svn] SF.net SVN: oorexx:[7286]
sandbox/jlf/trunk/interpreter/streamLibrary/ StreamNative.cpp
To: oorexx-...@lists.sourceforge.net
Revision: 7286
http://oorexx.svn.sourceforge.net/oorexx/?rev=7286view=rev
Author: jfaucher
Date: 2011-11-11 16:04:41 + (Fri, 11 Nov 2011)
Log Message:
---
A possible fix for bug 3274050 (to discuss on the dev list)
Modified Paths:
--
sandbox/jlf/trunk/interpreter/streamLibrary/StreamNative.cpp
Modified: sandbox/jlf/trunk/interpreter/streamLibrary/StreamNative.cpp
===
--- sandbox/jlf/trunk/interpreter/streamLibrary/StreamNative.cpp
2011-11-11 04:23:38 UTC (rev 7285)
+++ sandbox/jlf/trunk/interpreter/streamLibrary/StreamNative.cpp
2011-11-11 16:04:41 UTC (rev 7286)
@@ -632,6 +632,8 @@
// position at the end, and set the write position
setPosition(size(), charWritePosition);
+if (!write_only)
+{
char char_buffer;
size_t bytesRead;
// read the last character of the buffer.
@@ -651,6 +653,7 @@
/* explicitly set the position */
setPosition(charWritePosition, charWritePosition);
}
+}
}
lineWritePosition = 0;
lineWriteCharPosition = 0;
@@ -793,6 +796,8 @@
// position at the end, and set the write position
setPosition(size(), charWritePosition);
+if (!write_only)
+{
char char_buffer;
size_t bytesRead;
// read the last character of the buffer.
@@ -812,6 +817,7 @@
/* explicitly set the position */
setPosition(charWritePosition, charWritePosition);
}
+}
}
// set default line positioning
lineWritePosition = 0;
@@ -2384,7 +2390,8 @@
{
// if this is some sort of device, it might be output only
(i.e., a
// printer). Try opening again write only
-if (fileInfo.isDevice())
+// bug 3274050 : no longer limited to device, a regular file can
have write-only permissions
+if (true /*fileInfo.isDevice()*/)
{
if (!open(WR_CREAT, S_IWRITE, shared))
{
@@ -2428,6 +2435,8 @@
// position at the end, and set the write position
setPosition(size(), charWritePosition);
+if (!write_only)
+{
char char_buffer;
size_t bytesRead;
// read the last character of the buffer.
@@ -2447,6 +2456,7 @@
/* explicitly set the position */
setPosition(charWritePosition, charWritePosition);
}
+}
}
/* set default line positioning */
lineWritePosition = 0;
This was sent by the SourceForge.net collaborative development platform,
the
world's largest Open Source development site.
Re: [Oorexx-devel] A possible fix for bug 3274050
On Fri, Nov 11, 2011 at 8:08 AM, Jean-Louis Faucher jfaucher...@gmail.comwrote: After replacing the test isDevice() by true, the open is ok, but... ... Tested under MacOs, looks good. Not tested under Linux or Windows. Not sure if I break something by not testing ctrl_z... For me, ctrl_z is Windows specific, no ? is the write-only mode supported under Windows ? Opening a file for write only is supported under Windows. ctrl_z is a hold over from DOS I think. I believe I read that the operating system ignores it now and goes by the size of the file. I.e. if you have a ctrl-z at position 100, but the file size is 200, the OS uses 200. I say commit the fix and I'll try to get some time to test it on Windows / look more closely at the ctrl-z issue. -- Mark Miesfeld -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] A possible fix for bug 3274050
ctrl_z is a hold over from CP/M-80 at least. CP/M didn't have any sort of counter or pointer to tell where the data ended in the last allocated disk block, so a marker was used. I don't know why ctrl_z was chosen. Ctrl_\ , the ASCII file separator charter would have seemed to be a better choice. I'm sure they had their reasons. Bruce On Nov 11, 2011, at 9:43 AM, Mark Miesfeld wrote: On Fri, Nov 11, 2011 at 8:08 AM, Jean-Louis Faucher jfaucher...@gmail.com wrote: After replacing the test isDevice() by true, the open is ok, but... ... Tested under MacOs, looks good. Not tested under Linux or Windows. Not sure if I break something by not testing ctrl_z... For me, ctrl_z is Windows specific, no ? is the write-only mode supported under Windows ? Opening a file for write only is supported under Windows. ctrl_z is a hold over from DOS I think. I believe I read that the operating system ignores it now and goes by the size of the file. I.e. if you have a ctrl-z at position 100, but the file size is 200, the OS uses 200. I say commit the fix and I'll try to get some time to test it on Windows / look more closely at the ctrl-z issue. -- Mark Miesfeld -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
