И вот почему:
char x;
char *y=malloc(1);
char *z=alloca(&x-y);
*z = 1;
Не то, чтобы кто-то писал этот код, но аргумент размера, который вы передаете alloca
, почти наверняка исходит из какого-то ввода, которое может быть злонамеренно направлено на получение ваша программа для alloca
чего-то такого огромного. В конце концов, если размер не основан на вводе или не может быть большим, почему вы просто не объявили небольшой локальный буфер фиксированного размера?
Практически весь код, использующий alloca
и / или C99 vlas имеет серьезные ошибки, которые приведут к сбоям (если вам повезет) или компрометации привилегий (если вам не повезет).
Вы всегда можете разместить среду CLR в своем собственном приложении.
Если у вас есть собственное приложение C ++ и вы не хотите "загрязнять" его слишком большим количеством элементов среды CLR, вы можете включить флаг / clr
только для одного конкретного файл и используйте стандартный заголовок C ++, чтобы предоставить ему интерфейс. Я сделал это в старом коде. В заголовке у меня есть:
void SaveIconAsPng(void *hIcon, const wchar_t *pstrFileName);
Итак, остальная часть программы имеет простой API, которому она может передавать HICON и путь к файлу назначения.
Затем у меня есть отдельный исходный файл, единственный, у которого есть / clr
включен:
using namespace System;
using namespace System::Drawing;
using namespace System::Drawing::Imaging;
using namespace System::Drawing::Drawing2D;
#include <vcclr.h>
#include <wchar.h>
void SaveIconAsPng(void *hIcon, const wchar_t *pstrFileName)
{
try
{
Bitmap bitmap(16, 16, PixelFormat::Format32bppArgb);
Graphics ^graphics = Graphics::FromImage(%bitmap);
graphics->SmoothingMode = SmoothingMode::None;
Icon ^icon = Icon::FromHandle(IntPtr(hIcon));
graphics->DrawIcon(icon, Rectangle(0, 0, 15, 15));
graphics->Flush();
bitmap.Save(gcnew String(pstrFileName), ImageFormat::Png);
}
catch (Exception ^x)
{
pin_ptr<const wchar_t> unmngStr = PtrToStringChars(x->Message);
throw widestring_error(unmngStr); // custom exception type based on std::exception
}
}
Таким образом, я могу преобразовать HICON в файлы PNG из моей устаревшей программы на C ++, но я изолировал использование платформы .NET от остальной части кода - так что если я позже нужно будет переносить, я могу легко заменить его в другой реализации.
Книга C ++ / CLI в В Action есть глава «Смешивание управляемого и собственного кода», а внутри главы под заголовком «Работа с механизмами взаимодействия» рассказывается как о доступе к управляемой библиотеке из собственного кода, так и о доступе к собственной библиотеке из управляемого кода. Это действительно помогло мне понять концепцию, когда я когда-то ее читал.
в нем говорится как о доступе к управляемой библиотеке из собственного кода, так и о доступе к собственной библиотеке из управляемого кода. Это действительно помогло мне понять концепцию, когда я когда-то ее читал. в нем говорится как о доступе к управляемой библиотеке из собственного кода, так и о доступе к собственной библиотеке из управляемого кода. Это действительно помогло мне понять концепцию, когда я когда-то ее читал.Вызов кода .NET из C ++ / CLI очень прост. Это очень похоже на обычный C ++. Убедитесь, что ваш проект настроен как проект C ++ / CLI, добавьте ссылку на сборку .NET, перейдя в свойства проекта в разделе «Общие свойства», затем используйте свои объекты .NET с таким кодом, как этот:
using namespace System;
using namespace System::Collections::Generic;
using namespace MyNamespace;
void MyFunctionCall()
{
MyObject ^obj = gcnew MyObject();
obj->MyMethod();
// ...
}