Об ошибке в конструкторе класса может сигнализировать

Главная / Программирование /
Язык программирования C++ / Тест 16

Какие ключевые слова используются для создания и обработки исключительных ситуаций?

Функция вычисляет произведение двух чисел. Исходные данные вводятся с клавиатуры. Какие проверки целесообразно ввести в программе?

Сколько блоков catch может быть после блока try?

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

На каком этапе обнаруживаются ошибки в алгоритме программы?

Если заданы классы
 class A {... } A1;
class B : public A { ... } B1;
class C : public A { ... } C1;
то что будет выведено при выполнении оператора
throw (C1);
а обработка исключительной ситуации записана
catch (B& b) { cout << 1; }
catch (C& c) { cout << 2; }
catch (A& a) { cout << 3; }
catch (...) { cout << 4; }

Если заданы классы
class A {... } A1;
class B : public A { ... } B1;
class C : public A { ... } C1;
то что будет выведено при выполнении оператора
throw (A1);
а обработка исключительной ситуации записана
catch (B& b) { cout << 1; }
catch (C& c) { cout << 2; }
catch (A& a) { cout << 3; }
catch (...) { cout << 4; }

Если заданы классы
class A {... } A1;
class B : public A { ... } B1;
class C : public B { ... } C1;
то что будет выведено при выполнении оператора
throw (C1);
а обработка исключительной ситуации записана
catch (B& b) { cout << 1; }
catch (C& c) { cout << 2; }
catch (A& a) { cout << 3; }
catch (...) { cout << 4; }

Если в конструкторе класса
 class  A {
 public:
    A() { ptr = new char[size];
         Init(); }
    ~A() { if (ptr) delete[] ptr; }
    char* ptr; };
 произойдет исключительная ситуация, будет ли потеряна память при откате по стеку?

Оператор throw без аргументов

Блок try catch

Об ошибке в конструкторе класса может сигнализировать:

Отметьте, какие возможности языка Си++ помогают предупреждать ошибки:

Отметьте те средства языка Си++, которые относятся к диагностике ошибок

Что может быть аргументом оператора throw?

Какие требования предъявляются к классу исключительных ситуаций?

Что происходит при попытке выполнить оператор return внутри блока catch?

Что будет на экране после выполнения программы

#include <iostream.h>
short x = 4, i = 0;
void fun1()
{  if (i == 0) throw 2; }
int fun2()
{ --x; fun1();  x++; return x; }
int main()
{ try
  { fun2(); }
     catch (int)
  { cout << "Exception "; }
  cout << x << " " << i;  
}
    

Что будет на экране после выполнения программы

#include <iostream.h>
short x = 4, i = 0;
void fun1()
{  if (i == 5) throw 2; }
void fun2()
{ --x; fun1();  x++; }
int main()
{ try
  { fun2(); }
   catch (int)
  { cout << "Exception "; }
  cout << x << " " << i;
}

Что будет на экране после выполнения программы

#include <iostream.h>
short x = 4, i = 0;
void fun1()
{ double p=2;
   if (!i) throw p; }
void fun2()
{ --x; fun1();  x++; }
int main()
{ try
  { fun2(); }
    catch (double)
   { cout << "Exception "; }
  cout << x << " " << i;  
}

Какой результат будет у следующего выражения?
    
    int main()
    { try
      { 
         try
         { 
            try {  throw 1; }
            catch (int) { cout << "Exception 1"; }
         }
         catch (int) { cout << "Exception 2"; }
      }
      catch (int){ cout << "Exception 3"; }  
      return 0;
    }
    

Какой результат будет у следующего выражения?
    
    int main()
    { 
      try
      { 
         try
         { 
            try{  throw 1; }
           catch (float) { cout << "Exception 1"; }
         }
         catch (int){ cout << "Exception 2"; }
      }
      catch (int){ cout << "Exception 3"; } 
     return 0; 
    }
    

Что будет выведено на экран после выполнения программы?
    
    int main()
    { 
       try{ 
            try
            {  throw 3.14; }
           catch (int) { cout << "Exception 1"; }
         }
       catch (...)
         { cout << "Exception 2"; }
       return 0;
      
    }
    

Варианты ответа:

1)
abstract
class
A{virtual
f()=0;};

*2)
class
A{virtual
f()=0;};

3)
class
A{virtual
f();};

2. Абстрактный класс – это класс, в котором:

1) есть хотя бы один
виртуальный метод;

2) есть виртуальный
конструктор;

3) есть виртуальный
деструктор;

*4) есть чисто
виртуальный метод.

3. Основная проблема множественного наследования состоит в:

1) замедлении
выполнения программ;

2)
необходимости явно указывать, к какому
базовому классу принадлежит метод;

*3) возможности
существования двух экземпляров объекта
базового класса;

4) неэкономном
расходовании памяти.

4. Если записано

class
A{public:virtual void f(){cout<<1;}};

class
B:public A {public:virtual void f(){cout<<2;}};

то что будет
напечатано, если

B
b;A &a=b; a.f(); ?

Варианты ответа:

*1) 2; 2) 21; 3) 12; 4) 1; 5)
ошибка.

5. Если записано

class
A {public:void f(){cout<<1;}};

class
B:public A{public: void f(){cout<<2;}};

то что будет
напечатано, если

B
b; b.f(); ?

Варианты
ответа:

*1)
2; 2) 21; 3) 12; 4) 1.

6.
Если
записано

class
A{public:virtual void f(){cout<<1;}};

class
B:public A{public:virtual void f(){cout<<2;}};

то что будет
напечатано, если

B
b; b.f(); ?

Варианты ответа:

*1) 2; 2) 21; 3) 12; 4)1;
5)ошибка.

Лабораторная
работа № 6
Тема. Потоки, обработка
исключительных
ситуаций в C++

