Простой пример:

Вот так:...

#include <Pt.h>



static char* str;



char* f() { return str; }



void any_func()

{

  ...

  PtSetResource( pw, Pt_ARG_TEXT_STRING, f(), 0 );

  ...

}

... будет выдано предупреждение в строке с PtSetResource (cast does not match function type)

А вот так:...

...

void any_func()

{

  char *res;

  ...

  PtSetResource( pw, Pt_ARG_TEXT_STRING, res = f(), 0 );

  ...

}

... нет.

"Я так хохоталься..."
Всё по правилам ! Но - будьте обэрэжни!
Тут в пору ошибку выводить, но компилятор полагается на нас в наших стремлениях усложнить себе жизнь, просто скромно предупреждая... :о)

А вот ещё вопрос:
Защёл давеча к знакомому. Показал он мне свой код, проконсультироваться. Но тут мне на глаза попалась такая строчка в его тексте (чисто аналогия):

struct S* pS = {0};

Коллеги, объясните мне какой смысл в знаке = и дальше? :о)
ЧТО подразумевается под записью инициализации указателя нулём в фигурных скобках? То что, это аналогично = NULL я понимаю, но что за неявные преобразования и соглашения здесь действуют? Это что-то из нового С99 или расширения gnu? (версия 3.4.х)

Wlad
Коллеги, объясните мне какой смысл в знаке = и дальше? :о)

Создаётся объект размером sizeof(struct S), все поля равняются 0/NULL. pS содержит указатель на созданный и проинициализированный объект.

Wlad
Это что-то из нового С99 или расширения gnu? (версия 3.4.х)

"The ANSI C Programming Language (Second Edition)" , Copyright 1988 by AT&T Brian W. Kerninghan, Dennis M. Ritchie.

If there are fewer initializers in the list then members of the structure, the trailing members are initialized with 0.

В С89 были незначительные расширения по данному вопросу.

Я в детстве использовал конструкции типа: struct S aS[20]={{0}}; Сейчас такие конструкции уже deprecated, и компиляторы не держут. 2Wlad: домашнее задание, что делает (делала) эта конструкция.

lestat
Создаётся объект размером sizeof(struct S), все поля равняются 0/NULL. pS содержит указатель на созданный и проинициализированный объект.

Это я пробредил. Блин, написал, выключил компьютер, пошел спать, лег и думаю, во фигню написал, встал, решил исправится

Да, в вышеуказанном примере это равносильно = NULL, но если, к примеру будет инициализироваться массив указателей, struct S* pS[20] = {0};, то все указатели будут равны NULL. Т.е. вышеуказанная запись равносильна struct S* pS[1] = {0};

Wlad

ЧТО подразумевается под записью инициализации указателя нулём в фигурных скобках?

Ваш знакомый или не совсем понимает, что он пишет, или таким образом задрачивает коллег. Ведь многие, не только lestat, могут пробредить увидев структуру там где ее нет. Почему вы не задали этот вопрос вашему знакомому? Любопытно бы услышать, что он сказал бы.

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

edit: если вы не упустили и там конечно не была инициализация массива указателей

Инициализировался указатель на структуру.
Причём, когда я спросил, "какето?", мне были паказаны исходники FreeBSD, где народ в массовом порядке применяет то же самое. Вот я теперь и думаю: то ли они на одном символе экономят, то ли исходят из каких-то высших стратегических интиресов?
Если рассуждать в меру моей осведомлённости, то я бы расшифорвывал это так: строится одноэлементный массив, элементов с типом по умолчанию (так, как нет "(тип)" перед "{"? следовательно - это - int), первый и единственный элемент которого (в случае int 32 разряда) совпадает с размером указателя. И потом ЭТО неявно преобразется к NULL-указателю заданного в описании типа.
Но чуйствую неверность в рассуждениях...
Интерес-то в чём: если это просто фича для указателей от гну - похрен мне один лишний символ писать. А если это "часть чего-то большего" - то я об этом почему-то до сих пор не знаю. То есть не могу вывести из тех общих правил языка, которые известны мне, этот частный случай...

Я бы, все-таки, по простоте душевной предположил, что указатель инициализируется ссылкой на область с нулевым значением... Возможно чтобы не встрять в разыменование NULL... Можно, конечно проверить "живьем",.. но не интересно
Если мое предположение о смысле конструкции верно, то ее широкое применение объямняется ремесленным подходом, т.е. было подсмотрено в исходниках какого-нибудь мастера-корифея без понимания смысла использования и воспринято как признак "крутизны". Ну а дальше "Мартышка и очки"...

Не знаю что они экономят. ИМО, правильная инициализация указателя
struct S* pS = NULL;
Как по мне, я сразу вижу, что обьект типа указатель (адрес памяти). Второе, NULL не на любой системе обязан быть 0, смысл такой инициализации присвоить "неправильный" адрес, куда нельзя обращаться.

Фигурные скобки - это инициализация списка. Мое первое предположение было, что человек однажды написал что-то типа
int array[5][10] = {0};
И получил предупреждение от gcc, что нету фигурных скобок вокруг инициализатора. Догадался ли он написать "правильно" (в трактовке парней от gcc)
int array[5][10] = {{0}};
или нет, но тем не менее запомнил, что нужны фигурные скобки вокруг инициализаторов. До сих пор их и ставит, везде.

Надо бы поисследовать вопрос... Может я в корне не прав. Исходники фри... Это серьезно... Надо посмотреть при случае, что там люди пишут.

ed1k
Догадался ли он написать "правильно" (в трактовке парней от gcc)
int array[5][10] = {{0}};

Эта конструкция, на сколько я знаю, уже не поддерживается.

ed1k
Не знаю что они экономят. ИМО, правильная инициализация указателя struct S* pS = NULL;

ПОлностью с вами согласен. Это и наглядно и на счёт представимости NULL-а на низком уровне...
Меня терзают сомнения, что я чего-то пропустил. Может "все поют уже давно, а вы всё разговариваете"((с)МЖ)? - вдруг тут нечто важное, а сакральный смысл ускользает от моего мировоспряития? :о)

lestat

конструкция, на сколько я знаю, уже не поддерживается.

$ gcc --version 

gcc (GCC) 3.2.2

Copyright (C) 2002 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.



$ cat init.c





int main ()

{

    int a[5][10] = {0};

    a[0][0] = a[4][9]; 

    return 0; 

}



$ gcc -Wall init.c 

init.c: In function `main':

init.c:5: warning: missing braces around initializer

init.c:5: warning: (near initialization for `a[0]' )



...



$ cat init.c 





int main ()                                         

{                                                   

    int a[5][10] ={{0}}; 

    a[0][0] = a[4][9];

    return 0;  

}



$ gcc -Wall init.c 

--

Это проблемы GCC. См. C99 раздел 6.7.8. Иначе будут проблемы с aggregate initialization.

lestat
Это проблемы GCC. См. C99 раздел 6.7.8.

Да знаю я Смотрел C99.

lestat
ed1k
Догадался ли он написать "правильно" (в трактовке парней от gcc)
int array[5][10] = {{0}};

Эта конструкция, на сколько я знаю, уже не поддерживается.

Об ГЦЦ и шла речь. Очень этими парнями эта конструкция поддерживается и даже требуется, если у кого требуется компилить "чисто" при -Wall. У нас например требуется, и "боевой" компилятор gcc 2.96...

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

Wlad
Ну вот, опять ищем под фонарём... :о)
Про массивы я и так знал. Мне, всё же, дюже интересная именно тайна велика про инициализацию указателя нулём в фигурных скобках...

Wlad
Причём, когда я спросил, "какето?", мне были паказаны исходники FreeBSD, где народ в массовом порядке применяет то же самое.

Во второй цитате ответ на ваш вопрос. Если человек не может обьяснить, что он написал, а ссылается на какой-то другой код, то гнать такого коллегу в шею.
Просмотрел вчера кое-что из исходников freeBSD - ничего такого не нашел, на удивление опрятный код. Тянуть все и грепить - нет ни времени ни желания.
Простой пример

#include <stddef.h>

#include <stdio.h>



struct S

{

    int a;

    float b;

} my_structS;



int main ()

{

#if 1

    struct S* pS = {0};

#else 

    struct S* pS = NULL;

#endif

    printf("some_structS.a = %d", pS->a);

    return 0;

}

--

в двух случаях компиляции производит одинаковый код, который приводит к одинаковому результату:
Segmentation Fault (core dumped)

Evgeniy
Я бы, все-таки, по простоте душевной предположил, что указатель инициализируется ссылкой на область с нулевым значением... Возможно чтобы не встрять в разыменование NULL...

Речь ведь о Си без плюсов? Какие ссылки и разименования?

Просмотрев хидеры SunOS и то как там обьявлен NULL,
могу только предположить, что если тип int короче, чем ширина адресной шины, то ширины нуля может нехватить и при {0} компилятор таки возьмет длинный ноль из нескольких нулей списка. (Хотя вроде бы должен преобразовать типы и расширить ноль). По любому - инициализация указателя с помощью {0} извращение и в корне неправильно, IMHO.

ed1k
По любому - инициализация указателя с помощью {0} извращение и в корне неправильно, IMHO.

Q: Should I use NULL or 0?

A: In C++, the definition of NULL is 0, so there is only an aesthetic difference. I prefer to avoid macros, so I use 0. Another problem with NULL is that people sometimes mistakenly believe that it is different from 0 and/or not an integer. In pre-standard code, NULL was/is sometimes defined to something unsuitable and therefore had/has to be avoided. That's less common these days.
If you have to name the null pointer, call it nullptr; that's what it's going to be called in C++0x. Then, "nullptr" will be a keyword.

(c) Bjarne Stroustrup.

Раз пошла такая жара, читать от корки до корки.

5.4: What is NULL and how is it #defined?

A: As a matter of style, many programmers prefer not to have
unadorned 0's scattered through their programs. Therefore, the
preprocessor macro NULL is #defined (by <stdio.h> and several
other headers) with the value 0, possibly cast to (void *) (see
also question 5.6). A programmer who wishes to make explicit
the distinction between 0 the integer and 0 the null pointer
constant can then use NULL whenever a null pointer is required.

Using NULL is a stylistic convention only; the preprocessor
turns NULL back into 0 which is then recognized by the compiler,
in pointer contexts, as before. In particular, a cast may still
be necessary before NULL (as before 0) in a function call
argument. The table under question 5.2 above applies for NULL
as well as 0 (an unadorned NULL is equivalent to an unadorned
0).

NULL should *only* be used for pointers; see question 5.9.

References: K&R1 Sec. 5.4 pp. 97-8; K&R2 Sec. 5.4 p. 102; ISO
Sec. 7.1.6, Sec. 6.2.2.3; Rationale Sec. 4.1.5; H&S Sec. 5.3.2
p. 122, Sec. 11.1 p. 292.

5.5: How should NULL be defined on a machine which uses a nonzero bit
pattern as the internal representation of a null pointer?

A: The same as on any other machine: as 0 (or some version of 0;
see question 5.4).

Whenever a programmer requests a null pointer, either by writing
"0" or "NULL", it is the compiler's responsibility to generate
whatever bit pattern the machine uses for that null pointer.
Therefore, #defining NULL as 0 on a machine for which internal
null pointers are nonzero is as valid as on any other: the
compiler must always be able to generate the machine's correct
null pointers in response to unadorned 0's seen in pointer
contexts. See also questions 5.2, 5.10, and 5.17.

References: ISO Sec. 7.1.6; Rationale Sec. 4.1.5.

5.6: If NULL were defined as follows:

#define NULL ((char *)0)

wouldn't that make function calls which pass an uncast NULL
work?

A: Not in general. The complication is that there are machines
which use different internal representations for pointers to
different types of data. The suggested definition would make
uncast NULL arguments to functions expecting pointers to
characters work correctly, but pointer arguments of other types
would still be problematical, and legal constructions such as

FILE *fp = NULL;

could fail.

Nevertheless, ANSI C allows the alternate definition

#define NULL ((void *)0)

for NULL. Besides potentially helping incorrect programs to
work (but only on machines with homogeneous pointers, thus
questionably valid assistance), this definition may catch
programs which use NULL incorrectly (e.g. when the ASCII NUL
character was really intended; see question 5.9).

References: Rationale Sec. 4.1.5.

5.9: If NULL and 0 are equivalent as null pointer constants, which
should I use?

A: Many programmers believe that NULL should be used in all pointer
contexts, as a reminder that the value is to be thought of as a
pointer. Others feel that the confusion surrounding NULL and 0
is only compounded by hiding 0 behind a macro, and prefer to use
unadorned 0 instead. There is no one right answer. (See also
questions 9.2 and 17.10.) C programmers must understand that
NULL and 0 are interchangeable in pointer contexts, and that an
uncast 0 is perfectly acceptable. Any usage of NULL (as opposed
to 0) should be considered a gentle reminder that a pointer is
involved; programmers should not depend on it (either for their
own understanding or the compiler's) for distinguishing pointer
0's from integer 0's.

NULL should *not* be used when another kind of 0 is required,
even though it might work, because doing so sends the wrong
stylistic message. (Furthermore, ANSI allows the definition of
NULL to be ((void *)0), which will not work at all in non-
pointer contexts.) In particular, do not use NULL when the
ASCII null character (NUL) is desired. Provide your own
definition

#define NUL ''

if you must.

References: K&R1 Sec. 5.4 pp. 97-8; K&R2 Sec. 5.4 p. 102.

5.10: But wouldn't it be better to use NULL (rather than 0), in case
the value of NULL changes, perhaps on a machine with nonzero
internal null pointers?

A: No. (Using NULL may be preferable, but not for this reason.)
Although symbolic constants are often used in place of numbers
because the numbers might change, this is *not* the reason that
NULL is used in place of 0. Once again, the language guarantees
that source-code 0's (in pointer contexts) generate null
pointers. NULL is used only as a stylistic convention. See
questions 5.5 and 9.2.

5.12: I use the preprocessor macro

#define Nullptr(type) (type *)0

to help me build null pointers of the correct type.

A: This trick, though popular and superficially attractive, does
not buy much. It is not needed in assignments or comparisons;
see question 5.2. (It does not even save keystrokes.) See also
questions 9.1 and 10.2.

5.13: This is strange. NULL is guaranteed to be 0, but the null
pointer is not?

A: When the term "null" or "NULL" is casually used, one of several
things may be meant:

1. The conceptual null pointer, the abstract language concept
defined in question 5.1. It is implemented with...

2. The internal (or run-time) representation of a null
pointer, which may or may not be all-bits-0 and which may
be different for different pointer types. The actual
values should be of concern only to compiler writers.
Authors of C programs never see them, since they use...

3. The null pointer constant, which is a constant integer 0
(see question 5.2). It is often hidden behind...

4. The NULL macro, which is #defined to be 0 (see question
5.4). Finally, as red herrings, we have...

5. The ASCII null character (NUL), which does have all bits
zero, but has no necessary relation to the null pointer
except in name; and...

