Another doubleunderscore thingy
Mark Hobley
> Right. That is just as messy as __dead. I think I will just delete the tag.
Right I have found another doubleunderscore thingybob. This time __progname:
void
usage(void)
{
extern char *__progname;
(void)fprintf(stderr, "usage: %s [-itw] file ...\n", __progname);
exit(1);
}
This was easier to find in google than the last one. I stumbled across:
http://stackoverflow.com/questions/273691/using-progname-instead-of-argv0
This tells me that __progname is a bsdism and getopt() modifies argv[],
which is not available outside of main(). I guess that I need to somehow
capture argv[0] on entry to main. I guess that the following is a fixup for
this:
extern char *progname;
int
main(int argc, char *argv[])
{
extern char *progname;
progname=argv[0];
blah blah blah
}
void
usage(void)
{
extern char *progname;
(void)fprintf(stderr, "usage: %s [-itw] file ...\n", progname);
exit(1);
}
Does that look right?
Mark.
--
Mark Hobley
Linux User: #370818 http://markhobley.yi.org/
Mark Hobley
> extern char *progname;
Hmmm. It's not external now though. I changed this to:
char *progname;
When I compile, I get an error:
getname.c: In function 'main':
getname.c:96: error: 'optind' undeclared (first use in this function)
getname.c:96: error: (Each undeclared identifier is reported only once
getname.c:96: error: for each function it appears in.)
That error looks right to me: 'optind' is undeclared. I wonder if this is an
error in the original bsd code, or whether optind becomes defined in the
bsd versions of the header files, or the optind becomes defined when the bsd
compiler is used.
The headers are:
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <libgen.h>
The specification says:
SYNOPSIS
#include <unistd.h>
int getopt(int argc, char * const argv[], const char *optstring);
extern char *optarg;
extern int optind, opterr, optopt;
Maybe optind is defined in unistd.h
I added the declaration to the top of the file, and now I get an error:
getname.c:(.text+0x304): undefined reference to `strlcat'
There is a string.h file, so I don't know what is going on there.
Ian Collins
> In comp.os.linux.development.apps Mark Hobley <markh...@hotpop.donottypethisbit.com> wrote:
>
>> extern char *progname;
>
> Hmmm. It's not external now though. I changed this to:
>
> char *progname;
>
> When I compile, I get an error:
>
> getname.c: In function 'main':
> getname.c:96: error: 'optind' undeclared (first use in this function)
Then you haven't included the header where it is declared.
> getname.c:96: error: (Each undeclared identifier is reported only once
> getname.c:96: error: for each function it appears in.)
>
> That error looks right to me: 'optind' is undeclared. I wonder if this is an
> error in the original bsd code, or whether optind becomes defined in the
> bsd versions of the header files, or the optind becomes defined when the bsd
> compiler is used.
>
> The headers are:
>
> #include <stdio.h>
> #include <stdlib.h>
> #include <string.h>
> #include <libgen.h>
Well given the synopsis below, you are missing <unistd.h>.
> The specification says:
>
> SYNOPSIS
>
> #include <unistd.h>
>
> int getopt(int argc, char * const argv[], const char *optstring);
> extern char *optarg;
> extern int optind, opterr, optopt;
>
> Maybe optind is defined in unistd.h
No, it may be declared there, but it will be defined in a library source
file.
> I added the declaration to the top of the file, and now I get an error:
>
> getname.c:(.text+0x304): undefined reference to `strlcat'
>
> There is a string.h file, so I don't know what is going on there.
It will probably be declared in <strings.h>, see the man page.
--
Ian Collins
Seebs
>(someone else)
>> getname.c:(.text+0x304): undefined reference to `strlcat'
>> There is a string.h file, so I don't know what is going on there.
> It will probably be declared in <strings.h>, see the man page.
More likely, it was in <string.h> on the system the OP was porting from,
but isn't in it on most other systems, since it's a BSD extension.
(strlcat/strlcpy are what strncat/strncpy probably should have been).
-s
--
Copyright 2010, all wrongs reversed. Peter Seebach / usenet...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
Mark Hobley
> More likely, it was in <string.h> on the system the OP was porting from,
> but isn't in it on most other systems, since it's a BSD extension.
> (strlcat/strlcpy are what strncat/strncpy probably should have been).
Right that is interesting. I am reading the manual pages online, and I have
found something very odd:
The man page for string(3)
http://linux.die.net/man/3/string
(This does not mention strlcat)
From the same website, a man page for strlcat:
http://linux.die.net/man/3/strlcat
Strangely, there is a string.h and a strings.h
I tried included both:
#include <string.h>
#include <strings.h>
That didn't fix it. Maybe it is in unistd.h:
#include <unistd.h>
Nope. That didn't fix it either.
I think you are right. Maybe this is a BSD extension and I am reading the wrong
documents.
santosh
It does seem to be a BSD specific function, along with strlcpy().
<http://en.wikipedia.org/wiki/Strlcpy>
<http://www.openbsd.org/cgi-
bin/cvsweb/~checkout~/src/lib/libc/string/strlcat.c?rev=1.13>
<http://www.openbsd.org/cgi-bin/man.cgi?query=strlcpy&sektion=3>
Since the source is available, and it's easy to implement your own as
well, with the same semantics, it's not a big portability problem,
AFAICS.
Mark Hobley
> Then you haven't included the header where it is declared.
Yeah. That is weird, because there were no additional #include statements in
the original bsd code. This must be an implementation difference.
Mark Hobley
> Since the source is available, and it's easy to implement your own as
> well, with the same semantics, it's not a big portability problem,
> AFAICS.
Yeah. I am just deciding how to do that now. I have stumbled across a library
called libnostd that contains an implementation of this. I could use that
library. I am a bit concerned about the transparency issue of that though,
because it still uses string.h and this means that code using string.h
but using strlcat will work directly on some systems, but not on other
systems where strlcat is not implement (so much for standard C libraries huh!).
I am thinking it might be better to create a new header bsdlib.h containing
the additional functionality, and using that. However, this may then create
another problem in that I need to provide fixups so that code including
bsdlib.h and string.h on a host that includes strlcat in the string.h header
does not create a conflicting definition. Also, what do I do about alternative
implementations of strlcat, which zero the last byte of the buffer? Do I just
drop support for those platforms, or do I create a new function name with
equal functionality to avoid ambiguity? What a mess!
The other thing is, I have some fixups to make to glibc anyway to make it
portable across IA32 compatible machines (Currently it contains embedded
invalid instructions which do not work on traditional Pentiums, the Cyrix 686,
and the AMD K5 and AMD K6, and can cause a crash when the libraries are
transferred between machines containing these processors.) I could just fork
the library, apply the strlcat to the forked library and be done.
Moi
> In comp.unix.programmer santosh <santo...@gmail.com> wrote:
>> Since the source is available, and it's easy to implement your own as
>> well, with the same semantics, it's not a big portability problem,
>> AFAICS.
>
> Yeah. I am just deciding how to do that now. I have stumbled across a
> library called libnostd that contains an implementation of this. I could
> use that library. I am a bit concerned about the transparency issue of
> that though, because it still uses string.h and this means that code
> using string.h but using strlcat will work directly on some systems, but
> not on other systems where strlcat is not implement (so much for
> standard C libraries huh!).
The strlxxx() and strpxxx() families of functions are extensions to
the stdlibrary. If you can live with polluting the library, it is
easiest to just add them to libc. Otherwise, you'll have to put them
in a separate library, obviously.
(IMHO: the and str[lp]xxx() are a very useful extention; I never
use the return values (the first argument, which the caller already has)
from strcpy() and memcpy().
>
> I am thinking it might be better to create a new header bsdlib.h
> containing the additional functionality, and using that. However, this
> may then create another problem in that I need to provide fixups so that
> code including bsdlib.h and string.h on a host that includes strlcat in
> the string.h header does not create a conflicting definition. Also, what
> do I do about alternative implementations of strlcat, which zero the
> last byte of the buffer? Do I just drop support for those platforms, or
> do I create a new function name with equal functionality to avoid
> ambiguity? What a mess!
The clean way is to provide your own versions, and possibly
#define strlcpy mystrlcpy
, etc.
>
> The other thing is, I have some fixups to make to glibc anyway to make
> it portable across IA32 compatible machines (Currently it contains
> embedded invalid instructions which do not work on traditional Pentiums,
> the Cyrix 686, and the AMD K5 and AMD K6, and can cause a crash when the
> libraries are transferred between machines containing these processors.)
Well, this is what open source is all about. Why distribute binaries
if you can compile on (for) the target platform ?
Why would you distribute glibc anyway ? You expect target platforms without
a usable glibc ? Why not have the users install it themselves ?
(or let the package manager handle it)
HTH,
AvK
Mark Hobley
> Well, this is what open source is all about. Why distribute binaries
> if you can compile on (for) the target platform ?
The core system will be installable from a cdrom, and the rest of the binary
files will be shared via the network. All machines are IA32 compatible, so as
long as I can build to this the binaries will be portable.
Mark.
> Why would you distribute glibc anyway ? You expect target platforms without
> a usable glibc ?
I was hoping that my source packages would be usable within other
distributions irrespective of which C library was being used. This enables me
to bootstrap. I need to have the code working on an existing system, before I
can deploy a revised system.
This would also mean that third parties can use my packages without having to
install my version of the C library.
William Ahern
> In comp.unix.programmer santosh <santo...@gmail.com> wrote:
> > Since the source is available, and it's easy to implement your own as
> > well, with the same semantics, it's not a big portability problem,
> > AFAICS.
> Yeah. I am just deciding how to do that now. I have stumbled across a library
> called libnostd that contains an implementation of this. I could use that
> library. I am a bit concerned about the transparency issue of that though,
> because it still uses string.h and this means that code using string.h
> but using strlcat will work directly on some systems, but not on other
> systems where strlcat is not implement (so much for standard C libraries huh!).
I think you're a bit confused about what libnostd* does.
libnostd provides static inline versions of strlcpy, strlcat, and many other
routines. By adding "[path to libnostd]/bsd", a supported compiler (gcc,
msc, several others) will pick up the included "string.h" automatically.
bsd/string.h will include the system's string.h. Then bsd/string.h will
define routines such as strlcat() if it doesn't believe that they're already
declared (and thus available in libc).
Everything is defined static inline**, so there's no linking dependency
whatsoever. Once your code is compiled, that's the end of it.
libnostd is intended to be totally transparent. By simply adding bsd/ to
your include path, you should be able to safely use strlcat() everywhere w/o
worrying about it, and w/o having to modify any of the application code.
The way I use libnostd is to simply include it at the top-level of my
projects as a compat/ directory.
foo/
compat/
src/
The Makefile in src/ simply does
CPPFLAGS=-I../compat -I../compat/bsd
That's the end of it. In your source you include <string.h> confident that
strlcat() will be provided one way or another. Similarly, if you
`-I../compat/gnu' you can be confident that strnlen() is available.
<snip>
> does not create a conflicting definition. Also, what do I do about alternative
> implementations of strlcat, which zero the last byte of the buffer? Do I just
> drop support for those platforms, or do I create a new function name with
> equal functionality to avoid ambiguity? What a mess!
You can do what libnostd does: declare/define your version as xstrlcpy(),
and then `#define strlcpy(a, b, c) xstrlcpy((a), (b), (c))'.
* I'm the author of libnostd. It's not a particularly ambitious library.
I've never tested it on HP-UX or AIX. It works on the platforms I work with:
Linux, OS X, OpenBSD, Win32. I occassionally get patches for FreeBSD. But
the strlcpy() and strlcat() support should be near universal (assuming the
compiler supports interposing string.h), because even if it guesses wrong it
simply diverts usage to the inline definition; no harm no foul.
** Everything is static inline (including arc4random), except for
the recent setproctitle implementation. libnostd doesn't install anything,
and there's no independent build step. It's just meant to take the hassle
out of these minor portability issues.
William Ahern
> > Right. That is just as messy as __dead. I think I will just delete the tag.
> Right I have found another doubleunderscore thingybob. This time __progname:
> void
> usage(void)
> {
> extern char *__progname;
> (void)fprintf(stderr, "usage: %s [-itw] file ...\n", __progname);
> exit(1);
> }
> This was easier to find in google than the last one. I stumbled across:
> http://stackoverflow.com/questions/273691/using-progname-instead-of-argv0
If you're only porting to Linux you can either use the getprogname()
implemented in libnostd, or just read over the code in
bsd/stdlib/getprogname.h.
For Linux (or rather glibc and compatible libraries) the simple substitute
is `extern char *program_invocation_short_name'.
Martin Neitzel
> Strangely, there is a string.h and a strings.h
Historically (in the eighties), BSD systems had the declarations
for string functions such as strcpy() in <strings.h> whereas SystemV
systems had them in <string.h>. There were some differences in
return types (int vs. char*) and naming (index() vs. strchr()).
These differences were always a portability nuisance. Later,
ANSI C (1989) came and also defined the standard library.
This made <string.h> the norm. In today's systems, you'll
often find a <strings.h> which just #includes <string.h>.
If you're porting some code to a new system: first look which
routine is requiring a prototype declaration; then look up its man
page which will indicate the required header file. Use that one.
If you get type warnings when you compile the code, fix the code.
Martin Neitzel
Ersek, Laszlo
> Mark Hobley wrote:
>> Strangely, there is a string.h and a strings.h
>
> Historically (in the eighties), BSD systems had the declarations
> for string functions such as strcpy() in <strings.h> whereas SystemV
> systems had them in <string.h>. There were some differences in
> return types (int vs. char*) and naming (index() vs. strchr()).
>
> These differences were always a portability nuisance. Later,
> ANSI C (1989) came and also defined the standard library.
> This made <string.h> the norm. In today's systems, you'll
> often find a <strings.h> which just #includes <string.h>.
SUSv3 (POSIX:2004) and SUSv4 (POSIX:2008) have a <strings.h> which is
not an empty shell:
http://www.opengroup.org/onlinepubs/000095399/basedefs/strings.h.html
http://www.opengroup.org/onlinepubs/9699919799/basedefs/strings.h.html
Cheers,
lacos