c null pointer

tokuchu

sergey_m

Понятно, что можно сделать что-нибудь вроде (void *)1, или взять ссулку на какую-нибудь ненужную переменную или функцию внутри программы, или просто тупо malloc сделать лишний. Но я подумал, что может какие специальные методики для такого есть?

tokuchu

Вроде ты перечислил все специальные методики

Marinavo_0507

Вроде ты перечислил все специальные методики

tokuchu

можно ещё выравнивать данные и использовать младшие биты

slonishka

vall

Anturag

Понятно, что можно сделать что-нибудь вроде (void *)1

Serab

ты же не не собираешься разыменовывать, верно?

Anturag

Werdna

можно сделать что-нибудь вроде (void *)1

vall

глянь на include/linux/err.h

#define IS_ERR_VALUE(x) unlikelyx) >= (unsigned long)-MAX_ERRNO)



static inline void *ERR_PTR(long error)

{

	return (void *) error;

}



static inline long PTR_ERR(const void *ptr)

{

	return (long) ptr;

}



static inline long IS_ERR(const void *ptr)

{

	return IS_ERR_VALUEunsigned long)ptr);

}

tokuchu

от 0 до (PAGE_SIZE - 1) - в этом диапозоне у тебя гарантированно ничего нет и не будет, ибо работа с VMM постраничная

tokuchu

для тех кому лень смотреть. в ядре широко используется такая конструкция

tokuchu

Больше быднокодинга! Ты можешь круче, мы знаем.
Вместо того, чтобы сделать грамотный и понятный интерфейс, сделай нечто, что обломает лучшие умы будущего.

kokoc88

А 0-я страница гарантированно не может быть использована?

Werdna

Ну давай подробнее расскажи-то что тебя смущает?

Anturag

А 0-я страница гарантированно не может быть использована?

Не гарантировано, туда можно отмапить файл или кусок памяти

tokuchu

Если говорить по делу, то лучше интерфейсы сделать явными и код передавать как-то ещё.

yroslavasako

kokoc88

Бля, это где так можно? В винде что ли?

#include <sys/ipc.h>

#include <sys/shm.h>

#include <stdio.h>



int main(int argc, char* argv[])

{

    int id;

    void* ptr;

    char* pc = NULL;

    int i;



    id = shmget(IPC_PRIVATE, 4096, IPC_CREAT|0666);

    if (id == -1)

    {

	perror("shmget");

	return -1;

    }

    printf("shmget: %d\n", id);



    ptr = shmat(id, 1, SHM_RND);

    if (ptr == (void*)-1)

    {

	perror("shmat");

	return -1;

    }

    printf("shmat: %x\n", ptr);



    memset(ptr, '5', 4096);

    for (i = 0; i < 4096; i++)

	if (*pc++ != '5')

	    return -1;



    printf("OK\n");

    return 0;

}

Anturag

vall

vall

Oper

Хочу в C себе сделать ещё один указатель "в никуда". Чтобы можно было делать как-нибудь так:

vall

Oper

новую переменную для состояний ошибки заводить ненужно, для этого уже есть errno.

...

return NULL; // not NULL, really

...

tokuchu

Это такой стандартный способ вернуть errno вместо поинтера — в ядре ошибки всегда отрицательные.
Последней страницы в ядре нет, т.к. часто используется container_of и надо ловить баги при дереференсе поинтеров полученных применением его к NULL. В юзерспейсе этой страницы тоже быть не должно.

procenkotanya

(void *)-1

tokuchu

Если слова "хороший стиль программирования" тебе о чем-нибудь говорят, то "ты не должен этого хотеть" (c)
Лучше заведи дополнительную переменную.

vall

Речь идет о конкретной проблеме. Заметь, топикстартер ничего не говорил про то, что этот NULL2 нужен для отслеживания "состояния ошибки" в программе.

vall

А мне как раз кажется, что если у меня 3 состояния: "память ещё не выделена", "память не надо выделять", "память выделена", то заводить дополнительную переменную (что приведёт к 4 возможным состояниям) — это и есть нехороший стиль. Потом т.к. их будет много, то экономия места в 2 раза уже как минимум оправдывает данный подход. Всё это мне нужно не в том месте, где можно насрать на память, на производительность, зато будет шаблонно.

tokuchu

Для этого мне не нравиться применять non-NULL т.к. при освобождении придётся думать нужно ли освобождать память.
Лучше выделять именно там где становиться понятно что память нужна, иначе оставлять NULL, а free пофиг на NULL.

Oper

Для этого мне не нравиться применять non-NULL т.к. при освобождении придётся думать нужно ли освобождать память.
Лучше выделять именно там где становиться понятно что память нужна, иначе оставлять NULL, а free пофиг на NULL.

ну вот всегда так, не разобравшись что конкретно нужно начинают строить всеобщее универсальное решение.

Oper

А мне как раз кажется, что если у меня 3 состояния: "память ещё не выделена", "память не надо выделять", "память выделена", то заводить дополнительную переменную (что приведёт к 4 возможным состояниям) — это и есть нехороший стиль. Потом т.к. их будет много, то экономия места в 2 раза уже как минимум оправдывает данный подход. Всё это мне нужно не в том месте, где можно насрать на память, на производительность, зато будет шаблонно.

tokuchu

Как вариант, "память не нужно выделять" - NULL, "память не выделена" - запись в глобальную переменную, например, ту же errno.

kokoc88

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

tokuchu

И для этого ты делаешь специальный NULL? Я согласен с -ом:

kokoc88

Какие у тебя предложения?

tokuchu

Размести полноценную вершину дерева, чтобы указатель показывал на соответствующий ему тип данных.

Serab

tokuchu

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

kokoc88

Ничего не понял. А так у меня указатели на несоответствующие типы будут указывать что ли?

tokuchu

А так у тебя они будут указывать на хер знает что.

kokoc88

Почему. У меня есть указатель типа (struct tree *) и у него будет 3 варианта значений: NULL, SKIP, и на аллоцированную память. Где здесь "хер знает что"?

tokuchu

SKIP, если это (void*)-1

kokoc88

И что в этом плохого? NULL ведь тоже указывает на хер знает что.

tokuchu

NULL как раз никуда не указывает.

kokoc88

А я буду заодно считать, что SKIP тоже никуда не указывает.

tokuchu

Но лучше всё равно писать нормальный читаемый код без хаков, тем более даже Си это позволяет.

tokuchu

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

kokoc88

Я считаю, что ты не привёл никаких весомых аргументов "против". Только какие-то мифические предположения, что код будет нечитаемым, что-то будет некрасиво (непонятно по каким критериям) и т.п.

vall

Если написать SKIP = create_some_node то код будет намного лучше, безопасней и проще для развития: эту память можно читать и передавать в разные функции, можно добавлять какую-то логику и значения по умолчанию, и так далее.

tokuchu

эту память можно читать и передавать в разные функции

kokoc88

безопаснее? не нужно эту память читать. это всё равно что NULL читать

kokoc88

Да не будет оно наружу выдаваться.
Это внутреннее устройство дерева. Снаружи в него будут только ложить данные и вынимать. Прямой доступ к вершинам не предполагается.
Если и понадобится расширить, то разве только ещё каким-нибудь NULL-ом. В общем польза от добавления лишних сущностей неочевидна даже в будущем, а вот польза от их исключения есть, как я уже говорил — меньше памяти занимает и проще проверки будут в некоторых местах.

tokuchu

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

kokoc88

Оно менее удобное, чем константа, поэтому нужны причины для его использования, про которые я и спрашивал.

Проверки как раз не будут нарушать никаких соглашений общепринятых.

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

tokuchu

Теперь я не вижу аргументов.
Моё решение вообще-то тоже с константой.

Общепринятые соглашения нарушает неправильное значение указателя на память.

Что действительно является усложнением программы, так это хаки.
Что действительно бессмысленно, так это писать хаки ради неведомой выгоды.

Serab

tokuchu

может там очевидная ситуация какая-то.

kokoc88

Константа, которая появляется во время выполнения?

Да это не более хаки, чем заведение дополнительного флага или ненужной области памяти.

tokuchu

Да. бывают константы, которые хранятся в памяти. В Си можно проинициализировать константу один раз.

Я опять не вижу аргументов. Заведение флага или размещение памяти делаются обычными языковыми конструкциями.

kokoc88