6. The "null string," which is another name for the empty
string (""[img]http://qnx.org.ru/components/minibb/img/smilies/wink.gif[/img]. Using the term "null string" can be
confusing in C, because an empty string involves a null
(''[img]http://qnx.org.ru/components/minibb/img/smilies/wink.gif[/img] character, but *not* a null pointer, which brings
us full circle...

This article uses the phrase "null pointer" (in lower case) for
sense 1, the character "0" or the phrase "null pointer constant"
for sense 3, and the capitalized word "NULL" for sense 4.

5.14: Why is there so much confusion surrounding null pointers? Why
do these questions come up so often?

A: C programmers traditionally like to know more than they might
need to about the underlying machine implementation. The fact
that null pointers are represented both in source code, and
internally to most machines, as zero invites unwarranted
assumptions. The use of a preprocessor macro (NULL) may seem
to suggest that the value could change some day, or on some
weird machine. The construct "if(p == 0)" is easily misread
as calling for conversion of p to an integral type, rather
than 0 to a pointer type, before the comparison. Finally,
the distinction between the several uses of the term "null"
(listed in question 5.13 above) is often overlooked.

One good way to wade out of the confusion is to imagine that C
used a keyword (perhaps "nil", like Pascal) as a null pointer
constant. The compiler could either turn "nil" into the
appropriate type of null pointer when it could unambiguously
determine that type from the source code, or complain when it
could not. Now in fact, in C the keyword for a null pointer
constant is not "nil" but "0", which works almost as well,
except that an uncast "0" in a non-pointer context generates an
integer zero instead of an error message, and if that uncast 0
was supposed to be a null pointer constant, the code may not
work.

5.15: I'm confused. I just can't understand all this null pointer
stuff.

A: Here are two simple rules you can follow:

1. When you want a null pointer constant in source code,
use "0" or "NULL".

2. If the usage of "0" or "NULL" is an argument in a
function call, cast it to the pointer type expected by
the function being called.

The rest of the discussion has to do with other people's
misunderstandings, with the internal representation of null
pointers (which you shouldn't need to know), and with the
complexities of function prototypes. (Taking those complexities
into account, we find that rule 2 is conservative, of course;
but it doesn't hurt.) Understand questions 5.1, 5.2, and 5.4,
and consider 5.3, 5.9, 5.13, and 5.14, and you'll do fine.

5.16: Given all the confusion surrounding null pointers, wouldn't it
be easier simply to require them to be represented internally by
zeroes?

A: If for no other reason, doing so would be ill-advised because it
would unnecessarily constrain implementations which would
otherwise naturally represent null pointers by special, nonzero
bit patterns, particularly when those values would trigger
automatic hardware traps for invalid accesses.

Besides, what would such a requirement really accomplish?
Proper understanding of null pointers does not require knowledge
of the internal representation, whether zero or nonzero.
Assuming that null pointers are/">

Не влезло всё, дочитать можно тут:
http://c-faq.com/

Текст хороший. Первый пост про С++ не совсем к месту, вроде бы вопроса не было, что по этому поводу думает Страуструп. И возвращаясь к вопросу - где же тут про {0}? Для меня 0 и {0} - две большие разницы, извините.

Если NULL вежливо напоминает, что идет речь о указателе;
0 - делает ту же работу, но без напоминаний;
что же делает {0}?

ed1k
Первый пост про С++ не совсем к месту

Ай, Эдик, оставь свои рассовые предрассудки, всё это к месту.

ed1k
Если NULL вежливо напоминает, что идет речь о указателе; 0 - делает ту же работу, но без напоминаний;
что же делает {0}?

напоминает что там лежит sequence of constant expressions, пусть даже в количестве одного.

lestat ... напоминает что там лежит sequence of constant expressions, пусть даже в количестве одного.

... мнэээ, а какого типа?
Но даже - не это главное. Мне хотелось бы получить хотя бы намёк на (может быть неявные) правила преобразования, используемые для этого случая записи инициализатора... Не предположения, а указания в стандарте или расширении каком...

Wlad
... мнэээ, а какого типа?

В C++ - число 0 - это скалярная константа любого типа. Особый случай.

В C - число 0 - автоматически приводится к необходимому типу.

Wlad
Но даже - не это главное. Мне хотелось бы получить хотя бы намёк на (может быть неявные) правила преобразования, используемые для этого случая записи инициализатора... Не предположения, а указания в стандарте или расширении каком...

Вот http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1124.pdf тут стандарт С99. Искать по всему документу слово initializer и читать. Желательно вообще весь прочесть.

Пункт 6.6 Constant expressions

More latitude is permitted for constant expressions in initializers. Such a constant expression shall be, or evaluate to, one of the following:
— an arithmetic constant expression,
— a null pointer constant,
— an address constant, or
— an address constant for an object type plus or minus an integer constant expression.

Необходимое выделено жирным. 0 и null pointer constant это особый случай. Как и в C++.

Пункт 6.7.8 Initialization

10 If an object that has automatic storage duration is not initialized explicitly, its value is
indeterminate. If an object that has static storage duration is not initialized explicitly,
then:
— if it has pointer type, it is initialized to a null pointer;
— if it has arithmetic type, it is initialized to (positive or unsigned) zero;
— if it is an aggregate, every member is initialized (recursively) according to these rules;
— if it is a union, the first named member is initialized (recursively) according to these
rules.

Необходимое выделено жирным.

Пункт 6.3 Conversions/Пункт 6.3.2.3 Pointers


3) An integer constant expression with the value 0, or such an expression cast to type void *, is called a null pointer constant.55) If a null pointer constant is converted to a pointer type, the resulting pointer, called a null pointer, is guaranteed to compare unequal
to a pointer to any object or function.


Необходимое выделено жирным.


5) An integer may be converted to any pointer type. Except as previously specified, the result is implementation-defined, might not be correctly aligned, might not point to an entity of the referenced type, and might be a trap representation.(^56)



(^56)
The mapping functions for converting a pointer to an integer or an integer to a pointer are intended to
be consistent with the addressing structure of the execution environment.


Необходимое выделено жирным.

Хватит ?

2Wlad, перепости сообщение, а то видать мы вместе дубликаты стирали. И достирались ...

Какое-то нисдоровье у нас на работе с "интернетом" случилось... Посылал мессаги - хрен дожидался ответа. Думал из дома отвечу, пришёл, смотрю - куча моих сообщений. Прошу пардону у почтеннейшей публики!
Итак, краткое резюме. Вопрос не снят. То, что вы привели - правила негласного преобразования скалярных типов в указатели и назад. Запись, увиденная мной - приводит меня к противоречию: объявляется переменная типа указателя, а инициализируется она конструкцией, служащей для формирования значения составного типа. Ваш пост и приведённые вами ссылки, мне ничего не разъясняют. Если действовать по этим правилам, получим, что

struct S* p = {0}; эквивалентно struct S* p = {NULL};

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

Вопрос остаётся в силе: Что есть struct S* p = {0}; ???

lestat
2Wlad, перепости сообщение, а то видать мы вместе дубликаты стирали. И достирались ...

:о)))))) Надо же: вплоть до секунд одновременно "орудовали"! :о)))
А я подумал ((с) майк) "допрограммировался..." :о)

