Re: encapsulating directory operations

On 2025-06-04, Paul Edwards <mutazilah@gmail.com> wrote:

"Kaz Kylheku" <643-408-1753@kylheku.com> wrote in message
news:20250604121550.286@kylheku.com...

On 2025-06-04, Paul Edwards <mutazilah@gmail.com> wrote:

If I have existing C code that does:
>
fopen("test1.dat", "rb");
fread into buf
if (memcmp(buf + 5, "XYZ", 3) == 0)
>
and test1.dat is in EBCDIC, the above program on the 80386
has been compiled with EBCDIC strings, so it works, and then
now you do:
>
printf("It matches!\n");
>
where do you expect those characters in the printf string - all
currently EBCDIC - to be translated to ASCII on a modern
Windows 10/11 system?

>
I think that in this case you would ideally want the EBCDIC-enabled
compiler to have extensions for working with both character sets.
>
For isntance E"foo" would specify a string object that is
encoded in EBCDIC in the execution environment, whereas
"foo" is ASCII.
>
You could develop a textual preprocesor which implements
this transformation: tokenizes the C well enough to recognize
string literals preceded by E, and translates them to
string literals without E, whose content is EBCDIC bytes.
>
It wouldn't have to be absoultely perfect; only to work
correctly on your small amount of private code.

>
Even assuming the above was technically possible  - what's
wrong with just having a pseudo-bios and OS so that
everything is totally clean?

Nothing; it's just that the OS doesn't match the requirement given in
some above quoted text I was responding to that this is on "modern
Windows 10/11 system" which requires the program output to be
"translated to ASCII".

(There are obvious advantages to working with a widely used,
contemporary system; I don't see it necessary to go into those.)

A C program built on and running on an ASCII system, handling EBCDIC
data, could benefit from having an E"..." string literal feature, as
well as a E' ' character constant feature, either as a compiler
extension or a preprocessing tool, so that in places where EBCDIC text
is being handled, literals in that encoding could be conveniently
specified.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca