Propose a change in open for passing in the file type.

Propose a change in open for passing in the file type.

[Haritha D]

Hi Everyone,
 
Am working on porting git to z/OS. For reference, the pull request am working on https://github.com/git/git/pull/1537.
 
On z/OS there is a notion of file tag attributes. Files can be tagged as binary, ASCII, UTF8, EBCDIC, etc. z/OS uses these attributes to determine if auto-conversion is necessary. It was recommended in PR that we add logic directly to xopen . In order for me to do this in xopen , I have to pass an extra parameter to xopen that specifies the file type. 
 
Ex: 
xopen(output_file, O_CREAT | O_WRONLY | O_TRUNC, 0666);
 
To :
xopen(output_file, O_CREAT | O_WRONLY | O_TRUNC, 0666, BINARY);
 
BINARY: would be an enum value.
 
Would this be okay to do? Or are there other recommendations?
 
Best regards
Haritha

Re: Propose a change in open for passing in the file type.

[Torsten Bögershausen]

On Tue, Dec 12, 2023 at 02:46:04PM +0000, Haritha D wrote:
> Hi Everyone,
>
> Am working on porting git to z/OS. For reference, the pull request am working on https://github.com/git/git/pull/1537.
>
> On z/OS there is a notion of file tag attributes. Files can be tagged as binary, ASCII, UTF8, EBCDIC, etc. z/OS uses these attributes to determine if auto-conversion is necessary. It was recommended in PR that we add logic directly to xopen . In order for me to do this in xopen , I have to pass an extra parameter to xopen that specifies the file type. 
>  
> Ex:
> xopen(output_file, O_CREAT | O_WRONLY | O_TRUNC, 0666);
>
> To :
> xopen(output_file, O_CREAT | O_WRONLY | O_TRUNC, 0666, BINARY);
>
> BINARY: would be an enum value.
>
> Would this be okay to do? Or are there other recommendations?

I think that the suggestion was to embedd the BINARY thing into xopen(),
not to all callers of xopen().

If you have this type of special handling for one specific OS,
call it quirks, if you want, they are better placed in an own file.

Please see e.g. compat/mingw.c as an example, how things are solved
for Git for windows.
Then there are some include files, which re-define things like open(),
if needed.

Another example could be
compat/win32/dirent.c

Where exactly things are placed, is may be a matter of taste,
that may be decided later.
In your case a file like
compat/z_os.c and z_os.h may make clear what this is about to everybody.




>
> Best regards
> Haritha
>
>

Re: Propose a change in open for passing in the file type.

[Đoàn Trần Công Danh]

On 2023-12-12 14:46:04+0000, Haritha D <Harithamma.D@ibm.com> wrote:
> Hi Everyone,
>  
> Am working on porting git to z/OS. For reference, the pull request am working on https://github.com/git/git/pull/1537.
>  
> On z/OS there is a notion of file tag attributes. Files can be
> tagged as binary, ASCII, UTF8, EBCDIC, etc. z/OS uses these
> attributes to determine if auto-conversion is necessary. It was
> recommended in PR that we add logic directly to xopen . In order for
> me to do this in xopen , I have to pass an extra parameter to xopen
> that specifies the file type. 
>  
> Ex: 
> xopen(output_file, O_CREAT | O_WRONLY | O_TRUNC, 0666);
>  
> To :
> xopen(output_file, O_CREAT | O_WRONLY | O_TRUNC, 0666, BINARY);
>  
> BINARY: would be an enum value.

Would it work if you always open the file as BINARY? And let's all the
conversion done by git via some configs (core.encoding?)?

-- 
Danh

Re: Propose a change in open for passing in the file type.

[Torsten Bögershausen]

On Wed, Dec 13, 2023 at 11:17:17AM +0700, Đoàn Trần Công Danh wrote:
[]
> Would it work if you always open the file as BINARY?
Yes, I think so.

> And let's all the
> conversion done by git via some configs (core.encoding?)?
We already have an attribute, "working-tree-encoding", that
can tell Git to do the encoding/reencoding.
The advantage of the .gitattributes file is, that it is
typically commit into the repo, and travels with `git push`
and `git fetch` or `git pull` to the different work stations,
so that everybody has the same settings.

In opposite, config files are always local.
So that everybody should do the same (local) git config.
If that is forgotten for some reason, then different
configurations leads often to some kind of chaos.

But I don't have a z/os sytem to test on.