bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: getprocname Tru64


From: Bruno Haible
Subject: Re: getprocname Tru64
Date: Tue, 29 Jun 2021 17:04:23 +0200
User-agent: KMail/5.1.3 (Linux/4.4.0-210-generic; KDE/5.18.0; x86_64; ; )

Jay K wrote:
> I see I lost the race here, but here is my rendition of getprogname for 
> Tru64, much more efficient.
> 
> > diff -c getprogname.c.orig getprogname.c
> *** getprogname.c.orig  Tue Jun 29 03:46:44 2021
> --- getprogname.c       Tue Jun 29 03:48:55 2021
> ***************
> *** 283,288 ****
> --- 283,291 ----
>         close (fd);
>       }
>     return "?";
> + # elif defined __osf__
> +   extern char** __Argv;
> +   return last_component (__Argv[0]);
>   # else

But it seems that the use '__Argv' can cause link-time errors on Tru64. [1]

> I came to this by:
> 1: Looked in old gcc to find:
> #define MD_STARTFILE_PREFIX "/usr/lib/cmplrs/cc/"
> 
> 2: grep/nm/dis there.
> 
> I had hoped to step through the startup but haven't learned this dbx yet.

In other words, it's undocumented. In Gnulib, we avoid to rely on
undocumented stuff when possible. In some cases it is unavoidable,
but here we already have an implementation of getprogname() for
OSF/1.

> There is also maybe "auxv" stuff.

That's not good. The result would not only depend on which executable
is running, but on how it was invoked (shell, emulator, valgrind, etc.).

> I find the proc file system kinda gross and inefficient but yeah.

If it's inefficient, you can add caching via a 'static' variable.
Like we already do in the implementations for AIX and HP-UX.

Bruno

[1] https://stat.ethz.ch/pipermail/r-help//2004-January/044699.html




reply via email to

[Prev in Thread] Current Thread [Next in Thread]