lestat
напоминает что там лежит sequence of constant expressions, пусть даже в количестве одного.

Вот об этом Wlad и писал (в затертом сообщении). Если слева простая переменная (типа указатель), то зачем её инициализировать последовательностью? Ведь может маньяк-программист положить, что каждая переменная это массив, пусть даже и в колличестве одного элемента и писать что-то типа:
int i[1]={0};
for(;i[0]<I_MAX;i[0]++)...
Причем, в этом случае, у меня вопросов к фигурным скобкам не возникает (психическое расстройство программиста оставим отдельным вопросом). Кстати, sequence в колличестве одного - весьма мутно, т.к. есть правила в соответсвии с которыми эта последовательность расширяется до уравнивания кол-ва элементов последовательности до кол-ва эл-тов слева от знака присваивания.

По работе пришлось сегодня почитать стандарт С99. Заодно нашел ответ на этот вопрос.

ISO/IEC 9899:1999 (E) para 6.2.5

21 Arithmetic types and pointer types are collectively called scalar types.

ISO/IEC 9899:1999 (E) para 6.7.8

11 The initializer for a scalar shall be a single expression, optionally enclosed in braces.

Т.е. блюдут опционально требуемые фигурные скобки.

ed1k
Это проблемы GCC. См. C99 раздел 6.7.8.
Да знаю я Смотрел C99.

Таки посмотрел

ed1k Т.е. блюдут опционально требуемые фигурные скобки.

"Эге, сказали мы с Иваном Никанорычем..."
Получается, что, по стандарту, я вполне законно могу записать:

int i = {10}; ?

Интересно, всё-таки, зачем им это понадобилось? Это - ещё "отрыжка" Си от бестипового Би? :о)
Я понимаю, когда в Лиспе, PHP, или ишшшо в каком бестиповом языке, это актуально (по типу инициализатора определяется действующий тип переменной (до следующего присваивания :О) )), но в языках с типизацией...

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