Skip to content
This repository was archived by the owner on Jun 16, 2025. It is now read-only.
This repository was archived by the owner on Jun 16, 2025. It is now read-only.

Should we still support EBCDIC? #742

Description

@krader1961

Coverity pointed out a condition that is always true on ASCII using systems. Which lead @siteshwar to open PR #741. That transformation, however, is only valid on ASCII using systems. There are other places in the code which attempt to support both ASCII and EBCDIC. See, for example, the definition of getop() in src/cmd/ksh93/sh/streval.c. But given all the places in the code which have hardcoded chars like \033 (escape) my confidence is low that the current code will function correctly in an EBCDIC environment.

If we continue to support EBCDIC it should be done via build time tests such as #if ('a' == 97). Probably coupled with formal abstractions and preprocessor symbols. Personally I would just as soon drop whatever support there is for EBCDIC and formally state that ksh only supports ASCII and encodings like ISO-8859 and UNICODE which are compatible with ASCII. Which basically means everything but EBCDIC.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions