To my opinion, that is not odd.
I assume the example is running under Linux or similar. A filename of just one space is legal and different from a filename of two spaces. I am not familiar with the C-interface of open-cobol but when the filename string pic X(02) contains two spaces, a filename of two spaces should be considered. Please compare with the infamous "Program Files" under Windows. Also, I suspect that removing trailing spaces from a string in a C-interface is not the way to go.
So, open cobol should search for a filename of 50 chars when the filename string is pic x(50). A trick can be used to pad the file name with a low-value (a null), or surround the filename (not the path) in quotes, assuming the filename will be parsed first by the kernel.
You may try this by using the command touch, like touch " ". Or touch "myFile " and touch " myFile" and see the differences using the command ls.
Also compare the CALL "SYSTEM" using string, which explicitly mentions that the string should be null-terminated in order to execute.
There is described how to cope with the problem. I find it funny that MicroFocus specifies that the filename should terminate with a blank and NetCobol specifies a blank or null character should be used. They obviously ignore filenames with a space like "Program files". In any case, there are migration problems ahead. Maybe open cobol should comply with big compiler specs?
My euro cent (just one; could be worth $0.02 soon).
Wim Niemans
Op 8 mei 2013, om 18:39 heeft Michael Anderson het volgende geschreven:
Yes, this is odd.
Not sure if it will make a difference in this case, but...... in
C, strings are terminated by null, this is how C determines the
length of the string. Without the null your string may include
more data than you expected, as the program continues walking
though memory until a null is encountered, or until it walks right
off the stack and core dumps.
As a "Best Practice" kinda thing, when calling any "C" subroutine
I first initialize all strings with LOW-VALUES, which is nulls,
and then use string instead of move.
So, I'm curious; If you first MOVE LOW-VALUES (instead of SPACES)
to myfilepath and myfilename, will the results be the same?
Is the "" as the last STRING parm in your second example really a
null char?
If so, then that is why the results are different.
There is a compiler setting to null terminate all string/char
parms in all call statements.
-fnull-param Pass extra NULL terminating pointers on
CALL statements
Just my $0.02
--
Mike.
On 05/08/2013 10:20 AM, studiok wrote:
Hi,
@ Vince
thank you.
@ all
It seems that:
working-storage section.
01 myfilepath pic x(50).
01 myfilename pic x(20).
Procedure division.
move spaces to myfilepath
myfilename
move "something.txt" to myfilename
string
"/abc/def" delimited size
"/xyz/" delimited size
"filename" delimited spaces
into myfilepath
end-string
------------> that is /abc/def/xyz/something.txt
string
"/abc/def" delimited size
"/xyz/" delimited size
'"' delimited size
"filename" delimited spaces
'"' delimited size
into myfilepath
end-string
------------> that is /abc/def/xyz/"something.txt"
get different results. First of which file-status 35. Is it
possible?
marcellom
Il 08/05/2013 14:29, vbcoen ha scritto:
Hi forgot to add this that sets up the
ACAS-xxx vars from the environment that is run before the code
I sent last msg: Procedure: accept ACAS_LEDGERS from Environment
"ACAS_LEDGERS". accept ACAS_IRS from Environment
"ACAS_IRS". accept ACAS_BIN from Environment
"ACAS_BIN". if ACAS_IRS (1:1) = space or ACAS_LEDGERS (1:1) = spaces or ACAS_BIN (1:1) = spaces display ST009 at 0505 with erase eos
highlight display ST008 at 1210 with
foreground-color 3 highlight accept ws-reply at 1243 stop run end-if if ACAS_LEDGERS (1:1) = "/" *> Its
Linux/Unix/OSX move "/" to OS-Delimiter. if ACAS_LEDGERS (1:1) = "\" *> Its
Windoz/Dos-Box move "\" to OS-Delimiter. Vince
------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and
their applications. This 200-page book is written by three acclaimed
leaders in the field. The early access version is available now.
Download your free book today! http://p.sf.net/sfu/neotech_d2d_may
_______________________________________________
open-cobol-list mailing list
address@hidden
https://lists.sourceforge.net/lists/listinfo/open-cobol-list
------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and
their applications. This 200-page book is written by three acclaimed
leaders in the field. The early access version is available now.
Download your free book today! http://p.sf.net/sfu/neotech_d2d_may
_______________________________________________
open-cobol-list mailing list
address@hidden
https://lists.sourceforge.net/lists/listinfo/open-cobol-list
------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and
their applications. This 200-page book is written by three acclaimed
leaders in the field. The early access version is available now.
Download your free book today! http://p.sf.net/sfu/neotech_d2d_may_______________________________________________
open-cobol-list mailing list
address@hidden
https://lists.sourceforge.net/lists/listinfo/open-cobol-list
|