• Neal Alexander <wqeqweuqy hotmail.com> Jan 07 2008
• Robert DaSilva <sp.unit.262+digitalmars gmail.com> Jan 07 2008
• Neal Alexander <wqeqweuqy hotmail.com> Jan 08 2008
• Neal Alexander <wqeqweuqy hotmail.com> Jan 08 2008

Neal Alexander <wqeqweuqy hotmail.com> writes:

link.exe (Assertion failure: 'len <= IDMAX' on line 129 in file
'libin.cpp')

I saw on the C++ newsgroup it happens when identifiers are too long in 
an object file. The question is whats the best way igure out which ID is 
causing it? All the symbols in the source code are nowhere near the 512 
limit.

I tried playing with the dmd/objdump tool but diddnt diddnt see anything 
  glancing over the output.

Robert DaSilva <sp.unit.262+digitalmars gmail.com> writes:

Neal Alexander wrote:
 link.exe (Assertion failure: 'len <= IDMAX' on line 129 in file
 'libin.cpp')
 
 I saw on the C++ newsgroup it happens when identifiers are too long in
 an object file. The question is whats the best way igure out which ID is
 causing it? All the symbols in the source code are nowhere near the 512
 limit.
 
 I tried playing with the dmd/objdump tool but diddnt diddnt see anything
  glancing over the output.


Do you have any templates, they tend to have long mangled names.
It could also be a deeply nested identifier.

Neal Alexander <wqeqweuqy hotmail.com> writes:

Robert DaSilva wrote:
 Neal Alexander wrote:
 link.exe (Assertion failure: 'len <= IDMAX' on line 129 in file
 'libin.cpp')

 I saw on the C++ newsgroup it happens when identifiers are too long in
 an object file. The question is whats the best way igure out which ID is
 causing it? All the symbols in the source code are nowhere near the 512
 limit.

 I tried playing with the dmd/objdump tool but diddnt diddnt see anything
  glancing over the output.


 Do you have any templates, they tend to have long mangled names.
 It could also be a deeply nested identifier.


Yea its a mixin template causing it im pretty sure. I tried making 
identifiers 1-2 chars long but it doesnt help.

http://paste.dprogramming.com/dpfxrbb1 If youre interested.

The point of the code is to transparently wrap 32/64bit structs and 
endian conversion. It uses a proxy struct with enum indexing and 
offset/size tables.

Neal Alexander <wqeqweuqy hotmail.com> writes:

Neal Alexander wrote:
 Robert DaSilva wrote:
 Neal Alexander wrote:
 link.exe (Assertion failure: 'len <= IDMAX' on line 129 in file
 'libin.cpp')

 I saw on the C++ newsgroup it happens when identifiers are too long in
 an object file. The question is whats the best way igure out which ID is
 causing it? All the symbols in the source code are nowhere near the 512
 limit.

 I tried playing with the dmd/objdump tool but diddnt diddnt see anything
  glancing over the output.


 Do you have any templates, they tend to have long mangled names.
 It could also be a deeply nested identifier.


 Yea its a mixin template causing it im pretty sure. I tried making 
 identifiers 1-2 chars long but it doesnt help.
 
 http://paste.dprogramming.com/dpfxrbb1 If youre interested.
 
 The point of the code is to transparently wrap 32/64bit structs and 
 endian conversion. It uses a proxy struct with enum indexing and 
 offset/size tables.


Ok so, obj2asm.exe gave much more useful output.

It turns out the length of a mixin string affects the symbol names 
generated.

__body__ generated a 750 byte identifier:

extrn	_D14reflect_txtgen3635__T8�body�VG4yaa4_45686472VA���8���c6633325f���2a2078���3b����4������3b���1746_656e7�d���b�655f74797���2c���6d61���8696e���76�7273���f6e�����Ȁ��79���0���f66ɀ����Ā������16773���8���7a��怄€�ր�������ڀ��������ف������82c7d3b���6���963���3��Ҁ�����5������45b5�����Ā��03���5��������€�����2c������5��������Ѐ��5������������e�����������������������Ԁ��������������́�����ⅎ��������������������������م����셧�����������������������������
�����������Ⅸ����� ����������������d3b���61�96320��τ�����2075��℃�45b5dۀ���
�03���5bۇ����€��� ������������������솋���������������І����҅�������������������������������Ȇ�
��Ȁ����Ȁ�ꅤȀ��� Ȁ�� Ȁ��� ȁ��� ȁ�Ѕ ȁ�҄�؀����؂������
Ȁ�����d3bZ8__body�xAya


Splitting up the struct definition into smaller const char[] variables 
and concatenating them in __body__ fixed it (making each their own 
template crashes DMD).