From: lew.pitcher@digitalfreehold.ca
On Wed, 21 Feb 2024 05:37:45 +0800, Paul Edwards wrote:
> On 21/02/24 01:55, Lew Pitcher wrote:
>> On Tue, 20 Feb 2024 22:25:05 +0800, Paul Edwards wrote:
>>
>>> On 20/02/24 22:14, Lew Pitcher wrote:
>>>> On Tue, 20 Feb 2024 14:51:15 +0800, Paul Edwards wrote:
>>>>
>>>>> Hi.
>>>>>
>>>>> Cygwin has an O_TEXT on the open() call to let
>>>>> "the OS layer" (can be quibbled) that the file
>>>>> is being opened in text mode. And as such, it
>>>>> gives that layer an opportunity to insert CRs.
>>>> [snip]
>>>>> I'd like to add an O_TEXT flag to Linux.[snip]
>>>>> Any suggestions?
>>>>
>>>> Yes, one. Dont.
>>>>
>>>> Microsoft Windows (on top of which Cygwin must run) makes a low-level
>>>> distinction between "binary" files and "text" files. I believe it is
>>>> because Windows guarantees (or must guarantee) certain data
>>>> transformations on text that do not apply to other forms of data.
>>>> (I.e. translating sequences into C newline characters, etc)
>>>>
>>>> HOWEVER, Linux (or, /any/ Unix) makes NO distinction between text
>>>> and binary data, neither in the standard I/O library, nor in the OS
>>>> itself.
>>>>
>>>> You are effectively asking that Linux /NOW/ make such a distinction,
>>>> even if only to ignore the O_TEXT flag that you ask for.
>>>
>>> The C library that most people use already has
>>> that distinction - and it is indeed ignored.
>>> Works perfectly fine.
>>
>> Lets take an accounting...
>>
>> 1) POSIX open() does not make any distinction between "text" and "binary"
>> files
>>
>> 2) Standard C / POSIX fopen() /does/ make a distinction between "text"
>> and "binary" files. POSIX issues a caveat regarding the mode
>> parameter that "The character 'b' shall have no effect, but is allowed
>> for ISO C standard conformance.", referring to the mode character "b"
>> specified by the ISO C standard as indicating that the file should be
>> opened for "binary" I/O, rather than the default "text" I/O.
>>
>> 3) You specifically reference the open() call, not the fopen() call.
>>
>> So, you ask that the open() call, a call that, under Linux and other
>> POSIX-compatible operating systems, makes no distinction between binary
>> and text files, now recognize a flag indicating that the open() should
>> act apon a text file.
>>
>> That leaves the Linux kernel developers with a choice to make: either
>> a) accept your request and add an O_TEXT flag that conditions the I/O
>> for text data, or
>> b) accept your request and add an O_TEXT flag that does nothing, or
>> c) ignore or deny your request
>>
>> Choice (a) would drastically change the behaviour of the open()
>> call, and any existing code that uses open() to access a text file would
>> have to change to specify the O_TEXT flag. I believe that this would
>> be a no-starter, even if the default for O_TEXT would leave behaviour
>> as it currently is.
>>
>> Choice (b) is ... useless. It recognizes a non-issue, and does nothing.
>> It would be a header change that reserves a flag that would be ignored
>> by everyone.
>
> Almost everyone.
>
> PDOS/386 would use it.
If PDOS/386 needs it, then PDOS/386 probably should use it.
However, the needs of PDOS/386 aren't the needs of Linux or POSIX, and
neither Linux in particular, nor POSIX in general, need bother with
it.
If you are concerned with PDOS/386 being able to use source code written
to the POSIX standard, then I suggest that you select the value and
treatment of your O_TEXT flag to work in absence, as POSIX code won't
have it or use it.
The alternative is to specify that such a flag /is/ required for PDOS/386,
which restricts you to using code written specifically for PDOS/386, and
not the more general-purpose and widely available POSIX standard.
[snip]
Best of luck.
--
Lew Pitcher
"In Skills We Trust"
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
