From: mutazilah@gmail.com
On 22/02/24 23:34, Richard Kettlewell wrote:
> Paul Edwards writes:
>> On 22/02/24 17:57, Richard Kettlewell wrote:
>>> Paul Edwards writes:
>>
>>>> Cygwin is a correct example, I believe.
>>>>
>>>> And Cygwin doesn't change the behavior of Linux ELF
>>>> executables either.
>>>
>>> AFAIK it can’t run them at all, so I don’t know why that would be
>>> relevant.
>>
>> That's exactly the point - it doesn't run them.
>> No behavior is being changed by Cygwin either.
>
> The behavior of read() and write() is changed by the O_TEXT flag in
> Cygwin.
Sure - that's existing Cygwin that has *already
changed*. I'm not proposing a change to anything
that already exists.
>>>> Nor does it change the behavior of existing POSIX source code.
>>>
>>> Your use case was C90 programs, not POSIX programs, last time you
>>> mentioned it. Has that changed now?
>>
>> I am the vendor of a C90 runtime library for Linux (PDPCLIB).
>>
>> fopen() necessarily does an open syscall.
>
> If a file was opened with fopen() then the stdio functions (putc, fread,
> etc) can do the newline translation.
I don't WANT to do newline translation when *my*
binary *runs on Linux*.
I want my binaries to behave like any normal Linux program.
So I can't translate in the C library, unless the C
library does some sort of special call to detect the
environment and change behavior accordingly.
I think O_TEXT (with Cygwin prior art) is the neater
solution to this logical problem.
> No need to mess with the behavior
> read() and write().
No need to mess with the behavior of read() and
write() on WHICH SYSTEM?
PDOS/386 is the only thing that would be doing
any messing.
And that's far less mess than the alternative.
> But I think we’ve been round that loop and for
> unknown reasons you still seem to want to do it the hard way.
I don't consider this to be the hard way.
Can you suggest a syscall that I could use to detect
whether I am running under true Linux or PDOS/386
so that I can get the C library to adjust appropriately?
Also, the C library (as with Cygwin) may need to adjust
on a file-by-file basis. ie a syscall needs to be done
"do you want translation to be done on this particular
filename?". open() doesn't have the ability to return
such a status, so I would need to do a similar syscall
to open to find the translation requirements.
And this overhead needs to be added to (my) Linux programs
even when running on Linux - overhead for no purpose,
when a simple flag (that is ignored) is all that is required.
>>>>> If, in fact, you don’t want to add translation to read() and write()
>>>> I do.
>>>
>>> OK, so an ELF executable (that had been modified to use your
>>> hypothetical O_TEXT flag) would get newline translation from read() and
>>> write() when run on your toy OS, but not when run on a real Linux
>>> kernel. There’s the change in behavior.
>>
>> Well you can call it that if you want. But as I said, I think it is
>> odd to call something a change in behavior when the software that
>> would be "changing" hasn't even been written yet. Or at least, the
>> INT 80H open() processing of PDOS/386 hasn't been written yet. Only
>> write to stdout has been written so far. And exit.
>
> Once again, this would go a lot quicker if you didn’t engage in
> “semantic debates”.
I'm not deliberately engaging in semantic debates.
I'm just saying that if that's your definition, then
fine, yes, you're right, by that definition.
>> Also, when you say "the ELF executable that has been modified", I
>> would use the word "built" rather than "modified". I am building new
>> ELF executables according to a hypothetical version of POSIX/Linux
>> that includes a new O_TEXT definition.
>
> If it’s unmodified then it won’t set O_TEXT.
If *WHAT* is unmodified?
An existing ELF binary or one that I will build in
the future?
>>> At any rate we’re back to the issue that you say want to add
>>> Cygwin-style translation to read() and write(), but you also say that
>>> you will only be running programs written in C90, which doesn’t have
>>> open(), so nothing will ever pass O_TEXT and the translation will
>>> never be activated.
>>
>> PDPCLIB will do that.
>
> If you control the C library then you can do the translation in the
> implementation; there is no need to mess with the behavior of
> read() and write().
Not true. The translation needs to be conditional.
So I need a different set of infrastructure to do
translation in the C library.
>> I clearly haven't done a very good job of explaining what I want.
>
> Indeed.
And I'm not doing that deliberately either.
I'm a native English speaker, but this is not the
first time I have failed to convey my message.
Sorry about that, but I don't know where I am
going wrong.
Maybe I can express it in C code/pseudocode.
Solution 1:
fopen()
{
if (strcmp(mode, "r")
{
flag |= O_TEXT; /* cannot be zero!!! */
}
syscall(syscall_open, name, flag);
}
Solution 2:
fopen()
{
if (strcmp(mode, "r")
{
rc = syscall(syscall_os_check);
if (rc == PDOS386) /* as opposed to GENUINE LINUX */
{
rc = syscall(syscall_check_translation, filename);
if (rc == TRANSLATION_REQUIRED)
{
FILE.translation_flag = 1;
}
}
}
}
fwrite()
{
if (FILE.translation_flag)
{
for (...) /* add CRs */
}
}
Let me know if the pseudocode is understandable,
or needs to be fleshed out in even more detail.
BFN. Paul.
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
