This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [patch] libstdc++/67747 Allocate space for dirent::d_name


Other than that, I tend to be leery of using plain char arrays
as buffers for objects of bigger types. I don't know to what
extent this is a problem for libstdc++ anymore as more and more
hardware is tolerant of misaligned accesses and as the default
new expression typically returns memory suitably aligned for
the largest fundamental type. But since there is no requirement
in the language that it do so and I would tend to err on the
side of caution and use operator new (as opposed to
new char[len]).

Actually, after re-reading 5.3.4, I see that this idiom is supposed
to be safe. Paragraph 11 has this note explaining the requirement
for the char array form of the new expression to adjust offset
the (already aligned) pointer returned by the allocation function
by a multiple of the strictest fundamental alignment:

  Note: Because allocation functions are assumed to return pointers
  to storage that is appropriately aligned for objects of any type
  with fundamental alignment, this constraint on array allocation
  overhead permits the common idiom of allocating character arrays
  into which objects of other types will later be placed.

Sorry for sounding the false alarm. I must have been remembering
problems with arrays allocated on the stack.

Martin


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]