Теоретическое
введение. В
С++ ввод-вывод осуществляется через
потоки. Потоки являются объектами
соответствующих классов. При запуске
программы автоматически открываются
стандартные потоки cin,
cout, cerr, clog. Последние
два потока используются для вывода
сообщений об ошибках. В файле iostream.h
определены классы: ввода – istream,
вывода – ostream,
ввода-вывода – iostream.

Для
реализации файлового ввода-вывода
небходимо включить файл fstream.h,
содержащий производные от istream
и ostream
классы ifstream,
ofstream
и fstream,
и
объявить соответствующие объекты.
Например:

Ifstream in;//ввод

ofstream
out;//вывод

fstream
io;//ввод—вывод

После
объявления потоков производится открытие
файла, связывающее его с потоком с
помощью функции open()
или
с помощью конструктора. Прототип
функции
open():

void
open (char *filename,int mode,int access);

Здесь
filename
– имя файла, включающее путь; mode
– режим открытия файла (ios::in
– открытие файла для чтения, ios::out
– открытие для записи, ios::binary
– открытие файла в двоичном режиме, по
умолчанию в текстовом); access:
0 – файл со свободным доступом, 1 –
только для чтения, 8 – архивный файл.
Файл закрывается с помощью функции
close().

Для
чтения-записи здесь можно использовать
перегружаемые оператор-функции >> и
<< или использовать методы классов.
Для ввода-вывода одного символа
используются функции:

istream
&get(char &ch); ostream &put(char ch);

Для
записи и считывания блоков двоичных
данных используются функции
считывания-записи n
байт в буфер или из буфера:

istream
&read(unsigned char *buf, int n);

ostream
&write(const unsigned char *buf, int n);

Обработка
исключительных ситуаций.В
программах на С++ следует использовать
механизм обработки исключительных
ситуаций. Операторы программы при
обработке исключительных ситуаций
располагаются в блоке try.
Перехватывается и обрабатывается
исключительная ситуация в блоке catch.
Форма операторов try-catch
следующая:

try
{/*блок
try*/ }

catch(type1
arg){/*блок
catch*/}

С
блоком try
может
связываться
несколько блоков catch.
Выполняется тот блок catch,
для которого тип аргумента соответствует
типу возникшей исключительной ситуации.
При этом ее значение присваивается
аргументу catch.
Если ошибка имеет место внутри блока
try,
она может генерироваться с помощью
throw,
после
чего управление передано блоку catch.
В случае необходимости перехвата всех
исключительных ситуаций независимо от
типа используется

catch(…)

{/*тело*/}

Для
функций, вызываемых из блока try,
можно указать число типов исключительных
ситуаций, которые будет генерировать
функция:

тип
имя (список аргументов) throw(список типов)

{/*тело*/}

Пример.
Из
текстового потока ввести информацию о
студентах и записать ее в виде дерева.
Отсортировать или по фамилии, или по
баллу (вывести тех студентов, у которых
балл выше среднего). Использовать потоки
ввода-вывода и шаблоны.

#include
<iostream.h>

#include
<conio.h>

#include
<fstream.h>

struct
Student{

int
num;

char
surname[10];

int
group;

int
balls;

friend
ostream &operator<< (ostream &stream, Student stud){

stream
<< » » << stud.num << » » <<
stud.surname << » » << stud.group

<<
» » << stud.balls;

return
stream;

}

friend
istream &operator>> (istream &stream, Student &stud){

stream
>> stud.num >> stud.surname >> stud.group >>
stud.balls;

return
stream;

}

};

struct
node{

Student
info;

node
*nextl, *nextr;

node
(){

info.num
= info.group = info.balls=0;

nextl
= nextr = 0;

}

node
(Student newinfo){

info
= newinfo;

nextl
= nextr = 0;

}

};

template
<class T, class T1> class tree{

public:

T
*root;

tree()
{ root = 0; }

void
push (T *& wer, T1 dat, int n){

if
(wer == 0){

try{

wer
= new T;

if(!wer)
throw 1;

wer->nextl
= 0; wer->nextr = 0; wer->info = dat;

}

catch
(int mthrow) {cout<<”No memory!”<<endl;return;}

}

else
if (n == 1)

if
(strcmp(dat.surname,wer->info.surname) < 0) push (wer->nextl,
dat, 1);

else
push (wer->nextr, dat, 1);

else

if
(dat.balls > wer->info.balls) push (wer->nextl, dat, 2);

else
push (wer->nextr, dat, 2);

}

void
insert (T1 dat, int n){

if
(root == 0) root = new T(dat); else push (root, dat, n);

}

void
look (ostream &stream, T *&wer){

if
(wer != 0){

look
(stream, wer->nextl);

stream
<< » » << wer->info << endl;

look
(stream, wer->nextr);

}

}

friend
ostream &operator<< (ostream &stream, tree ob)

{
ob.look (stream, ob.root); return stream; }

};

void
main(){

int
m;

do{

cout
<< «1. Sort with namesn»;

cout
<< «2. Sort with ballsn»;

cout
<< «3. Exitn»;

cin
>> m;

switch
(m){

case
1: {

tree<node,
Student> q;

node
*n;

ifstream
infile(«stud.txt»);

while(!infile.eof()){

Student
c;

infile
>> c;

q.insert(c,
1);

}

infile.close();

cout<<q;

break;

}

case
2: {

tree<node,
Student> q;

node
*n;

ifstream
infile(«stud.txt»);

Student
*c;

c
= new Student;

int
i = 1;

float
s = 0;

while(!infile.eof()){

infile
>> c[i];

s+=c[i].balls;

i++;

}

for
(int j=1; j<=i; j++)

if
(c[j].balls > s/i)

q.insert(c[j],
2);

infile.close();

cprintf(»
Miide ball is %1.3f»,s/i);

cout<<‘n’
<< q;

break;

}

case
3: {return;}

default:
{cout<<«Error! Try againn»; break;}

}

getch();

clrscr();
}

while(m
!= 3);

return;}

Задания
для самостоятельного решения

При
выполнении приводимых ниже заданий
можно использовать классы, разработанные
в лабораторных работах № 1–3. Осуществлять
контроль состояния потоков. В случае
возникновения ошибок потоков генерировать
и обрабатывать исключительные ситуации.
Для соответствующих классов перегрузить
операции вставки в поток и извлечения
из потока. При динамическом выделении
памяти предусмотреть обработку
исключения, возникающего при нехватке
памяти.

I

а)
Для класса Student
(лаб. работа № 1) предусмотреть ввод
данных из файла. Полученные при выполнении
лаб. работы № 1 списки студентов вывести
в файл.

То же задание для
классов:

б)
Abiturient
(лаб. работа №1);

в)
Aeroflot
(лаб. работа № 1);

г)
Worker
(лаб. работа № 1);

д)
Train
(лаб. работа
№ 1);

е)
Product
(лаб. работа № 1);

ж)
Patient
(лаб. работа
№ 1);

з)
Bus
(лаб. работа
№ 1);

и)
Customer
(лаб. работа № 1);

к)
File
(лаб. работа № 1);

л)
Word
(лаб. работа № 1);

м)
House
(лаб. работа № 1);

н)
Phone
(лаб. работа № 1);

о)
Person
(лаб. работа № 1).

II

а)
При выполнении задания № 1 лаб. работы
№ 2 (класс Com­plex)
предусмотреть формирование массива
объектов путем считывания комплексных
чисел из файла. Результат также вывести
в файл.

То же задание для
классов:

б)
Fraction
(лаб. работа № 2);

в)
Vector
(лаб. работа № 2). Предусмотреть обработку
исключения при динамическом выделении
памяти;

г)
Matrix
(лаб. работа № 2);

д)
Polynom
(лаб. работа № 2);

е)
Stack
(лаб. работа № 2);

ж)
Строка
(лаб. работа № 2);

з)
Set
(лаб. работа № 2);

и)
«Массив строк»
(зад. № 10 лаб. работы № 2);

к)
«Булев вектор»
(лаб. работа № 2);

л)
«Троичный
вектор»
(лаб. работа № 2);

м)
«Булева
матрица»
(лаб. работа № 2).

III

Те
же задания, что и в разделах I
и II,
но для классов, реализующих работу с
динамическими структурами данных (см.
лаб. работу № 3).

Тесты

1. Если имеется код
chara[8];cin>>a; и
вводится текст “HelloWorld”, то что будет в массивеa?

Варианты
ответа:

1)
“Hello W”; 2) “Hello Wo”; *3) “Hello”; 4) “Hello
World”; 5) “lo World”.

2. Что будет выведено
в результате

double
x=12.4;

cout<<setw(5)<<x<<setw(3)<<setfill(‘*’)<<””<<endl;
?

Варианты ответа:

1) 12.40***; *2) 12.4***; 3)
12.4 ***; 4) 12.40; 5) .124e2***.

3. Если имеется код
intx;cin>>x;
и вводится “1.2”, что будет в перемен­нойx?

Варианты ответа:

*1) 1; 2) 2; 3) 1.2; 3)
другое; 4) произойдет ошибка.

4. Какой из классов
используется для вывода строк на экран?

Варианты
ответа:

1)
strstream; *2) ostream; 3) ofstream; 4) istream; 5) ifstream.

5. Каким будет
результат работы программы:

#include
<iostream.h>

void
main (){

char
A[]=”ABC”;

char
_*U=&A[2];

cout<<”n”<<_*U—<<_*U—<<_*U<<endl;
} ?

Варианты ответа:

1) BAA;
*2)CBA.

6. Если имеется код
doublex;cin>>x;
и вводится “12-3”, то что бу­дет в
пе­ре­меннойx?

Варианты ответа:

1) 9.0; *2) 12.0; 3) другое;
4) произойдет ошибка.

7. Для того, чтобы
выполнить чтение из файла с произвольной
по­зиции, надо использовать объект
класса:

1)
strstream; 2) ostream; 3) ofstream; 4) istream; *5) ifstream.

8. Что будет выведено
при выполнении оператора throwC, если заданы классы

class
A {…};

class
B: public A {…};

class
C: public A {…};

а
обработка исключительной ситуации
записана

catch
(B&b) {cout<<1;}

catch
(C&c) {cout<<2;}

catch
(A&a) {cout<<3;}

catch (…)
{cout<<4;}
?

Варианты ответа:

1) 1; *2) 2; 3) 3; 4) 4; 5)
34; 6) 234.

9. Если в конструкторе
класса

classA{

char*ptr;

public:

A()
{ptr=newchar[size];Init();}

~A() {if(ptr)delete[]ptr;}

};

произойдет
исключительная ситуация, будет ли
потеряна память при откате по стеку?

Варианты ответа:

1) да, будет во всех
случаях; 2) будет, только если объект
класса созда­вался с помощью new;
*3) будет, если создавалась автома­тическая
пере­менная классаA;
4) нет, не будет.

10. Об ошибке в
конструкторе класса может сигнализировать:

1) возвращаемое
значение; *2) исключительная ситуация;
3) вы­зов дест­руктора сразу в
конструкторе.

11. Что будет
выведено, если заданы классы

classA{…};

class
B: public A {…};

class
C: public A {…};

а
операторы throwиcatchзаписаны так:

throw
A;

catch
(B&b) {cout<<1;}

catch
(C&c) {cout<<2;}

catch
(A&a) {cout<<3;}

catch(…) {cout<<4;} ?

Варианты ответа:

1) 1; 2) 2; *3) 3; 4) 4; 5)
34; 6) 234.

12. Оператор throwбез аргументов

*1) повторно вызывает
обрабатываемую исключительную си­туацию;

2) вызывает
исключительную ситуацию типа Exception.

13. Что будет
выведено, если заданы классы

classA{…};

class
B: public A {…};

class
C: public B {…};

а
операторы throwиcatchзаписаны так:

throwC;

catch
(B&b) {cout<<1;}

catch
(C&c) {cout<<2;}

catch
(A&a) {cout<<3;}

catch (…)
{cout<<4;}
?

Варианты ответа:

*1) 1; 2) 2; 3) 3; 4) 4; 5)
1234; 6) 234.

ЛИТЕРАТУРА

1. Страуструп,
   Б.Язык программирования С++/Б.
   Страуструп. СПб.:БИНОМ, 1999.

2. Шилдт,
   Г. Самоучитель С++/Г. Шилдт. 3-е изд.
   СПб.:BXV-Петербург, 2002.

3. Эккель,
   Б.Философия С++. Введение в стандартный
   С++/Б. Эккель.2-е изд. СПб.:Питер, 2004.

4. Эккель,
   Б. Философия С++. Практическое
   программирование/Б. Эккель, Ч. Эллисон
   .СПб.:Питер, 2004.

5. Павловская,
   Т.А.С++. Объектно-ориентированное
   программиро­вание: Практикум/Т. А.
   Павловская,Ю. А. Щупак.СПб.:Питер,
   2004.

6. Глушаков,
   С.В.Язык программирования С++/С. В.
   Глушаков, А. В. Коваль, С. В. Смирнов.Харьков:Фолио, 2002.

7. Фридман,
   А. Л.Язык программирования С++. Курс
   лекций/А. Л. Фридман.М.:ИНТУИТ, 2003.

СОДЕРЖАНИЕ

Лабораторная
работа № 1 Тема. Простейшие классы и
объекты 3

Лабораторная
работа № 2 Тема. Разработка классов 9

Лабораторная
работа № 3 Тема. Классы для работы с
динамическими структурами данных 19

Лабораторная
работа № 4 Тема. Шаблоны классов 27

Лабораторная
работа № 5 Тема. Наследование 34

Лабораторная
работа № 6 Тема. Потоки, обработка
исключительных ситуаций в C++ 45

Учебное издание

Романчик Валерий
Станиславович

Люлькин
Аркадий Ефимович

С++.
ЛАБОРАТОРНЫЕ РАБОТЫ

по
курсу «Методы программирования»

Учебно-методическое
пособие

для
студентов механико-математического

факультета

Технический
редактор __

Корректор

Ответственный
за выпуск В.
В. Власова

Подписано в печать
__.__.2005. Формат 60х84/16. Бумага офсетная.
Печать офсетная.

Усл.печ.л. ____.
Уч.-изд.л. . Тираж 100 экз. Зак.

Белорусский
государственный университет.

Лицензия ЛВ №315
от 14.07.98.

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]

• #
• #
• #
• #
• #
• #
• #
• #
• #
• #
• #

Автор: David Chisnall.
Оригинальное название: «Writing Insecure C».
Оригинал статьи: Part 1, Part 2, Part 3 (в данной редакции все три части объединены).
Перевод на русский: n0xi0uzz.
Оригинал перевода: http://netsago.org/ru/docs/1/14/
Коррекция и форматирование: Клуб программистов «Весельчак У».
Публикуется с разрешения автора перевода.

• Введение.
• Проверка ошибок.
• Начальные значения.
• Проблемы целых.
• Проблемы с памятью.
• Буферы и строки.
• Когда все идет не так.
• Отказ от привилегий.
• Разгоняя ядро.
• Заключение.

Использование языка программирования Си часто приводит к написанию очень опасного кода. Но это не совсем справедливое обвинение. Такие проекты, как OpenBSD, показывают, что возможно писать безопасный код на Си. Проблема Си та же, что и в ассемблере — язык открывает вам не только все возможности архитектуры, но и кое-что ещё. Он дает все возможности для написания безопасного кода, но не делает эти вещи сам.

В этой статье рассмотрены стандартные примеры ошибок в коде Си и то, как их и избежать.

Множество современных языков программирования включают в себя некоторый механизм по обработке исключений. Вообще, исключения — это плохая идея. Они усложняют управление ходом программы, и у них есть много недостатков, от которых страдали программы с использованием GOTO перед рассветом структурного программирования. Программист должен проектировать код программы так, чтобы не пришлось обрабатывать исключения. Тем не менее, у исключений есть одно важное преимущество: вы не можете их игнорировать. В частности, код на Java часто засорен блоками try:catch, которые ничего не делают, кроме отбрасывания ошибок, но даже в этом случае механизм исключений преследует цель: это заставляет программиста помнить о том, что он небезопасно обрабатывает условия ошибок.

В Си большинство функций возвращают неправильное значение, когда произошла какая-либо ошибка. Обычно это делается двумя способами. Множество функций возвращают код ошибки ноль в случае успеха. Функции, возвращающие указатели, возвращают правильное значение в случае успеха или ноль в противном случае. Эта ситуация может немного смущать, так как ноль означает и успешное выполнение одних функций, и ошибку в других. Можно возвращать нулевой указатель, его вы не сможете легко проигнорировать, так как получите ошибку сегментации, как только попытаетесь разыменовать его. Этот подход действительно опасен только в тех функциях, которые почти никогда не завершаются с ошибкой, в других ошибка может быть обнаружена во время тестирования и исправлена. Стандартный пример функции, которая почти никогда не завершается с ошибкой — malloc(), наряду со связанными с ней функциями, вроде calloc(). В спецификации Си указано, что malloc() должна вернуть NULL в случае, если памяти недостаточно, чтобы удовлетворить запрос. Linux не полностью следует этому правилу, он возвращает NULL, если в системе недостаточно виртуального адресного пространства, чтобы выполнить выделение памяти, но в случае недостатка памяти Linux по-прежнему выделяет пространство адресов, а затем возвращает ошибку, если вы пытаетесь использовать эту память. Как бы то ни было, исходя из того, что у вас есть подходящая реализация Си, необходимо проверять значения, которые возвращает malloc.

В большинстве случаев вы не сможете сделать ничего разумного, если malloc завершится с ошибкой. Даже код, восстанавливающий ошибку, обычно нуждается в выделении памяти. Вы можете попробовать выделять эту память, когда программа запускается (не забудьте проверить, что вы можете получать к ней доступ). В качестве альтернативы, вы можете использовать что-нибудь вроде этого макроса:

#define MALLOC(x,y) do { y = malloc(x); if (!y) abort(1); } while(0)

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

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

При объявлении локальной переменной компилятор выполняет это как простой инкремент верхнего регистра стека. Начальное значение переменной будет таким, каким последняя функция его установила, использовав эту часть памяти стека. Здесь существуют две потенциальные проблемы. Первая в том, что невозможно предсказать поведение не инициализированной переменной. Вторая в том, что этого может и не быть. В общем, использование значения перед инициализацией приведет к неопределенному состоянию вашей программы. В худшем случае, это может привести к утечке информации. Например, если вы пишете некоторый код, который использует неинициализированную переменную после вызова функции шифрования, ваше «случайное» значение неопределенной переменной может содержать некоторую часть ключа шифрования. Если ваш код запускает скрипты, которые могут читать информацию из стека, это может быть серьезной уязвимостью.

Ещё несколько проблем могут произойти с неинициализированными переменными. Одна из самых ужасных, что я видел, это когда вы начинаете с кода, который выглядит как-то так:

int a = 42;

А затем вы решаете, что вам необходимо условие для инициализации, поэтому вы копируете и вставляете его в выражение if:

if ({некоторое условие})
{
   int a = 42;
}

Ой, вы же забыли объявить переменную за пределами блока if, поэтому вы делаете это позже и даете ей значение по умолчанию:

Теперь у вас есть код, который компилируется и запускается. Большинство времени (когда не встречается условие), он будет работать. Но код внутри фигурных скобок будет «холостым». Он определяет новую переменную под названием «a» и присваивает ей значение 42. Как только блок закончится, эта переменная выйдет из области видимости и останется старая «a», до сих пор со значением 0.

Более незаметный вариант может возникнуть при опечатке в инициализации, когда вы выполняете что-то, вроде этого:

int value = value + 12;

когда на самом деле ожидаете выполнение этого:

int value = othervalue + 12;

Как только компилятор распарсит int value, переменная станет валидной и будет находиться в области видимости. Вы можете считать её значение, добавить 12 к нему и присвоить результат ей же. К несчастью для вас, value, которую вы считываете, не определена. Теперь вам придется присвоить value неопределенное значение. Если вы считываете неосторожно, вы можете подумать, что проинициализировали её, хотя вы этого и не сделали. Компилятор с оптимизацией удалит +12, поскольку неопределенность плюс 12 есть неопределенность, и это будет эквивалентно следующему:

int value;

Если в вашем компиляторе есть выдача предупреждений о том, что не было проинициализировано, он должен выявить эти проблемы. К сожалению, выключение этих предупреждений происходит довольно часто, потому как в Си нет способа указать выходные параметры. Вот почему следующие вещи встречаются относительно часто:

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

Если вы используете высокоуровневые языки программирования, поддержка числовых переменных в Си может показаться мучительно примитивной. То же самое может быть, если раньше вы писали на ассемблере, так как Си также не открывает программисту условных кодов современных ЦПУ. В высокоуровневых языках числа обычно условно-точные, причем точность определена так, как вам надо. В Си есть набор целых типов. Наиболее часто используемый — это int, который должен соответствовать машинному слову. На компьютерах, на которых я учил Си, оно было длиной в 16 бит. Теперь он обычно размером в 32 бита даже на архитектурах, где машинное слово имеет длину 64 бита, так как большое количество написанного кода подразумевает, что он всегда имеет длину 32 бита. Одна из наиболее частых причин странного поведения — попытка хранить значение указателя в int. На обычных 32-битных платформах этот метод работает хорошо. На некоторых 64-битных он работает, а на некоторых — нет. Стандарт C99 определяет новый целый тип, intptr_t, который гарантированно имеет достаточный размер, чтобы хранить указатель. Если вы планируете хранить указатель в int, вы всегда должны использовать intptr_t.

Указатель — один из других, слегка сбивающих с толку, моментов. Си определяет два типа указателей, один указывает на код, другой указывает на данные. Указатель на функцию не имеет гарантированно такой же размер, что и указатель, указывающий на данные. На множестве встроенных платформ часто используются 16-битные указатели для кода и 32-битные для данных. Преобразование типа в void* указателя на функцию приведет к тому, что некоторые данные будут отброшены.

Другим основным видом целого в Си является char, short и long. В C99 также определен long long. Ни один из них не имеет фиксированного размера, но все они имеют минимальные размеры (технически у них есть минимальный набор значений, который они могут хранить, не предоставляя гарантий по внутреннему формату). Short должен быть, по крайней мере, 16 бит, long как минимум 32, а lon long как минимум 64. Если вам необходимо минимальное количество точности, выберите один из них, и вы сможете получить дополнительное пространство к тому, что запросили, в зависимости от архитектуры.

Я не упомянул char ещё и потому, что они детально отличаются от других типов. Все другие основные целые типы данных являются знаковыми, пока не будут объявлены, как беззнаковые. Это не всегда так в случае с char. К сожалению, в случае с char, знаковая она, или нет, полностью зависит от реализации. Если вы используете char, всегда явным образом объявляйте их как знаковые или нет, так как в противном случае вы можете быть удивлены позже.

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

a = b + c;

Так как вы храните результат в «a», вы можете предположить, что сложение будет выполнено, каким бы типом ни была «a». По факту, оно будет выполнено с типом «b» и «c». Это имеет смысл тогда, когда вы думаете, что лучше иметь значение (b + c) в зависимости от чего-то, чем «b» и «c» сами по себе. Вы можете думать, что тип этого выражения будет типом «b». Стандарт C99 определяет набор правил для определения типа, но в основном он будет представлять собой тот тип, который больше, «b» или «c». Например, если «a» — char, а «b» — int, тип выражения будет int. Поразительно часто встречается ошибка, когда делают что-то вроде такого:

long long a;
long b; // = чему-то
long c; // = чему-то
a = b * c;

Размерность «a» как минимум 64 бита, «b» и «c» как минимум 32 бита. Так как у вас есть только гарантия того, что «b» и «c» по 32 бита, вы не должны помещать нечто большее в них, даже если ваш компилятор или платформа имеет long в 64 бита. Когда вы умножаете их, вы получаете результат, подходящий для 64-битного int и вы храните его в чем-то, что подходит для 64-битного int. Звучит удобно? Так и есть, кроме того факта, что результат искажается до 32 бит прямо перед присваиванием. Вот правильный способ сделать это:

a = (long long)b * c;

realloc() — ещё одна проблема. Нет стандартного пути сделать это с ней, поэтому вам надо делать это самому. К счастью, OpenSSH включает в себя xrealloc(), который является версией realloc() с проверкой границ. Она включает несколько других проверок, но если вам не нужны все из них, вы можете реализовать упрощенную версию:

Этот тест довольно прост. SIZE_T_MAX — это максимальное значение, которое может иметь size_t. Когда вы делите на указанное количество элементов, вы получаете максимальный размер, который может быть без переполнения. Если этот размер меньше, чем требуемое пространство, возникает переполнение, поэтому вы возвращаете NULL. realloc возвращает NULL в случае ошибки, так что вам всегда следует проверять возвращаемое значение realloc на валидность. К сожалению, это является наиболее частой причиной утечек памяти (которые, в свою очередь, являются причиной атак DDoS). Если realloc() возвращает NULL, исходный указатель по-прежнему является валидным. Часто разработчики забывают этот принцип и просто делают что-то вроде этого:

ptr = realloc(ptr, newsize);

Когда realloc() возвращает NULL, вы теряете вашу ссылку на предыдущее выделение памяти. FreeBSD предоставляет удобную функцию, reallocf(), которая эквивалентна следующей:

Если у вас нет кода для обработки случая, когда realloc() завершается с ошибкой, вам необходимо использовать что-то вроде неё.

Модель организации памяти в Си делит память на два участка — куча и стек. Память в куче выделяется и освобождается вручную. Память в стеке является контекстной — она выделяется автоматически при входе в блок и освобождается, когда блок завершается. Эта методика приводит к проблемам при передаче данных назад к вызываемой функции. Для структур очевидным решением является просто вернуть структуру. Когда она скомпилирована, вызывающая функция может выделить структуру и передать указатель к вызываемой функции, которая копирует данные в свое пространство. Тем не менее, это приводит к большому количеству копий. Что ещё хуже, это не работает для всех динамически выделяемых данных. Рассмотрим что-нибудь, вроде sprintf(). Этот аналог printf() пишет в буфер вместо стандартного вывода. Проблема sprintf в том, что вызывающей функции необходимо знать размер буфера, что не всегда просто — на самом деле, это требует реализации большинства кода sprintf в вызывающей функции. По факту, почти невозможно использовать sprintf безопасно. Вам необходимо указать длину каждого отдельного элемента строки формата (вот почему sprintf была создана). Это может привести к завершению процесса (что может также вызвать проблемы безопасности, и мы вернемся к этому позднее), поэтому некоторые реализации libc включают в себя asprintf().

Функция asprintf() — это то же самое, что и sprintf, кроме того, что она выделяет свой собственный буфер с помощью malloc. Это позволяет избежать досрочного завершения процесса или переполнения. К несчастью, она приносит новую проблему, когда вызывающая функция должна освобождать указатели, которые возвращает вызываемая функция.

Большое количество кода на Си содержит в себе эту проблему. Решение обычно заключается в том, чтобы поместить в документацию о функции строку «вызывающая функция должна освободить возвращаемый указатель». К сожалению, этот подход делает сложной возможность взглянуть на часть кода и увидеть, валидна ли она. Одно из решений заключается в том, чтобы заключать в оболочку каждый указатель, например, так:

typedef struct _RefCountedBuffer
{
    void *buffer;
    int refcount;
    void (free*)(struct _RefCountedBuffer*);
} *RefCountedBuffer;

Когда вы возвращаете указатель, вы создаете одну из этих структур и устанавливаете refcount в 1. Когда вы получаете его, вы всегда вызываете функцию, которая увеличивает refcount на единицу и вызывает соответствующую функцию free(), если она достигнет нуля. Эта методика близка для программистов Objective-C, потому как OpenStep реализует схожий механизм работы. GNUstep продвинулся дальше, предоставляя макросы ASSIGN() и DESTROY(). Эти макросы делают ошибки при работе с памятью более редкими, и мы можем сделать нечто похожее на обычном Си.

Прежде всего, нам надо определить функции retain() и release():

Определив эти функции, вы можете определить макросы SET и FREE следующим образом:

#define SET(var, val) do {
    RefCountedBuffer __tmp = retain(val);
    if (NULL != var) release(var); var = __tmp; } while(0)

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

#define FREE(var) do { release(var); var = NULL; } while(0)