Ты вот используешь слово "хак", как аргумент, но почему это "хак"?

tokuchu

Потому что ты вкладываешь смысл в указатель на несуществующую память.

kokoc88

И в этом нет ничего плохого.

tokuchu

Что в этом плохого уже написано выше по теме.
Причём разными людьми и различными словами.

kokoc88

Прости, но я не заметил ничего конкретного.

tokuchu

Не все могут принимать аргументы других людей.

salamander

Общепринятые соглашения нарушает неправильное значение указателя на память.

kokoc88

Какие нафиг общепринятые соглашения нарушаются?

tokuchu

Не использовать указатели на несуществующую память для реализации логики программы.

vall

Не использовать указатели на несуществующую память для реализации логики программы.

salamander

yroslavasako

tokuchu

А для си - это нормальная практика. Всё - ради производительности, и выдача результата через (void*) (-1) отвечает этой задаче

kokoc88

Во-вторых, (void *)-1, так же как и NULL, используются как специальные значения указателя, причем нередко (например, все программы использующие shmat).

Любая некорректная операция с ним сразу приводит к сегфолту, что особенно хорошо, когда приходится дописывать программу N-лет спустя.

kokoc88

Это откуда такое?

kokoc88

а NULL что такое?

A null pointer constant is an integral constant expression (5.19) rvalue of integer type that evaluates to zero. A null pointer constant can be converted to a pointer type; the result is the null pointer value of that type and is distinguishable from every other value of pointer to object or pointer to function type. Two null pointer values of the same type shall compare equal.

tokuchu

Мне бы было намного интереснее узнать, откуда обратное.

procenkotanya

Мне бы было намного интереснее узнать, откуда обратное.

Не использовать указатели на несуществующую память для реализации логики программы.

tokuchu

Правда это из стандарта плюсов, но всё равно даёт право говорить о том, что это общепринятая вещь. Указатель (void*)-1 стандартом языка не описан.

salamander

Чем больше хаков, тем тяжелее что-то дописывать и развивать N лет спустя. Если эта, в общем-то, очевидная вещь кому-то не понятна, то я не вижу смысла продолжать дискуссию.

kokoc88

не будучи как-то обосновано, пока что похоже на какую-то догму, а не рациональную рекомендацию

kokoc88

Ты два моих предыдущих поста до конца дочитал? Я там как раз объяснял почему в данном случае решение с (void *)-1 с точки зрения сопровождения и развития программы в дальнейшем лучше.

kokoc88

Правило либо есть, либо нет. Чтобы его не было — это не надо придумывать ничего. А ты утверждал, что оно есть, так что тебе доказывать. А "обратного" доказывать не надо.

tokuchu

потому что такие указатели описаны в стандарте со словами "undefined behavior".

tokuchu

Но не понял, почему сегфолт чем-то особенно хорош через N лет. А если совсем особенно дописать код так, что сегфолты будут только у клиентов раз в месяц...

Serab

salamander

Дочитал. Но не понял, почему сегфолт чем-то особенно хорош через N лет. А если совсем особенно дописать код так, что сегфолты будут только у клиентов раз в месяц...
Что касается дебагеров, оба моих дебагера способны в вотч листе вычислять выражения типа true/false, так что не знаю. Может быть, было бы полезно в каких-то случаях, но впиливать хаки в код ради этого я бы не стал.
Гарантированного несовпадения с (void*)-1 может и не быть, особенно при кроссплатформенной разработке.

tokuchu

Dasar

kokoc88

Сегфолт хорош тем, что возникает там, где произошла неокрректная операция. В бэктрейсе сразу видно, что случилось и где.

Чтобы вычислить какое-то выражение в вотч-листе, тебе нужно помнить, с чем сравнивать. (void *)-1 заметен и в том случае, если ты этого не помнишь.

То есть: сегфолт -> смотрим в дебагере бактрейс -> разыменовали -1 -> а, я забыл про специальное значение (void *)-1.

vall

Ага, особенно хорошо, когда стектрейс с оптимизированного релиза, который прислали клиенты, у которых программа падает один раз в месяц, из-за чего они теряют, скажем, 5-10 тысяч долларов. Моё мнение в том, что надо разрабатывать код так, чтобы сегфолтов не было, и на Си++ этого вполне можно добиться простыми правилами.

