Я не про мосты, а про то, что in_addr, так и остался 4 байта. И функция inet_aton так и работает с адресами v4.
А для v6 и структура in6_addr, и функция новая inet_pton, которая, впрочем, теперь реализована «форматно» независимая, хотя сейчас поддерживает только два формата: ipv4 и ipv6.
странные у вас рассуждения.
int32_t a,b,c;
c=a+b;
И вам не все ли равно как компилятор это обработает на разных платформах? Ну да, на 8-битных будет немного медленно. Но кмк сдвиги через С и сложение с использованием С как раз и предназначены для арифметики с разрядностью больше, чем умеет АЛУ в явном виде.
А для чего конкретно? Ну, например, crc-32 посчитать.
Заменяются, но новые системы прекрасно уживаются со старыми стандартами. А не используют несовместимую со старой новую адресацию.
dos как есть, кстати, берите freedos и ностальгируйте. А с некоторыми оговорками приложения дос неплохо так работали под вин. Пока не появился far и wc/tc в окошке вполне мог работать nc/vc/dn и т.д. Пока под вин не появилось достаточно приложений многие вообще ее использовали как многозадачный дос.
И вы опять заявляете о необходимости изменений, что не вызывает возражений, вместо того, что бы говорить о вариантах реализации этих изменений. И ваши же примеры как раз показывают как сделать новое не сломав старое, а дав ему спокойно доработать свой срок.
Вы опять используете «здесь и сейчас», а не «там и тогда». И речь не целесообразности 64-битного времени, а о вариантах реализации этого.
Кстати, ваш пример с ip-адресами просто в десяточку: v4 оставили как есть, хотя по вашей логике, видимо, следовало бы добить его еще 4 октетами или расширить октеты с 8 бит до 16. Или сразу до 32. Или добавить еще 4 октета и все расширить до 16 бит.
Но тем не менее, вместо этого сделали новую адресацию.
Ваши рассуждения хороши, когда число ящиков можно пересчитать по пальцам одной руки опытного фрезеровщика. А когда число и цвет ящиков неограниченны, нужен заранее определенный стандарт. Который если и меняется, то всегда можно было бы определить какая именно версия стандарта используется, а следовательно какие данные и какого размера будут использованы.
Абстрагируйтесь от сегодня. И даже от завтра. Попробуйте принять решение, находясь в позавчера. long long, по-моему, тоже чуть позже появилось.
Конечно, в общем случае можно использовать и 64-битные значения и даже 1024-битные, но речь не о размерности, а со сохранении размерности между системами.
Вы хотите, что бы дискета, записанная на одном устройстве прочиталась на другом?
Я не могу вам объяснить то, что вы сами себе придумали.
Давайте вы лучше мне расскажите: есть time_t, short, int, long. Какой надо выбрать для передачи информации о времени в другое устройство?
[u]intN_t, напомню, появится в далеком будущем, которое для вас не менее далекое прошлое.
зы. А мух от котлет я отделяю везде, где только можно.
Этот язык с самого начала был высокоуровневым ассемблером, достаточно сравнить с другими языками насколько легко и непринужденно он позволяет выстрелить себе в ногу, причем многократно.
Определение авторов: C is a relatively «low level» language. This characterization is not pejorative; it simply means that C deals with the same sort of objects that
most computers do, namely character, number, and addresses.
Стандартные типы для того и нужны, что бы не писать уникальный код под каждую систему и архитектуру там, где может быть реализован общий алгоритм. Я всегда отделяю форматно-, системно-, аппаратно-зависимые куски от основного кода, разве это не логично?
А вы, повторю, ссылаетесь на стандарт, который появился спустя 25 лет.
А у вас есть текст posix 1003.1-1989? Ну или 1990? Даже не смотря на то, что это уже +15 лет к появлению языка.
Для вас, м.б., это глубокое прошлое, но я начинал с конструкций f(v) int v; {...}.
Только вот для людей «старой закалки» единственным реально «машинно-независимым» типом данных являются типы c явным указанием размерности.
А вот и не угадали. Типы с явным указанием размерности появились, емнип, только через 20 лет, в C99. Это относительно новая фича. А до этого предлагалось «make an appropriate set of choices of short, int, and long for each host machine».
Языковых средств хватало, *_t, повторю, не являются новыми типами, это синонимы к существующим. К тем самым char/short/int/long, для того, что бы получить нужный диапазон значений не зависимо от архитектуры. И во всех функциях (в пределах архитектуры) int будет одинаковый. Другое дело, что там не везде int, а тот тип, который дает нужный диапазон значений. Прикрутив поддержку 64Гб заменой типа вы тут же отломали поддержку 4Гб, и не сможете смонтировать старый диск, потому что где на нем было 16 бит, вы теперь ожидаете увидеть 32, а вместо 32 — 64.
Стандарт для того и нужен, что бы не было разночтений. А иначе это не стандарт.
зы. массовое решение не означает правильное решение.
Внутри вашей разработки вы можете крутить типами как угодно. Я говорил об обмене с внешним миром. И если вы не можете при этом использовать «машинно-независимый тип», то зачем он нужен?
А вы предлагаете именно это. Да еще и с предельно четким дублированием функционала.
Ну так можно договориться до того, что short/int/long — это дублирование функционала.
Но, боюсь, позиция ваша в меньшинстве.
Даже не сомневаюсь, что миллионы мух не могут ошибаться. :)
Речь не о большинстве/меньшинстве, и не о моем уходе в подполье, а о самом типе данных в целях использования для обмена информацией в гетерогенных системах.
четко проектировать свои решения
Я не очень хочу придумывать свои стандарты, мне было бы намного проще воспользоваться имеющимися. Но так получается, что эти стандарты так стандартны, что в любой момент все может поломаться.
Как говорится: в наше время никому верить нельзя. :)
с того, что у вас наружу не торчит «машинно-независимый тип». А что у вас внутри программы — это ваше личное дело, поскольку оно под вашим полным контролем.
А вот с фискальным накопителем — крайне неудачный пример.
Крайне удачный, поскольку фискальный регистратор это не фискальный накопитель (т.е. фискальная память) и, грубо говоря, и есть касса, только в виде принтера, который можно подключить к любому ПК. В ФР стоит и сменный блок ФП и сменный блок ЭКЛЗ. И проработать ФР может до тех пор, пока реализация очередной законодательной поправки не потребует аппаратных изменений.
Трекер, камера или замок в ответственном месте тоже будут заменены.
Да, потому что новая версия софта не будет с ними работать. И вас вынудят их поменять.
И упомянутый вами принт-сервер. Разве что-то поменяется если его часы собьются?
В нем нет поддержки бесклассовых сетей, маска сети высчитывается автоматически на основе класса адреса. И для 192.168.x.x она всегда /24.
Это был не пример использования time_t, а пример отсутствия обновления прошивки под новые стандарты. Хотя RFC с CIDR приблизительно того же года, что и девайс.
Вы тут K&R цитировали, а сами в открытую противоречите идеологии UNIX.
i8051 рулит мотором, и ему глубоко до лампочки до текущего времени в UTC или любом ином формате.
А еще он рулит фискальным регистратором, и ему ооочень не до лампочки насчет текущего времени. Как и проверяющему из налоговой. :)
Новомодный IoT уже знает о том, что time_t 64-разрядный.
Ну да, ну да… вот только что попробовал: arduino ide 1.8.5: 02 04 04, это sizeof int, long, time_t
Да и опять — самому IoT плевать на время.
Трекеру, камере, да банальному замку СКД — вряд ли плевать на время. IoT это же не только светодиодиками весело мигать, да свет в доме через облако со смартфона включать. А прожить встраеваемое решение может очень долго. Упомянутый мной принт-сервер года так 96-97.
А вот тянуть до последнего
Я же не предлагаю тянуть до последнего, а просто добавить новый тип. И функции дублировать не надо, достаточно для каждой иметь небольшой врапер, который на входе из 32 бит сделает 64, а потом на выходе обрежет обратно. В конце концов есть же lib64 рядом с lib, а programm files (x86) рядом с programm files. И ничего, никто вроде не сдох?
Тогда вы поимеете проблемы, если другая сторона не под вашим контролем и еще не перешла на 64-битное время.
вычислительные мощности позволят сделать его 64-разрядным.
Это можно было сделать и по-другому и я тоже раньше думал что проблема 2038 для тех кто использовал time_t — не проблема. Перекомпилировал и все. Пока мне в голову не пришло, что нет возможности всех заставить в одно мгновение, или хотя бы в разумно короткий срок, перекомпилировать свой софт и конвертировать хранимые данные. А некоторые, по ряду причин, в принципе этого делать не будут. Потому что «снято с производства».
Все же десктопно-серверно-мобильный парк уже 64 разрядный. А отстающим достаточно пересобрать
Вы выбрасываете огромный пласт встраиваемых и прочих промышленных систем, которых рядом с вами м.б. больше, чем десктопов и мобил. В т.ч. и новомодный IoT, где не то что 64 бита где-то за горизонтом, так и 8-битные никуда уходить особо не планируют. Древний 8051 до сих пор in production.
И перекомпилировать нечего. Прошивка проприетарная, производителю нафиг не надо. Даже если производитель еще живой, а не закрылся/продался/и т.д.
У меня есть принт-сервер, который tcp/ip уже поддерживает, а classless еще нет. И если сетка не /24 — ну извините. И, естественно, никакой новой прошивки нет и не будет.
Когда появился time_t еще не было intN_t. И, возможно, было бы int32_t time(int32_t *). Но в контексте спора int64_t — машинно-независимый и имеет постоянную разрядность, в отличии от time_t.
А выше предложение с long выглядит странной альтернативой. Я очевидно не могу воткнуть его в пакет — это очевидный слом протокольного слоя.
В пакет типа rpm или в пакет типа datagram? Предложение-то было не сейчас использовать лонг, а в принципе не определять time_t. И тогда никаких варнингов не будет.
я считаю такие типы машинозависимыми
В этом у нас с вами и расхождение: я считаю их машинно-независимыми, как intN_t. За исключением least/fast, которые явно определены как машинно-зависимые.
Возможно, мое негодование насчет time_t вызвано тем, что size_t или pid_t, в целом, остаются внутри платформы. А unixtime стал машинно-независимым стандартом настолько, что даже БД поддерживают такой тип данных.
зы. А с точки зрения экономии 4 байт можно было определить как unsigned, кмк это не поломало бы почти ничего, но дало бы еще 68 лет.
Да приблизительно столько же, сколько 64-битный лонг. И уж точно 128-битный лонг не окажется хуже.
Это как-то вам поломает код? Или вам очень жалко лишних 4 байта?
Да, переход time_t c 32 на 64 бита прошел
Да дело не в переходе, а в том, что машинно-независимые типы стали машинно-зависимыми. У K&R про какой-то тип из *_t было пояснение что «на нашем компе это short int, а на ваше м.б. не так, поэтому лучше использовать typedef». И понятно, что задумка в том — что бы везде было одинаково.
Я предпочту получить ошибку или предупреждение при компиляции на несоответствие типов, нежели успешную компиляцию при которой, для примера, 0x80000000 перестанет быть отрицательным числом.
Смысл typedef в возможности определить пользовательский тип.
во-первых typedef не определяет новые типы, а только синонимы к существующим, а во-вторых:
"… The first is to parameterize a program against portability problems. If typedefs are used for data types that may be machine-dependent, only the typedef s need change when the program is moved."
И что есть критерий нормальности?
Компилируется и работает. Или у вас есть другой критерий?
На уровне исходного когда и с short/int/long все нормально. long t=time(NULL) перенесется ничуть не хуже, чем time_t t=time(NULL).
А смысл typedef — машинно-независимые типы.
А вообще, по-хорошему, стоит использовать даже не uint32_t, а uint_fast32_t.
Не стоит. Потому что нужно именно 32 бита, не минимум 32 бита. Иначе у вас вся структура разъедется. По тем же причинам стоило бы вломить тем, кто вместо нового типа time64_t изменил разрядность time_t поломав двоичную совместимость, что напрочь убивает смысл использовать подобный тип.
А еще не надо забывать, что компилятор может поля структуры выровнять на границу слова, что бы доступ ускорить… Помню я тот давний зимний вечер, лет 20 назад, когда я узнал о существовании директивы #pragma pack. Потому что вместо заголовка bmp-файла считывалась какая-то лажа.
А для v6 и структура in6_addr, и функция новая inet_pton, которая, впрочем, теперь реализована «форматно» независимая, хотя сейчас поддерживает только два формата: ipv4 и ipv6.
int32_t a,b,c;
c=a+b;
И вам не все ли равно как компилятор это обработает на разных платформах? Ну да, на 8-битных будет немного медленно. Но кмк сдвиги через С и сложение с использованием С как раз и предназначены для арифметики с разрядностью больше, чем умеет АЛУ в явном виде.
А для чего конкретно? Ну, например, crc-32 посчитать.
dos как есть, кстати, берите freedos и ностальгируйте. А с некоторыми оговорками приложения дос неплохо так работали под вин. Пока не появился far и wc/tc в окошке вполне мог работать nc/vc/dn и т.д. Пока под вин не появилось достаточно приложений многие вообще ее использовали как многозадачный дос.
И вы опять заявляете о необходимости изменений, что не вызывает возражений, вместо того, что бы говорить о вариантах реализации этих изменений. И ваши же примеры как раз показывают как сделать новое не сломав старое, а дав ему спокойно доработать свой срок.
Кстати, ваш пример с ip-адресами просто в десяточку: v4 оставили как есть, хотя по вашей логике, видимо, следовало бы добить его еще 4 октетами или расширить октеты с 8 бит до 16. Или сразу до 32. Или добавить еще 4 октета и все расширить до 16 бит.
Но тем не менее, вместо этого сделали новую адресацию.
Абстрагируйтесь от сегодня. И даже от завтра. Попробуйте принять решение, находясь в позавчера. long long, по-моему, тоже чуть позже появилось.
Конечно, в общем случае можно использовать и 64-битные значения и даже 1024-битные, но речь не о размерности, а со сохранении размерности между системами.
Вы хотите, что бы дискета, записанная на одном устройстве прочиталась на другом?
Давайте вы лучше мне расскажите: есть time_t, short, int, long. Какой надо выбрать для передачи информации о времени в другое устройство?
[u]intN_t, напомню, появится в далеком будущем, которое для вас не менее далекое прошлое.
зы. А мух от котлет я отделяю везде, где только можно.
Определение авторов: C is a relatively «low level» language. This characterization is not pejorative; it simply means that C deals with the same sort of objects that
most computers do, namely character, number, and addresses.
Стандартные типы для того и нужны, что бы не писать уникальный код под каждую систему и архитектуру там, где может быть реализован общий алгоритм. Я всегда отделяю форматно-, системно-, аппаратно-зависимые куски от основного кода, разве это не логично?
А вы, повторю, ссылаетесь на стандарт, который появился спустя 25 лет.
Для вас, м.б., это глубокое прошлое, но я начинал с конструкций f(v) int v; {...}.
А вот и не угадали. Типы с явным указанием размерности появились, емнип, только через 20 лет, в C99. Это относительно новая фича. А до этого предлагалось «make an appropriate set of choices of short, int, and long for each host machine».
Языковых средств хватало, *_t, повторю, не являются новыми типами, это синонимы к существующим. К тем самым char/short/int/long, для того, что бы получить нужный диапазон значений не зависимо от архитектуры. И во всех функциях (в пределах архитектуры) int будет одинаковый. Другое дело, что там не везде int, а тот тип, который дает нужный диапазон значений. Прикрутив поддержку 64Гб заменой типа вы тут же отломали поддержку 4Гб, и не сможете смонтировать старый диск, потому что где на нем было 16 бит, вы теперь ожидаете увидеть 32, а вместо 32 — 64.
Стандарт для того и нужен, что бы не было разночтений. А иначе это не стандарт.
зы. массовое решение не означает правильное решение.
Внутри вашей разработки вы можете крутить типами как угодно. Я говорил об обмене с внешним миром. И если вы не можете при этом использовать «машинно-независимый тип», то зачем он нужен?
Ну так можно договориться до того, что short/int/long — это дублирование функционала.
Даже не сомневаюсь, что миллионы мух не могут ошибаться. :)
Речь не о большинстве/меньшинстве, и не о моем уходе в подполье, а о самом типе данных в целях использования для обмена информацией в гетерогенных системах.
Я не очень хочу придумывать свои стандарты, мне было бы намного проще воспользоваться имеющимися. Но так получается, что эти стандарты так стандартны, что в любой момент все может поломаться.
Как говорится: в наше время никому верить нельзя. :)
с того, что у вас наружу не торчит «машинно-независимый тип». А что у вас внутри программы — это ваше личное дело, поскольку оно под вашим полным контролем.
Крайне удачный, поскольку фискальный регистратор это не фискальный накопитель (т.е. фискальная память) и, грубо говоря, и есть касса, только в виде принтера, который можно подключить к любому ПК. В ФР стоит и сменный блок ФП и сменный блок ЭКЛЗ. И проработать ФР может до тех пор, пока реализация очередной законодательной поправки не потребует аппаратных изменений.
Да, потому что новая версия софта не будет с ними работать. И вас вынудят их поменять.
В нем нет поддержки бесклассовых сетей, маска сети высчитывается автоматически на основе класса адреса. И для 192.168.x.x она всегда /24.
Это был не пример использования time_t, а пример отсутствия обновления прошивки под новые стандарты. Хотя RFC с CIDR приблизительно того же года, что и девайс.
А что, простите, не так?
Это читтерство. Не time_t.
А еще он рулит фискальным регистратором, и ему ооочень не до лампочки насчет текущего времени. Как и проверяющему из налоговой. :)
Ну да, ну да… вот только что попробовал: arduino ide 1.8.5: 02 04 04, это sizeof int, long, time_t
Трекеру, камере, да банальному замку СКД — вряд ли плевать на время. IoT это же не только светодиодиками весело мигать, да свет в доме через облако со смартфона включать. А прожить встраеваемое решение может очень долго. Упомянутый мной принт-сервер года так 96-97.
Я же не предлагаю тянуть до последнего, а просто добавить новый тип. И функции дублировать не надо, достаточно для каждой иметь небольшой врапер, который на входе из 32 бит сделает 64, а потом на выходе обрежет обратно. В конце концов есть же lib64 рядом с lib, а programm files (x86) рядом с programm files. И ничего, никто вроде не сдох?
Тогда вы поимеете проблемы, если другая сторона не под вашим контролем и еще не перешла на 64-битное время.
Это можно было сделать и по-другому и я тоже раньше думал что проблема 2038 для тех кто использовал time_t — не проблема. Перекомпилировал и все. Пока мне в голову не пришло, что нет возможности всех заставить в одно мгновение, или хотя бы в разумно короткий срок, перекомпилировать свой софт и конвертировать хранимые данные. А некоторые, по ряду причин, в принципе этого делать не будут. Потому что «снято с производства».
Вы выбрасываете огромный пласт встраиваемых и прочих промышленных систем, которых рядом с вами м.б. больше, чем десктопов и мобил. В т.ч. и новомодный IoT, где не то что 64 бита где-то за горизонтом, так и 8-битные никуда уходить особо не планируют. Древний 8051 до сих пор in production.
И перекомпилировать нечего. Прошивка проприетарная, производителю нафиг не надо. Даже если производитель еще живой, а не закрылся/продался/и т.д.
У меня есть принт-сервер, который tcp/ip уже поддерживает, а classless еще нет. И если сетка не /24 — ну извините. И, естественно, никакой новой прошивки нет и не будет.
Когда появился time_t еще не было intN_t. И, возможно, было бы int32_t time(int32_t *). Но в контексте спора int64_t — машинно-независимый и имеет постоянную разрядность, в отличии от time_t.
В пакет типа rpm или в пакет типа datagram? Предложение-то было не сейчас использовать лонг, а в принципе не определять time_t. И тогда никаких варнингов не будет.
В этом у нас с вами и расхождение: я считаю их машинно-независимыми, как intN_t. За исключением least/fast, которые явно определены как машинно-зависимые.
Возможно, мое негодование насчет time_t вызвано тем, что size_t или pid_t, в целом, остаются внутри платформы. А unixtime стал машинно-независимым стандартом настолько, что даже БД поддерживают такой тип данных.
зы. А с точки зрения экономии 4 байт можно было определить как unsigned, кмк это не поломало бы почти ничего, но дало бы еще 68 лет.
Вот им-то я и предлагаю вломить :)
Да приблизительно столько же, сколько 64-битный лонг. И уж точно 128-битный лонг не окажется хуже.
Это как-то вам поломает код? Или вам очень жалко лишних 4 байта?
Да дело не в переходе, а в том, что машинно-независимые типы стали машинно-зависимыми. У K&R про какой-то тип из *_t было пояснение что «на нашем компе это short int, а на ваше м.б. не так, поэтому лучше использовать typedef». И понятно, что задумка в том — что бы везде было одинаково.
Я предпочту получить ошибку или предупреждение при компиляции на несоответствие типов, нежели успешную компиляцию при которой, для примера, 0x80000000 перестанет быть отрицательным числом.
Моему. Потому что это K&R. Им виднее, что они придумали. :)
Именно. Вот только для чего его менять-то? Как думаете?
time_t так и определен. Только для чего его определять, если на разных архитектурах он будет разный?
Ну тогда попробуйте убедить меня что time_t имеет преимущества перед long.
во-первых typedef не определяет новые типы, а только синонимы к существующим, а во-вторых:
"… The first is to parameterize a program against portability problems. If typedefs are used for data types that may be machine-dependent, only the typedef s need change when the program is moved."
Компилируется и работает. Или у вас есть другой критерий?
На уровне исходного когда и с short/int/long все нормально. long t=time(NULL) перенесется ничуть не хуже, чем time_t t=time(NULL).
А смысл typedef — машинно-независимые типы.
Не стоит. Потому что нужно именно 32 бита, не минимум 32 бита. Иначе у вас вся структура разъедется. По тем же причинам стоило бы вломить тем, кто вместо нового типа time64_t изменил разрядность time_t поломав двоичную совместимость, что напрочь убивает смысл использовать подобный тип.
А еще не надо забывать, что компилятор может поля структуры выровнять на границу слова, что бы доступ ускорить… Помню я тот давний зимний вечер, лет 20 назад, когда я узнал о существовании директивы #pragma pack. Потому что вместо заголовка bmp-файла считывалась какая-то лажа.