Этот макрос гарантирует, что каждый указатель всегда установлен в NULL после его освобождения. Даже если вы не используете подсчет ссылок, этот метод дает результат. Если вы используете оба этих макроса, у вас будет очень мало знаков равенства в коде. Что делает проще просмотр кода и поиск места, где могут быть ошибки, связанные с памятью. Подсчет ссылок — хорошее решение для данных, предназначенных только для чтения. Вы можете вернуть некоторый внутренний компонент большой структуры данных в качестве ссылки, не удаляя его из оригинальной структуры, пока его не перестанут использовать — так долго, как он находится в структуре RefCountedBuffer в обоих случаях. Тем не менее, эта модель не решает нашу первоначальную проблему функций, похожих на asprintf. Она требует вернуть строку, что часто используется только в вызывающей функции. Для этого выделение памяти в куче и заключения её в структуру подсчета ссылок будет лишним. Вам нужен способ выделить пространство в стековом фрейме вызывающей функции.

У разработчиков сервера Dovecot IMAP есть превосходное решение. В дополнение к обычному контролю стека они делают отдельный стек данных и аналог asprintf, которая использует его. Вызывающая функция сначала вызывает функцию, которая выделяет фрейм в новом стеке данных. Затем она вызывает аналог asprintf(), которая выделяет пространство в стеке результатов. Этот подход работает правильно, пока вызывающая функция достает верхний фрейм стека данных. Так как контрольный стек и стек данных работают на разных скоростях, вы можете просто вернуть данные в стек данных. Работа организована таким образом, что сначала создается фрейм в стеке данных, а затем вызывается asprintf(), которая выделяет пространство в текущем фрейме стека данных и помещает результат в него. Вы используете результат, а затем выталкиваете из стека текущий фрейм.

Вам ничего не мешает иметь несколько независимых областей памяти. Вы можете использовать mmap() на /dev/zero, чтобы выделить где-либо непрерывный блок памяти и использовать его по своему желанию. Одной из возможных идей может быть выделение стека данных, который работает на такой же скорости, как и контрольный стек. Используйте этот метод для всех массивов, которые вы будете по-другому выделять в стеке. В отличие от контрольного стека. Вы можете сделать его переместимым, постоянно адресуя его через глобальный указатель к началу. Например, с помощью подобного макроса:

#define NEW_ARRAY(type, name, elements)
    __attribute__((cleanup(popDataStack)))
    type *name = dataStackCalloc(sizeof(type), elements)

Как бы то ни было, вы до сих пор можете выйти за пределы массива. Вы не разрушите возвращаемый адрес, но можете переписать некоторые данные, или могут возникнуть другие проблемы. Вы можете избежать выхода за пределы стека данных, вызвав функцию mprotect() на последней странице стека, чтобы удалить все права доступа. У большинства реализаций malloc() есть режим отладки, который вставляет этот вид защитной страницы после каждого выделения памяти. Вы можете сделать это, создав свой стек данных, в котором будут чередоваться доступные и недоступные страницы, с каждым выделенным массивом, так что он завершится недоступной страницей, но эта система достаточно ресурсоемка. Никакая нормальная операционная система не выделит реальную память для защитных страниц, но вы потеряете много пространства в промежутках между началами страниц и началами массивов и будете использовать большое количество адресного пространства.

Строки в Си — вечная причина проблем. Когда Си был создан, было две концепции о том, как лучше всего реализовывать строки — известные сейчас как строки Си и строки Pascal, в соответствии с языками, которые сделали эти идеи популярными. Такие языки, как Lisp использовали третью реализацию: строки являлись связанным списком символов (Erlang до сих пор использует эту модель). Строки в стиле Lisp имеют очевидный недостаток. Каждому символу требуется один байт для хранения символа и 4 или 8 байт для хранения адреса следующего, до девяти байт уходит на хранение одного байта данных. Эта структура далека от идеальной, но делает разделение и конкатенацию строк очень простой.

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

Большинство «классических» строковых функций практически невозможно использовать безопасно (по этой причине линковщик OpenBSD легко выдает предупреждение, когда вы используете одну из них). Каноническим примером «плохой» функции является strcat(), которая принимает два указателя на строки Си. Функция проходит по первой строке, пока не найдет null, она записывает в нее байты из второй строки пока не дойдет до null во второй строке. Вызывающая функция должна быть уверена, что существует достаточно места в первой строке, чтобы сохранить вторую.

Более новая функция, strncat(), была создана, чтобы сделать это легче. Эта функция принимает в качестве третьего аргумента объем пространства в первой строке. Она гарантирует, что функция никогда не выйдет за пределы первой строки, но создает новую проблему, функция возвращает новую строку в качестве результата, поэтому вы не можете легко протестировать, был ли искажен результат. Это становится большой проблемой, когда соединяемые части являются, например, паролем.

В OpenBSD представлена strlcat, которая похожа на strncat, но возвращает сумму входных строк. Если результат работы функции больше третьего аргумента, имело место искажение. Эта функция находится в каждой ОС семейства BSD (включая Darwin/OS X), но её нет в glibc, так как, согласно главному разработчику glibc, является «бесполезным хламом BSD». К счастью, лицензия BSD позволяет вам копировать эту функцию из libc BSD в ваш код без каких-либо проблем.

Проблемы со строками в Си велики из-за того факта, что строки — это просто массивы без проверки границ. Точно также большинство проблем, затрагивающих строки, касаются и произвольных буферов.

Одной из самых опасных вещей в C99 является модель массивов переменной длины, которая позволяет вам выделять маленькие, с динамическим размером массивы в стеке. Вы можете всегда делать это с помощью alloca(), хотя качество реализаций alloca() варьируется между разными платформами. Следующие примерно эквивалентны:

Разница в поведении, если существует недостаточно пространства для роста стека до n целых значений. Первая строка будет при этом NULL, но вы сможете проверить это, что упрощает отладку — достаточно просто обратиться к началу массива. Во второй строке, если не будет хватать размера стека, он будет указывать: куда-то. А куда именно, будет зависеть от реализации. Вот почему, если вы используете массивы C99 с переменной длиной, невозможно протестировать программу на переполнение стека. В большинстве случаев это не является проблемой. Небольшие выделения памяти более безопасны для работы, но если взломщик сможет увеличить размер n, у вас может получиться массив, указывающий никуда.

