tldr: этот пакет SYS.STANDARD - он "живой" или "справочный"?
Мое исследование говорит, что справочный и написан в псевдокоде. В нем есть ошибки и неверные посылы, поэтому в отличие от настоящих исходников он не может считаться истиной в последней инстанции. Все же, есть польза от его прочтения.

Я почитал SYS.STANDARD на досуге, там есть немало любопытных приемчиков и комментариев.
Заметил некоторые нестыковки, как с документацией так и с функционалом по факту, поэтому возник вопрос в [subj].

Нестыковка с документацией:
В пакете STANDARD написано следующее:



у меня в версии 11.2 PL/SQL тип PLS_/BINARY_INTEGER определен как ограниченный подтип NUMBER, что есть десятичное число переменной длины. Документация обещает что тип BINARY_INTEGER (также PLS_INTEGER) это 32-битные переменные, которые хранятся в естественном для компьютера двоичном формате и быстрее работают с арифметикой.
Поскольку dump() в PL/SQL не доступен, я не смог проверить напрямик как BINARY_INTEGER хранится в памяти.
Однако по косвенным признакам (скорость исполнения бит операций над PLS_INTEGER в разы быстрее), документация права.

Нестыковка с фактом:
В пакете определены две полиморфные функции, с разными типами параметров.



Из практики я знаю, что попытка вызова полиморфных функций с null параметром даст ошибку компиляции PLS-00307.
Однако, я могу вызывать bitand(null,null) без ошибок, т.е. эта функция определена не так, как записано в пакете STANDARD.

Вот еще более очевидный пример несоответствия факту:



- синтаксическая ошибка, одинарные кавычки.
- запрещенная операция, для подтипов NUMBER запрещен диапазон (PLS-00572: improper constraint form used)
- n binary_integer := -2147483648 ; -- присваивание вне диапазона значений работает, ошибки нет.

Моя догадка, что этот пакет компилируется совсем другим компилятором, который понимает определение операторов, прагму 'interface' и кавычки в запрещенных определениях подтипов. Судя по присутствию восклицаний и имен разработчиков в комментариях, этот файл не сильно чистили для публики. Просто его нельзя воспринимать как PL/SQL код и делать выводы как если бы он был таковым.

Не думал что кого-то заденет слово "практика". Я имел в виду из прикладного эксперимента, а не из теоретических рассуждений основанных на богатом жизненном опыте SQL. Ибо с позиции SQL-стажа я рассуждать пока не могу, а вот эксперимент - легко.

В этом конкретном примере, я заметил что декларации одной из функций в STANDARD не объясняют поведение моей системы.



Из практики (о ней чуть ниже) я знаю, что в этом случае вызов bitand(null,null) должен быть пойман на стадии компиляции, однако это не происходит.



Эксперимент: я создал пакет "nonstd" с двумя функциями с аналогичными сигнатурами. Имя поменял на MySum.




Выводы в начале темы. Если кто-то хочет проверить на своей платформе, код ниже.

Это утверждение не сочетается с наличием синтаксических ошибок в SYS.STANDARD.
К примеру,


не компилируется по двум причинам, указанным в первом сообщении.

Если бы компилировалось, то присваивание


выдавало бы ошибку.

Каждый может посмотреть в свой SYS.STANDARD и убедиться что это так, по крайней мере для 11.2.

Вы можете привести какое-либо проверяемое обоснование вашего утверждения?

Признаю ошибку.
Мой эксперимент был проведен неверно, т.к. я не знал о разнице между SQL bitand() и PL/SQL bitand(). Теперь знаю.
Этот конкретный довод считать недействительным.

Когда читаешь дискуссию с середины, она кажется вырванной из контекста.
Посмотрите в первом сообщении темы, там в первой дюжине строк все указано, в том числе

subtype INTEGER is NUMBER(38,0);

Это также и мое заключение. Например, тип NUMBER_BASE или декларация операторов - попытки их использовать в своем модуле дают сообщение что это только для "STANDARD" и ни для кого другого. Тут вряд ли есть два мнения - сам Оракл в ошибке говорит об особом статусе пакета STANDARD, упоминая его по имени:

PLS-00504: type NUMBER_BASE may not be used outside of package STANDARD

Далее, исходя из конфликта между текстом SYS.STANDARD (где, к примеру, PLS_INTEGER показан как субтип NUMBER) и реальностью (где PLS_INTEGER использует двоичный формат), и некоторых других наблюдений, я думаю что STANDARD может быть полезен для обучения - как создатели делают некоторые вещи, но на него нельзя полагаться как на истину в последней инстанции, как это бывает с open source, или например API header files.

Другими словами - поскольку STANDARD/spec содержит некоторые лживые декларации, он не являются определяющим для поведения компилятора, и я подозреваю что компилятор моего сервера не смотрит туда вообще, а руководствуется встроенными правилами.

Насчет тела SYS.STANDARD/body я пока не уверен. Похоже, что оно тоже нерабочее, в отличие от других wrapped системных пакетов, и было включено только для образования. Там тоже есть что почитать.

Я до недавнего времени слышал, но не встречался, т.к. с плавающей точкой не работал.

Поскольку (согласно Ораклу и вопреки тексту STANDARD/spec) BINARY_INTEGER это двоичная 32-битная переменная, отрицательный ноль там быть не должен.

Проверим, ибо эксперимент важнее рассуждений:



Печатает -1073741824

Вывод - как все другие 32-битные двоичные числа со знаком, BINARY_INTEGER использует интервал (-2147483648,2147483647).
Декларация в STANDARD была сделана симметричной или для красоты, или в попытке предотвратить exception при смене знака.
Но это не сработало: