[Ns-bugs] [Bug 156] Rename string.h header to nsstring.h to ease gccxml parsing

[bugzilla-daemon@nsnam-www.ece.gatech.edu]

http://www.nsnam.org/bugzilla/show_bug.cgi?id=156





------- Comment #1 from mathieu.lacage at sophia.inria.fr  2008-03-31 16:03 -------
(In reply to comment #0)
> In the gjc/ns-3-pybindgen-notracing branch I had to enable a workaround:
> 
>     http://code.nsnam.org/gjc/ns-3-pybindgen-notracing/rev/1431a85ce21b
> 
> to avoid the following GCC-XML bug:
> 
>     http://www.gccxml.org/Bug/view.php?id=6682
> 
> The bug is due to string.h being the same name as a standard include.  The
> workaround involves forcing GCC-XML to parse this include before all others.  
> 
> It seems to work, though it's kind of ugly.  Maybe it's better to rename
> string.h to nsstring.h, like we have nstime.h instead of time.h?

Well, I would much rather have nstime.h renamed to time.h since I don't think
there are any technical reasons for this nstime.h name. I mean, next time, it
will be socket.h or some other header: the race to make sure that we do not
have similarly-named headers (as system headers) is sure to be lost one day or
another.

Could it be that a "simpler" fix would be to simply use the ns3/foo.h notation
for every public header ? I know that this will trigger much more fallout but
it might be a good change from the point of view of the user, if only because
they won't have to try to understand the difference between #include "foo.h"
and #include "ns3/foo.h".

If we did that, renaming nstime.h to time.h would be the way to go I think.


-- 
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.