Это является серьезной проблемой в зависимости от того, как реализован стек. В основном, нижняя часть стека является верхней границей памяти процессов, и она растет вниз. Если у вас есть массив в стеке, и вы выходите за его границы, вы перезаписываете стековый фрейм вызывающей функции. И что ещё хуже, также перезаписываете возвращаемый адрес. Если вы используете что-то вроде strcat() с результирующей строкой в стеке, очень легко перезаписать возвращаемый адрес, позволяя взломщику контролировать, где происходит переход к выполнению, после того, как функция вернула результат.

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

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

Ключом к безопасному программированию каждой части вашей программы является представление, что другая часть была написана идиотом. Вы можете проверить, что каждый входящий указатель — не NULL (хотя печально, что Си не предоставляет какого-либо механизма для проверки, что он указывает на валидную часть памяти). Вы можете проверить, что любые другие значения находятся в ожидаемых вами рамках. Тем не менее, в конце концов, баг в одной части процесса может разрушить данные — а во многих операционных системах, даже код — всей остальной части процесса.

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

Разбивая компоненты программы на отдельные процессы, вы ограничиваете размеры разрушений, которые может принести один баг. Самым распространенным примером является разделение привилегий кода, находящееся во множестве серверных программ. Многие сервера должны быть запущены под root или с соответствующими правами. Им нужна эта возможность для привязки к соответствующим портам и осуществления других действий в качестве root, таких, как получение доступа к данным разных пользователей или запуск программы под другим пользователем. Хорошим методом для такого вида процессов является заключение кода, осуществляющего привилегированные операции, в отдельный процесс. Например, если вам надо написать на разные почтовые ящики пользователей, у вас может быть процесс, который запускается под root, чтобы открыть почтовый ящик, написать в него письмо и больше ничего. Он проверит аргументы и осуществит запись, но не более того. Это легко реализовать в коде и довольно просто найти возможные баги. Также можно изолировать код, содержащий важную информацию. Большей части программы не надо знать, например, ключей шифрования или паролей. Вы можете хранить такую информацию в отдельном процессе и ограничивать доступ главной программы к нему, усложнив тем самым для взломщика получение доступа к этим данным.

Хотя разделение привилегий работает хорошо, многое может быть сделано благодаря простому отказу от привилегий. UNIX содержит семейство системных вызовов setuid(), которые позволяют процессу, запущенному в качестве root, работать как другой пользователь.

Веб-сервер нуждается в запуске в качестве root, так как ему нужно быть привязанным к 80 порту и иметь доступ к файлам в директории public_html каждого пользователя. Тем не менее, как только он привязан к 80 порту, ему не нужно более работать как root, и он может отказаться от прав root. Хотя ему по-прежнему нужен способ получать доступ к директории public_html каждого пользователя. Одно решение — заставить каждого пользователя сделать его файлы доступными для группы веб-сервера. Другим может быть выполнение fork() процесса-потомка для каждого пользователя, который работает в качестве этого пользователя и имеет доступ к файлам в директории пользователя.

Немного повысить безопасность можно, используя системный вызов chroot(), который меняет корневую директорию (которая видна процессу) на специальную директорию. Любые файлы за пределами этой директории находятся вне зоны видимости, хотя к тем, что были открыты, доступ по-прежнему остается. Этот факт важен, так как вы можете держать библиотеки и даже исполняемую программу, а также файлы настройки вне «тюрьмы» chroot.

Пользователь с правами root может легко избежать chroot, создав новое устройство для жесткого диска и смонтировав его внутрь chroot (или даже получая доступ к нему напрямую). Вот почему важно сбросить привилегии root сразу же после входа в chroot.

Ещё легче использовать chroot(), если он встроен в приложение. Команда chroot, которая запускает процесс в окружении chroot, также доступна, но этот подход имеет две проблемы. Первая — он вызывает chroot до запуска процесса, поэтому программа и все необходимые библиотеки должны быть внутри директории chroot. Вторая заключается в том, что он должен выполняться в качестве root, поэтому ему нужно что-то внутри chroot для возможности сброса привилегий. Обычным решением является поместить команду su внутрь chroot. Хотя, когда вы поместите так много кода внутрь chroot, он станет выглядеть, как и внешнее окружение.

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

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

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

К сожалению, этот подход имеет немного неожиданное поведение. Многие системные вызовы принимают указатели в качестве аргументов. Обычно ядро отображается в адресное пространство каждого процесса (но в режиме привилегий помечается только как для чтения), поэтому обработчик системного вызова в ядре может получить доступ к тому, на что указывают эти указатели дешево (без копирования). Даже если он не может получить к ним доступ напрямую на платформах, где ядро имеет полностью отдельное адресное пространство, обычно оно так же может получать доступ к адресному пространству процесса дешево. Если вы производите системный вызов с указателем, вот добавочный шаг:

Другой поток изменяет данные, на которые указывает аргумент-указатель.

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

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

Писать безопасный код на Си сложно, но это возможно. Безопасность таких систем, как OpenBSD доказывает, что это можно сделать. Язык не делает написание безопасного кода простым, но в некоторых случаях этот факт является полезным. Чтобы избежать проблем, программист должен основываться на хорошем коде, а не на возможностях языка.

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

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

Об ошибке в конструкторе класса может сигнализировать:

вопрос

Правильный ответ:

Комментарии:

Другие ответы на вопросы из темы программирование интуит.

• #

  В чем заключается назначение оператора перехода goto?

• #

  Отметьте, какому определению функции может соответствовать вызов func(5.98):

• #

  Как называется функция, которая вызывает саму себя?

• #

  Что из себя представляет динамическое выделение памяти?

• #

  Что будет напечатано в результате выполнения следующего кода?

  int x=39, *p = &x;
  cout << p << «__» << *p ;