kokoc88

исходя из этого получается, что надежнее использовать решение (void*)-1 (хотя оно мне и меньше нравится)

test.c:17: warning: passing argument 1 of ‘free’ discards qualifiers from pointer target type
/usr/include/stdlib.h:488: note: expected ‘void *’ but argument is of type ‘const void *’

salamander

Ага, особенно хорошо, когда стектрейс с оптимизированного релиза, который прислали клиенты, у которых программа падает один раз в месяц, из-за чего они теряют, скажем, 5-10 тысяч долларов.

надо разрабатывать код так, чтобы сегфолтов не было

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

мне по почте прислали стектрейс с релиза очень ценного клиента

Serab

kokoc88

Мне казалось, что надо разрабатывать код так, чтобы он работал. А отсутствие сегфолтов тебе этого, увы, не гарантирует.

kokoc88

бля, ну ты юморист, 10тыс. долларов за сегфолт. а неверный результат или тот же сегфолт, но в вообще не связанном месте кода эти клиенты скидку получают, типа за сложность отладки?

kokoc88

Например, добавить вершину в это дерево. И куда ты ее добавишь в этом случае? К твоей фиктивной вершине.

salamander

salamander

то в мою фиктивную вершину нельзя будет что-то добавлять

kokoc88

Ты про такую вещь, как assert слышал? В данном случае сегфолт служит ровно для тех же целей.

Если тебе так хочется восстанавливаться после сегфолтов - перехватывай их, в чем проблема-то? Это же не SIGKILL. И чинись после этого, прибиванием сглючившего задания и отправлением багрепорта, а не по принципу "программа не упала, что-то делает - ну и ладно, что-нибудь сделает, наверное".

Serab

kokoc88

Ты как этого собрался добиться?

kokoc88

ну тогда надо и вместо NULL использовать специально выделеный указатель, станет меньше сегфолтов, епта.

про проверки на верность результата вообще смешно: 1. ошйбка может быть в коде проверки, 2. порчи памяти хуй исправишь автоматически.

salamander

Перехватывать сегфолты в Си можно только с целью сделать дамп и умереть. Это ещё одна прописная истина, о которой я не собираюсь спорить.

#include <stdio.h>

#include <stdlib.h>

#include <unistd.h>

#include <signal.h>

#include <setjmp.h>

#include <inttypes.h>



static jmp_buf invalid_ptr;

static void handler_sigsegv(int x __attribute__unused { __builtin_longjmp(invalid_ptr, 1); }



int is_valid_ptr(void *x)

{

    uint8_t c;

    struct sigaction saved_act, new_act;

    int is_ok = 1;



    sigaction(SIGSEGV, NULL, &saved_act);

    new_act = saved_act;

    new_act.sa_flags |=  SA_RESETHAND;

    new_act.sa_flags &= ~SA_SIGINFO;

    new_act.sa_flags |=  SA_NODEFER;

    new_act.sa_handler = handler_sigsegv;



    sigaction(SIGSEGV, &new_act, NULL);

    if (__builtin_setjmp(invalid_ptr {

        is_ok = 0;

    } else {

        c = *uint8_t *)x);

    }

    sigaction(SIGSEGV, &saved_act, NULL);



    return is_ok;

}



void try_ptr(void *x)

{

    printf("Point %p is %s" "a valid pointer\n", x,

           is_valid_ptr(x) ? "" : "not ");

}



int main(void)

{

    int x;

    int *l = malloc(1); /* 1 is less than sizeof(int) */

    try_ptr(&x);

    try_ptr&x) + 7);

    try_ptr(NULL);

    try_ptr(handler_sigsegv);

    try_ptrvoid *)-1);

    try_ptr&x) - 1);

    try_ptr(l);

    try_ptr(l - 1);

    try_ptr(l + 20000000);

    try_ptr(l + 1);

    try_ptrvoid *)0eadbeaf);

    return 0;

}

salamander

Куда-то ты в ту степь уехал. Это уже не аргументы за или против какого-либо из предложенных решений.

salamander

На Си тоже можно делать стабильные отказоустойчивые решения, просто у них очень высокая стоимость.

