[erlang-bugs] ERL_NIF_TERM type collision

[Patrick Baggett]

At this point, you're effectively fighting the compiler. You could try an
enum since enum values aren't directly convertible to integers without an
explicit typecast -- maybe the compiler will get the hint.
Do you really need to have the exact same name? Is it completely infeasible
to have a function like int get_nif(...) instead of just "get" as an
overload? (aka: the easy solution)

Patrick


On Sun, Mar 18, 2012 at 8:07 PM, Daniel Goertzen
<daniel.goertzen@REDACTED>wrote:

> I am working on a c++ nif and have an overloaded function that takes a
> number of different types including integers and ERL_NIF_TERMs.  The
> problem is that ERL_NIF_TERM really just an integer and collides with my
> integer functions, for example:
>
> int get(std::string var) {...}
> int get(unsigned long var) {...}
> int get(ERL_NIF_TERM var) {...}  //compile error because ERL_NIF_TERM is
> really an unsigned long.
>
> It would be great it ERL_NIF_TERM was a unique type so it could be used in
> this situation.
>
> My first attempt to solve this involved creating wrappers for each NIF API
> function.  The wrapper used a new unique type instead of ERL_NIF_TERM, and
> did type casting as needed.  It was a type punning bloodbath.  This was
> complex and unsatisfactory.
>
> My second attempt was to hack erl_nif.h to change the definition of
> ERL_NIF_TERM to a struct containing an int, and this worked great.  But
> this is not very portable due to the custom erl_nif.h.  Also, I don't know
> enough about linkers to know for sure if this is permitted.
>
>
> Has this problem come up before?
>
> Is there some easy alternative that I am missing?
>
> Should I submit a patch for the erl_nif.h hack? (It is conditionally
> compiled, by default nothing changes)
>
>
> Thanks,
> Dan.
>
> _______________________________________________
> erlang-bugs mailing list
> erlang-bugs@REDACTED
> http://erlang.org/mailman/listinfo/erlang-bugs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-bugs/attachments/20120318/ea949d82/attachment.htm>