[Issue 7854] Non-C attributes allowed on extern(C) function parameters

[d-bugmail at puremagic.com]

http://d.puremagic.com/issues/show_bug.cgi?id=7854



--- Comment #8 from Maxim Fomin <maxim at maxim-fomin.ru> 2012-04-15 01:15:46 PDT ---
When extern(C) appears it boils down to:

1) either it is used with purely C features:
extern (C) int *array_func (int *array, size_t size);
This is heavily used when interfacing D code with C libraries and vice versa.

2) or it is used with non-C features:
extern (C) int[] array_func (int[] array);
Assumptions here are following:
- array_func is in different object file which was made (possibly) by different
implementation of which current source code is compiled (it may be even not D);
- such another implemenation mangles names differently, to overcome this
obstacle there is need to remove any mangling;
- but such implementation handles at least arrays (as in the example) equally
with current implementation. As new features would be introduced in
declaration, more features should be treated equally.

Although compiler (and programmer) can distinguish among 1) and 2) the problem
is worsen by the fact that much depends on what will be happening after
compilation and compiler cannot solve such things. 

Shortly speaking, the fact that dmd allows such thing is a loophole to link D
code with something that couldn't be used directly but has something common
with current implementation of D and is worth using. It is an option, and it is
a tradeoff between possible benefits and bugs. I do not know about any benefits
which it gives now, but it may change in the future. The first idea is that
different D compilers may mangle names differently, but ABI page at dlang.org
states that all implementations should conform to one mangling standard.
However, it is not official standard and nobody can enforce to follow it. 
Speaking about possible bugs it is clear that they are obvious (in majority
cases the code with 2) even wouldn't contain hidden bug but would not work).
So, code containing something like 2) means that it was written by somebody 
who either knows what he is he doing, or is looking for problems.

Possible solutions:
1) forbid non-C features in extern(C) as it was suggested. D code could be
linked only with C, D (suggesting that every D implementation follows abi page,
otherwise D community would have big problem) and any other language which can
be interfaced in C way.
2) leave the situation as it is. The only problem would come from code written
by people who experince difficulties in distinguishing D and C
3) forbid non-C features in extern(C) as it was suggested but introduce
directive that instructs compiler not to mangle function names.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------