On Mon, May 7, 2018 at 5:09 PM, Chris Johns <chr...@rtems.org> wrote:
> On 08/05/2018 07:32, Joel Sherrill wrote: > > On Mon, May 7, 2018 at 3:58 PM, Chris Johns <chr...@rtems.org > > <mailto:chr...@rtems.org>> wrote: > > > > On 08/05/2018 03:56, Joel Sherrill wrote: > > > > > > I have attached a workaround. > > > > Looks like a solution to me. > > > > > > Good enough for now. All basename() calls should come from rld. > > > > Eventually all dirname() calls should also. > > > > Luckily no file uses both so we don't have to include libgen.h when > > for dirname() and screw up basename(). > > Works on FreeBSD ;) > > > > It seems that libgen.h has this: > > > > > > ======================================================== > > > /* Return final component of PATH. > > > > > > This is the weird XPG version of this function. It sometimes > will > > > modify its argument. Therefore we normally use the GNU version > (in > > > <string.h>) and only if this header is included make the XPG > > > version available under the real name. */ > > > extern char *__xpg_basename (char *__path) __THROW; > > > #define basename __xpg_basename > > > ======================================================== > > > > > > > Oh yuck, who would ever work in standards. ;) > > > > Is this function allowed to be redefined as a macro? > > > > > > http://pubs.opengroup.org/onlinepubs/9699919799/functions/basename.html > > http://pubs.opengroup.org/onlinepubs/9699919799/functions/dirname.html > > > > Neither seems to say anything about that. Both have language like this: > > > > " The /dirname/() function may modify the string pointed to by /path/, > and may > > return a pointer to static storage that may then be overwritten by a > subsequent > > call to /dirname/()." > > > > It really would be better to have our own implementations and not > > use the standard basename() and dirname(). The POSIX ones > > are not thread-safe. > > We have them in rld-path. It is a little like the python os.path module. > > > > > > Chris has used basename as a method name and even though that > should > > > be perfectly acceptable, the macro above gets expanded, the name > > > gets changed (in some places) to rld::path::__xpg_basename() > > > > > > r.lowSourceLine = rld::path::basename (location); > > > > > > IMO the fix is to add dirname to rld-files, use rld basename and > dirname > > > exclusively, and avoid libgen.h at all costs. > > > > Wouldn't the world be so much simpler if there was only Linux? ;) > > > > > > The methods as defined by POSIX aren't thread-safe and can > > modify the caller's string. Suck by design. :) > > > > Having one mono-culture is easy but it doesn't make it right > > even when conformant. :) > > It is a horrible implementation and not safe in C++. > Not safe in C. Just not safe. > > > > > > I didn't do that much work. I got lucky in a couple of files by > removing the > > > include of libgen.h since it wasn't needed but I had to leave it > in one place. > > > > > > $ grep dirname *.cc > > > GcovData.cc: dirname( path ); > > > > > > Hopefully this lets you all proceed with Chris' patches and my > slight hack > > > in place. > > > > > > Ultimate solution is probably simple. We just need to hear from > Chris. > > > > This is fine. I am slowing move covoar to use more and more of the > rtemstoolkit. > > > > I will merge these changes into a v2 patch set. > > > > > > Are you adding dirname()? Or does that need a ticket? > > > > Confused.... > > https://git.rtems.org/rtems-tools/tree/rtemstoolkit/rld-path.h#n52 I missed that somehow. There was one call in covoar to the OS method. Just replace it and remove the libgen.h reference. Easy. :) --joel > > > ? > > Chris >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel