void const *argument, Что это? Опции

[ViKo]

В Keil CMSIS-RTOS RTX в параметрах задач указано:

Код

void job1 (void const *arg)

Что это, зачем? Писал, не задумываясь. Теперь хочу просветиться.

[GetSmart]

Вообще-то компилятор должен "съедать" этот параметр при вызове функции и без явного преобразования. Как и для параметра "void *" компилятор должен принимать указатель на любой неконстантный объект из соответствующего адресного пространства. Если отказывается, то это наверное плохой компилятор. Без явного преобразования очевидно, что безопаснее.

Нужно поправить - брать адрес структуры.

Какая разница в данном случае, с амперсандом или без? В случае когда голый идентификатор структуры без указания поля. Однозначнее, конечно, было бы с амперсандом, но на данный момент в Си оба варианта вроде бы одинаковые.

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

Квалификатор const не запретит передачу локальной переменной. Не встать на грабли - забота программиста. const в параметре "проявит себя" только внутри тела функции, когда этот указатель без явного преобразования будет передан параметром или присвоен другому типизированному указателю на константу.

то есть так нельзя
Suart_init mb_cfg = { 0, 9600 };
task_start( mb_task, ..., (void*)mb_cfg );

а так можно
const Suart_init mb_cfg = { 0, 9600 };
task_start( mb_task, ..., (void*)mb_cfg );

Второй вариант тоже будет на стеке. Просто менять его значения нельзя будет.

Сообщение отредактировал GetSmart - Jan 7 2014, 02:22

[ViKo]

Какая разница в данном случае, с амперсандом или без? В случае когда голый идентификатор структуры без указания поля. Однозначнее, конечно, было бы с амперсандом, но на данный момент в Си оба варианта вроде бы одинаковые.

Возможно, в других языках варианты одинаковые. Но не в С. В C можно структуру передавать в функцию, именно, по значению, а не по ссылке. Т.е., имя структуры не есть ее адрес. В отличие от массива.

[GetSmart]

Возможно, в других языках варианты одинаковые. Но не в С.

Чем отличается результат двух вариантов выражений со структурами ниже?

Код

(void*)&mb_cfg
и
(void*)mb_cfg

Если отличаются, то в каких компиляторах.

Идентификатор/имя массива тоже не является адресом его первого элемента. Иначе выражение &mass было бы аналогом &(&mass[0]). Взятие адреса от адреса в Си допустимо?

Сообщение отредактировал GetSmart - Jan 7 2014, 10:18

[ViKo]

Чем отличается результат двух вариантов выражений со структурами ниже?

Код

(void*)&mb_cfg
и
(void*)mb_cfg

Если отличаются, то в каких компиляторах.

Тем, что второй вариант не компилируется.
Keil V5.1.0
source\exsUSB.c(164): error: #171: invalid type conversion
Led9_id = osThreadCreate(osThread(Led_thread), (void *)led9);
А в каком компиляторе работают оба?

[GetSmart]

Тем, что второй вариант не компилируется.
Keil V5.1.0

А (void *)&mass скомпилируется, если это идентификатор массива? Кейла 5-ого под рукой нет чтобы проверить. Идентификаторы массивов, структур и юнионов должны (были) отличаться в применении. При явном преобразовании адреса логично было бы чтобы выражение с идентификатором было приведено к адресу силами самого программиста, дабы не возникало неоднозначностей.

Жаль, в Си нет операторов детипизации указателей, сохраняя исходное адресное пространство. В идеале ещё как-то наследующих выравнивание и другие атрибуты. Вручную для безопасной работы приходится объявлять указатель на void и потом его присваивать к другому типизированному указателю.

Сообщение отредактировал GetSmart - Jan 8 2014, 06:48

[ViKo]

А (void *)&mass скомпилируется, если это идентификатор массива? Кейла 5-ого под рукой нет чтобы проверить.

Проверьте на том, что имеете.
Мое мнение - для массива &mass и mass - одно и то же. Особенность языка.

[GetSmart]

Проверьте на том, что имеете.
Мое мнение - для массива &mass и mass - одно и то же. Особенность языка.

В IARе я так много раз делал без замечаний. Но если 5-ый Keil ругается на явное преобразование адреса от имени структуры без амперсанда, то использование аналогичного синтаксиса к имени массива порождает другой глюк. Кейлу логично было бы запретить использование (void *)&mass. Иначе будут новые грабли.

[ViKo]

Кейлу логично было бы запретить использование (void *)&mass.

Наверное, так оно и есть.

Проверил. Получил.
uint16_t arr[10] = {0, 1, 2, 3, 4, 5, 6, 7, 8, 9};
uint16_t *parr = &arr;

source\Exercises.c(159): error: #144: a value of type "uint16_t (*)[10]" cannot be used to initialize an entity of type "uint16_t *"

На uint16_t *parr = &arr[0]; не ругается, естественно.

На uint16_t *parr = (uint16_t *)&arr; тоже не ругается!

[Сергей Борщ]

На uint16_t *parr = (uint16_t *)&arr; тоже не ругается!

Естественно. Вы же делаете явное приведение типа. В этом случае каждый сам себе злобный Буратина, а компилятор умывает руки - если вы его просите о таком, значит знаете, чего хотите.

[ViKo]

Естественно. Вы же делаете явное приведение типа. В этом случае каждый сам себе злобный Буратина, а компилятор умывает руки - если вы его просите о таком, значит знаете, чего хотите.

Значит, компилятор "имеет представление" о том, что такое &arr. Почему же он неявное приведение не делает?
Ассемблерные команды получаются те же, что и для uint16_t *parr = arr;

[Сергей Борщ]

Почему же он неявное приведение не делает?

Потому что таковы правила языка. Это называется "безопасность типов" (type safety). Он не даем вам случайно спутать теплое с мягким и мух с котлетами. Но и оставляет вам право сделать это, если вам это действительно нужно, через явное приведение типов.