c99, передача указателей в функции

сегодня день передачи указателей на лоре?

всё правильно выводит

1) указатели вообще-то копируются при передаче

2) нефиг malloc'и по функциям прятать

voyd y ничего полезного делать не будет. Так же, как и void x :)

Передавайте указатель на указатель.

Да, а нафига в y переменная b?

>указатели вообще-то копируются при передаче

Более того, все параметры функций передаются по значению.

тебе нужны указатели на указатели

Более удачный пример:

#include <stdio.h>
#include <stdlib.h>

void mystery(int *our_ptr) {
    our_ptr = (int *)malloc(sizeof(int));
}

int main(void) {
    int *ptr = NULL;
    mystery(ptr);
    printf("%p\n",(void *)ptr);
    return 0;
}

our_ptr = (int *)malloc(sizeof(int));

Для того чтобы иметь возможность изменить значение ptr — нужно передать функции mystery адрес ptr, разыменовать его и присвоить ему значение, которое возвратит malloc. Как-то так:

#include <stdio.h>
#include <stdlib.h>

void mystery(int **pptr) {
    *pptr = (int *)malloc(sizeof(int));
}

int main(void) {
    int *ptr = NULL;
    mystery(&ptr);
    printf("%p\n",(void *)ptr);
    return 0;
}

Думаю, стоит еще добавить, что прочитавший K&R такое вытворять не будет :)

>Я ожидаю, что принтф мне выведет адрес в памяти, но он выводит (nil). Начинаю подумывать, что упустил что-то в основах.

Да.

А ты знаешь что делаешь restrict?

указатели вообще-то копируются при передаче

Более того, все параметры функций передаются по значению.

дык, даже указатель на указатель передаётся по значению :) и все это знают, но почему-то именно с передачей указателей начинаются самые большие проблемы в осознании этого факта у людей, и зачастую тут кроется тяжёлое наследие С++ с его передачами по ссылкам :)

Думаю, стоит еще добавить, что прочитавший K&R такое вытворять не будет :)

не думаю что люди писавшие дрова в linux kernel настолько дремучи, а ведь пишут :)

не думаю что люди писавшие дрова в linux kernel настолько дремучи, а ведь пишут :)

Вы в каком-нибудь модуле видели подобную глупость?

Указывает компилятору, что данные, доступные по указателю не перекрываются. Так же, указатель является единственным способом доступа к данным. Вроде так.

>Да, а нафига в y переменная b?

это рудимент. я настолько невнимателен, что запостил неудачный пример. edigaryev меня знатно поправил.

Потрясающий ответ :) Я нечто подобное и ожидал увидеть.
Всем мои благодарности за решение вопроса)

не думаю что люди писавшие дрова в linux kernel настолько дремучи, а ведь пишут :)

Вы в каком-нибудь модуле видели подобную глупость?

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

нашёл пример, смотрим

static int vt6420_prepare_host(struct pci_dev *pdev, struct ata_host **r_host)
 {
         const struct ata_port_info *ppi[] = { &vt6420_port_info, NULL };
         struct ata_host *host;
         int rc;
 
         rc = ata_pci_sff_prepare_host(pdev, ppi, &host);
         if (rc)
                 return rc;
         *r_host = host;
 
         rc = pcim_iomap_regions(pdev, 1 << 5, DRV_NAME);
         if (rc) {
                 dev_printk(KERN_ERR, &pdev->dev, "failed to iomap PCI BAR 5\n");
                 return rc;
         }
 
         host->ports[0]->ioaddr.scr_addr = svia_scr_addr(host->iomap[5], 0);
         host->ports[1]->ioaddr.scr_addr = svia_scr_addr(host->iomap[5], 1);
 
         return 0;
 }

взято отсюда

И что вам здесь не нравится? Все правильно сделано. Никаких попыток вернуть копию указателя не делается. В коде нет попытки изменить значение pdev, так что все ОК.

И что вам здесь не нравится?

кто сказал «не нравится»? :)

В коде нет попытки изменить значение pdev, так что все ОК.

смотрим на r_host и способ его передачи

эм, я кажется понял суть наших с Вами разногласий: Вы в исходном посте апеллировали к первой части, а я ко второй :)

нормальный код Вы привели выше часто передается указатель на указатель для инициализации нужная вещь вот еще пример

node* bstree_add_node(node **root, data){
    if (!*root){
        node *new = malloc
        *root = new
        return ...unwind... new;
    }
    if (pfnCmp(data, (*root).data) < 0)
        return bstree_add_node(&(*root).left, data);
    if (pfnCmp(data, (*root).data) > 0)
        return bstree_add_node(&(*root).right, data);
    return NULL;
}

смотрим на r_host и способ его передачи

Все правильно: т.к. значение указателя r_host должно измениться, нужно передавать указатель на него. Я тоже так делаю, если не хочу использовать глобальные переменные.

>сегодня день передачи указателей на лоре?

Похоже, пора самостоятельных и коллоквиумов.

не то что бы я эксперт в C, но вот не уверен что стоит пихать к каждой переменной кучу модификаторов типа extern static const auto volatile register restrict signed int *a :)

смотрим на r_host и способ его передачи

Все правильно: т.к. значение указателя r_host должно измениться, нужно передавать указатель на него. Я тоже так делаю, если не хочу использовать глобальные переменные.

конечно правильно, я про что и говорил что сам по себе факт передачи указателя на указатель не лютый писец, но нормальный приём программирования и что это используется довольно широко

А все равно gcc на большинство этих модификаторов внимание вообще не обращает :)

ничего подобного :). Ты же не имеешь в виду auto? Остальные вполне боевые :). Ну может restrict не допилен, не проверял...

auto вообще не имеет смысла; register выполняется по решению компилятора; volatile имеет смысл лишь для embedded-систем; про restrict не знаю, возможно компилятор и «слушается» эту директиву.

не-не-не, volatile ещё как имеет смысл при тредах и работе с оборудованием. http://alenacpp.blogspot.com/2006/04/volatile.html

register выполняется по решению компилятора

Конечно, регистров-то мало. Но пока их хватает всё работает как ожидается, проверил.

auto это наследие прошлого, остальное всё используется.

volatile нужно для того чтобы после longjmp сохранялись значения в регистрах.

*В локальных переменных

А я думал, чтобы функции вида

int volatile var;
...
while(var);
...

Да оно много для чего нужно.