Re: Allocating memory for part of a C struct

Pavel Minaev wrote:
On Sep 8, 5:30 pm, "Ben Voigt [C++ MVP]" <r...@xxxxxxxxxxxxx> wrote:
"Ben Voigt [C++ MVP]" <r...@xxxxxxxxxxxxx> wrote in message
news:e%23W4z$1DJHA.1180@xxxxxxxxxxxxxxxxxxxxxxx
True, but this is the C++/CLI group. So including some information
on interop might be useful (e.g. you can't use a buffer on the
managed heap unless you also pin it).

Well, there's always stackalloc... er, _malloca

That wouldn't put a buffer on the managed heap.

Why would it need to be on the managed heap, if it's just used for
interop?

You presented it as a counter-example to my statement that you can't use a
buffer on the managed heap without pinning. Or that's how I understood it.


It is non-standard in a sense that the ISO C++ standard prescribes
undefined behavior for this construct. It is precisely why it was
treated specially in C99 in form of open-sized arrays, to guarantee
that this idiom was actually blessed by the Standard.

Well, I'm pretty sure you are allowed to use the memory returned by
malloc as the TXFS_READ_BACKUP_INFORMATION_OUT structure, as long as
the size is at least sizeof TXFS_READ_BACKUP_INFORMATION_OUT. I
suppose the issue is that the compiler is not required to layout the
structure with the array at the end, so you might be walking over a
footer or some other field when you reference using the array name?
Explicitly referencing the memory immediately past the structure
should be ok by the standard as long as the requirement that the
extra space be allocated by the caller is stated, right?

Unfortunately, no. The Standard explicitly states that accessing an
array using an out-of-bounds index is U.B., without giving any
exceptions (such as the fact that memory accessed is allocated, etc).
In fact, you don't even have to dereference to get U.B. - it's already
happening at the pointer arithmetic stage. Recall that (p + i), where
p is pointer, and i is index, is only valid pointer arithmetics when
you're within the same object (object here defined as either array or
an individual value that the pointer is pointing to - not the
allocated memory block to which it belongs).

I disagree. You can cast back to the original allocated object type, which
is array-of-char, and then all indices within the originally requested size
are legal and well-defined, including those past the sub-range of memory
which has been used as an object of class type.


.

Relevant Pages

  • Re: Library Design, f0dders nightmare.
    ... first demo mistake but I suggest to you that a sequence of blunders ... The stack is only used temporarily while creating the argv array. ... in the input buffer. ... so you are not wasting memory. ...
    (alt.lang.asm)
  • Re: Allocating memory for part of a C struct
    ... That wouldn't put a buffer on the managed heap. ... I'm pretty sure you are allowed to use the memory returned by malloc ... the compiler is not required to layout the structure with the array at the ...
    (microsoft.public.dotnet.languages.vc)
  • Re: Allocating memory for part of a C struct
    ... That wouldn't put a buffer on the managed heap. ... It is non-standard in a sense that the ISO C++ standard prescribes ... the compiler is not required to layout the structure with the array at the ...
    (microsoft.public.dotnet.languages.vc)
  • Re: How to cast a buffer pointer into a byte array
    ... allocates a buffer in memory. ... After filling this buffer (with bitmap ... array ) because this is the type the OCX display control it ... Is there a way to send a pointer to the buffer ...
    (microsoft.public.vb.syntax)
  • Re: return a string
    ... Declare a static array of char in your ... mallocmemory for the string inside your function ... >> provide a way to use an alternative allocation function. ... Pass an already allocated buffer and its size to your function. ...
    (comp.lang.c)
Quantcast