История изменений

Вот как определить, какая размерность должна быть у str_value когда у нас int плавает туда-сюда, а мы не хотим тратить стек под лишнее?

А что бы было, если бы инт не плавал? Значит существует ситуация, когда в int_value пихают больше положенного (раз допускается выход за проектные пределы при росте int’a) -> переполнение и мусорное значение как итог. Аналог сделать несложно:

char str_value[10];
my_int_to_str(int_value % 1e5, str_value);

Но тут вопрос - а что лучше, мусорное значение с туманной перспективой отлова, или простое обнаружение санитайзером в этой «ловушке»? Т.е. в коде уже есть проблема и она живёт задолго до my_int_to_str().

Мелочи это всё. Меня вот куда больше интересует - почему в std крестов всунули специализации локалонезависмых codecvt фасетов для utf конверсий, но нет специализации для конвертаций между utf-16<->utf-32, очень странно, видимо предлагают делать цепочку из костылей: utf-16->utf-8->utf-32. Почему-то прокси кодировкой является utf-8, я бы понял если бы в этой роли выступал utf-32.

Вот как определить, какая размерность должна быть у str_value когда у нас int плавает туда-сюда, а мы не хотим тратить стек под лишнее?

А что бы было, если бы инт не плавал? Значит существует ситуация, когда в int_value пихают больше положенного (раз допускается выход за проектные размеры при росте int’a) -> переполнение и мусорное значение как итог. Аналог сделать несложно:

char str_value[10];
my_int_to_str(int_value % 1e5, str_value);

Но тут вопрос - а что лучше, мусорное значение с туманной перспективой отлова, или простое обнаружение санитайзером в этой «ловушке»? Т.е. в коде уже есть проблема и она живёт задолго до my_int_to_str().

Мелочи это всё. Меня вот куда больше интересует - почему в std крестов всунули специализации локалонезависмых codecvt фасетов для utf конверсий, но нет специализации для конвертаций между utf-16<->utf-32, очень странно, видимо предлагают делать цепочку из костылей: utf-16->utf-8->utf-32. Почему-то прокси кодировкой является utf-8, я бы понял если бы в этой роли выступал utf-32.

Вот как определить, какая размерность должна быть у str_value когда у нас int плавает туда-сюда, а мы не хотим тратить стек под лишнее?

А что бы было, если бы инт не плавал? Значит существует ситуация, когда в int_value пихают больше положенного -> переполнение и мусорное значение как итог. Аналог сделать несложно:

char str_value[10];
my_int_to_str(int_value % 1e5, str_value);

Но тут вопрос - а что лучше, мусорное значение с туманной перспективой отлова, или простое обнаружение санитайзером в этой «ловушке»? Т.е. в коде уже есть проблема и она живёт задолго до my_int_to_str().

Мелочи это всё. Меня вот куда больше интересует - почему в std крестов всунули специализации локалонезависмых codecvt фасетов для utf конверсий, но нет специализации для конвертаций между utf-16<->utf-32, очень странно, видимо предлагают делать цепочку из костылей: utf-16->utf-8->utf-32. Почему-то прокси кодировкой является utf-8, я бы понял если бы в этой роли выступал utf-32.