This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC 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] | |
Geoffrey Keating <geoffk@geoffk.org> writes:
For malloc-ed memory, I strongly support the
idea that the first store should determine its type and the type can't
change after that.
If I understand that correctly, that would break many existing programs, including BFD.
Could you give an example? I'm having trouble of thinking of any portable code for which this would be useful and not easily avoided.
It is possible that I misunderstood your proposal.
In BFD, we have structures like this in allocated memory:
struct elf_link_hash_entry {
...
union
{
/* If this is a weak defined symbol from a dynamic object, this
field points to a defined symbol with the same value, if there is
one. Otherwise it is NULL. */
struct elf_link_hash_entry *weakdef;
/* Hash value of the name computed using the ELF hash function.
Used part way through size_dynamic_sections, after we've finished
with weakdefs. */
unsigned long elf_hash_value;
} u;
...
};
Here u.weakdef is used in the first pass of the link, through adjust_dynamic_symbol. u.elf_hash_value is used starting at size_dynamic_sections.
This is a simple hack to decrease linker memory usage. It is portable and, I believe, fully standards compliant. It is a case in which malloc'ed memory changes type after the first store. Certainly it can be avoided, but that is not the point. I think the code is correct and reasonable, and I think gcc should not break it.
As I say, I may have misunderstood your suggestion.
void * mem = malloc (max (sizeof (int), sizeof (float)); *(int *)mem = 1; *(float *)mem = 2.0;
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
| Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
|---|---|---|
| Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |