Компилятор RealView из комплекта Keil MDK3.70.

Хочется получить текстовую строку в юникоде без нулевого байта.
Строки вида L"Text" включают в себя нулевой байт.
Как от него избавиться?

ЗЫ: и вообще, интересно, как в Си получить строку без нуля на конце?
Конструкция вида 'Text' не прокатывает - компилер ругается на слишком много символов...

static char tst[4] = "ABCD"; // и будет Вам 4 байта

Попробовал:

const char a[4] = { 'A','B','C','D'};

Это я знаю, но это крайний случай, слишком неудобно.
Во первых, надо вручную подсчитывать число знаков, во вторых, юзать неудобоваримую запись текста...
Гораздо приятнее работать с видом "Some text", а всю рутинную работу должен делать компилятор.

Странно, что в Си нет встроенного удобного механизма для исключения лишнего нулевого байта, ведь не всегда же он нужен!

Видимо из-за того, что C++, а не C. Я такое в MSVC без проблем использую, но именно в ".c" файлах. В gcc тоже. А вот с вашим конкретным компилером к сожалению не знаком, но по идее должно работать, если речь все же о Си, а не о плюсах.

так C или C++?
Не поверил, что не фунциклирует
static char a[4] = "ABCD";
и проверил в IAR 4.11B для MSP430 - всё путём

Ну, у вас IAR, а у меня RV и С++...
Интересно, почему в плюсах порезали такую фичу?

А по что тогда дезинформацию вносите?

Вы же спрашивали - "ЗЫ: и вообще, интересно, как в Си получить строку без нуля на конце?"

если в C++ то свой класс такой строки написать.

sizeof() в помощь

не надо, можно написать
char a[] = {...};
а с во вторых - согласен.

В общем, юзаю пока конструкцию L"String text", а затем в программе приходится вычитать 2 байта из длины строки.
Но лишние нули в памяти, конечно же, присутствуют...

Это зачем? Длина строки - strlen - возвращает длину без нулевого символа. Точнее, в Вашем случае, wcslen - таким образом

static wchar_t string[] = L"qwdqwedqwed"; и ничего нигде вручную считать не надо. wcslen даст сразу нужную длину. А вот 2 байта - да.

А у меня эти строки лежат внутри строкового USB дескриптора, и длина всего дескриптора включает в себя, кроме строки, ещё несколько полей.
Поэтому из общей длины дескриптора приходится вычитать 2, чтобы не передавать лишние нули - неизвестно, как их воспримет хост...

Зато, с другой стороны, изменить содержимое строк очень просто

Спасибо за помощь!

Если это единый текстовый "блок", то может быть удобной передача его как одной строки.
Тогда можно записать это одной строкой, но "не совсем обычным способом"(С) (дальше было "- в кредит и за советские рубли"):

Прикольно

Нет, там не только текст, ещё байт длины и байт типа дескриптора.
Вообще не очень удобно в Си (и в Си++) со структурами, в которых данные могут иметь различную длину, не известную на момент декларирования структуры, но известную после присваивания ей значения.
Язык требует указания точного значения прямо во время декларирования...

Насчёт плюсов не скажу, но не был бы так категоричен. В Си действительно с этим сложновато. В C99 появились массивы переменной длины. Такой массив размещается в конце структуры. И с sizeof введены изменения насчёт рантайма.
Посмотрите, авось чего получится
ЗЫ. Если байт длины описывает длину дескриптора, то, ИМХО, это поле лишнее.

Понятно Я, вообще, ассемблером заделал блок дескрипторов... Чтоба не возиться с указанными вопросами и полностью автоматизировать вычисление длин на этапе компиляции....

У меня тоже автоматом всё. Но с ассемблером, как только на Си перешёл, дел стараюсь не иметь
С ним обычно, наоборот, мороки на порядок больше...

Не проще ли написать функцию, которая в качестве параметра получают обычную С-строку и сама затем преобразует в unicode строку и заполняет все необходимые поля usb дескриптора. Я так понимаю, вам это часто приходится проделывать?

Да нет, не часто. Но нужно будет время от времени.
Тоже думал про отдельную функцию, но решил, что всё же она лишняя.

ЗЫ: слава богу ещё, что USB дескрипторы сформатированы в little endian, а то недавно осваивал карты памяти - там сплошной big endian.
Вот где полная задница - компиляторы не имеют механизма смены "индейца", как результат - полная неработоспособность структур с битовыми полями - всё пришлось делать ручками...

Это уже рантайм. Как идея, конечно, зависит от количества дескриптором и того, как часто их нужно править... написать свой препроцессор.

Ну уж прям и препроцессор... Это все можно сгенирить обычными bash/awk/perl/e.t.c. (что кому привычнее) из простого списка строк и включить в make (или pre-build step)... Если уж в эту сторону думать.

А ещё COG - и не только для этого.