Я всё равно не смогу принять их как аргумент "за", и считаю, что бесполезно спорить с тем, кто так аргументирует.

kokoc88

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

yroslavasako

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

Serab

ы про такую вещь, как assert слышал? В данном случае сегфолт служит ровно для тех же целей.

bleyman

int descriptor = p->descriptor; 

if (NULL == p) return E_INVAL;

// do kernel stuff with the descriptor

На прошлой работе как-то встретил такое в прошивке для контроллера AVR:
if (cmd[1] == RESET) // если принятая команда RESET
{void(*void0;} // что-то из черной магии

vall

В некоторых архитектурах NULL вовсе не состоит из всех нулей.

Кстати про нуллы и ядро

bleyman

Serab

tokuchu

А можно для проспавших (меня) пояснить, почему чувак так написал изначально? На что рассчитывал?

vall

А он и не работает, а чё? http://c-faq.com/null/machexamp.html

Вот один из множества примеров проявления бага, с реальным диффом реального кернел кода: http://lkml.org/lkml/2009/7/6/19%C0 так — говнокод, конечно. Обращение по нуллу производит undefined results, в которых вполне входит магическое исчезновение последующих проверок.

bleyman

какбы пофиг на исчезновение проверок, пэйдж фолты ещё никто не отменял.

SPARTAK3959

tokuchu

ну это уже из разряда "забавные курьёзы истории эвм"
сегментная адресация уже толком нигде не используется, боюсь даже в дремучем эмбедеде её не осталось.
да и банально проверка на ноль короче и быстрее во всех системах команд.

tokuchu

В таких случаях надо использовать паттерн NullObject - использовать указатель на неизменяемую структуру/объект с нужными дефолтными значениями полей и реализациями методов (для классов). В результате во многих случаях удастся обойтись вообще без сравнения с ним.

vall

bleyman

Я тут подумал, что можно ведь заюзать (char *)0 + 1, если рассчитывать на всяких извращенцев тоже.

tokuchu

Неа. Это тоже undefined behaviour.

vall

apl13

vall

SPARTAK3959

SPARTAK3959

tokuchu

Сегмент программы const data кто-то запретил?

bleyman

#include <stdio.h>



void * memcpy(void * destination, const void * source, size_t num)

{

    return "CPY MY MEM";

}



int main

{

    printf("%s\n", (char*)memcpy("HAXUS", "THE REIMPLEMENTOR", 0;

    printf("%s\n", (char*)memcpy("HAXUS", "THE REIMPLEMENTOR", 1;

    return 0;

}

$ gcc -dumpversion

3.4.6

$ gcc test.c -Wall -pedantic -ansi

$ ./a.out

HAXUS

CPY MY MEM

vall

ava3443

такойже пиздец есть с printf("%s\n", NULL);
он его заменяет на puts и падает, когда glibc printf печатает "(null)\n"

#include <stdio.h>



int main

{

printf("%s\n", NULL);

return 0;

}

$ cc test.c -o test

$ ./test

Segmentation Fault (core dumped)

$ cc -V

cc: Sun C 5.10 SunOS_sparc 2009/06/03

usage: cc [ options] files.  Use 'cc -flags' for details



$ gcc test.c -o test

$ ./test

Segmentation Fault (core dumped)

$ gcc --version

gcc (GCC) 3.4.6

Copyright (C) 2006 Free Software Foundation, Inc.

This is free software; see the source for copying conditions.  There is NO

warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

ava3443

$ gcc test.c -o test

$ ldd test

        libc.so.1 =>     /lib/libc.so.1

        libm.so.2 =>     /lib/libm.so.2

        /platform/SUNW,T5440/lib/libc_psr.so.1

apl13

procenkotanya

apl13

procenkotanya

vall

rosali

bleyman

tokuchu

Алсо, анализировать код всё-таки очень сложно.

SPARTAK3959

Я не в курсе на каких архитектурах реально можно поставить read-only флаг на сегмент памяти. И чтобы ещё компилятор const данные именно в такие сегменты разместил (если вообще у него есть полномочия).
Ну и к тому же в чём преимущество?

tokuchu

Serab

tokuchu

Ну все равно при записи все грохнется, это отладить все равно на порядки проще.

Serab

SPARTAK3959