У меня есть вопрос относительно раздела 5.2.4.1 Ограничения перевода в первом American National Standard for Programming languages - C, также известном как ANSI/ISO 9899-1990, ISO/IEC 9899.1990 (E), C89 и т. д. Проще говоря, первый Стандарт ANSI С.
Что такого странного говорит стандарт?
В нем печально известно, что для обработки требуется только соответствующий компилятор C, и я цитирую:
5.2.4.1 Ограничения на перевод
- 6 значащих начальных символов во внешнем идентификаторе
Теперь до боли очевидно, что это неоправданно мало, особенно если учесть, что в C нет ничего похожего на пространство имен. Особенно важно разрешать описательные имена при работе с внешними идентификаторами, видя, как они будут загрязнять все, на что вы ссылаетесь.
Даже стандартная библиотека предписывает функции с более длинными именами, longjmp, tmpfile, strncat. Последнее, strncat, показывает, что им пришлось немного потрудиться, чтобы изобрести имена библиотек, в которых начальные шесть символов были уникальными, вместо, возможно, более логичного strcatn, которое столкнулось бы с strcat.
Почему это все еще проблема для меня?
Мне нравятся старые компьютеры. Я пытаюсь писать программы, которые будут компилироваться и хорошо работать на платформах до C99, чего иногда не существует на моих любимых мишенях. Возможно, мне также нравится пытаться действительно следовать стандарту. Я многое узнал о C99 и C11, просто копаясь в старых стандартах, пытаясь отследить причины определенных ограничений и проблем с реализацией.
Таким образом, даже несмотря на то, что я не знаю ни одного компилятора или компоновщика, который фактически соблюдал бы или накладывал это ограничение, меня все равно раздражает, что я не могу утверждать, что написал строго соответствующий код, если я также хочу использовать разборчивый и неудобочитаемый код. конфликтующие внешние идентификаторы.
Зачем им такое навязывать?
Они начали работу над стандартизацией где-то в начале восьмидесятых и завершили ее в 1988 или 1989 году. Даже в семидесятые и шестидесятые не было какой-либо проблемы для обработки более длинных идентификаторов.
Принимая во внимание, что любой компилятор, желающий соответствовать новому стандарту, должен быть изменен — хотя бы для обновления документации — я не вижу, как было бы неразумно со стороны ANSI поставить ногу и сказать что-то вроде Это 1989 год. уже. Вы должны обработать 31 значащий начальный символ. Это не было бы проблемой для любой платформы, даже древней.
Обратная совместимость?
Из того, что я прочитал при поиске, проблема может исходить от FORTRAN. В ответе на вопрос Какова точная роль значимых символов в C (переменных)?, Джонатан Леффлер пишет:
Часть проблемы могла быть связана с Fortran; для этого требовалась только поддержка 6-символьных имен в одном регистре, поэтому компоновщики в системах, где широко использовался Фортран, не нуждались в поддержке более длинных имен.
Мне это кажется наиболее разумным ответом на прямой вопрос Почему?. Но учитывая, что это ограничение беспокоит меня каждый раз, когда я хочу написать программу, которую теоретически можно было бы собрать на старых системах, хотелось бы узнать еще некоторые подробности.
Вопросы
- Немного покопавшись в треке FORTRAN, я пришел только к теориям и маханиям руками. Какие популярные платформы действительно установили ограничение в 6 символов? Есть ли сверхпопулярный компоновщик, который заставил комитет по стандартам сдвинуться с места?
- Я не настолько стар, чтобы интересоваться подобными подробностями, когда они обсуждались. Этот предел и его обоснование публично обсуждались и защищались? Был ли общественный резонанс или просто молчаливо проигнорировали? Вилы возле штаб-квартиры ANSI?
В конечном счете, ответы на эти вопросы помогут мне решить, насколько плохо я должен спать по ночам из-за того, что давал разумные названия своим функциям.
