Prev: USB stick rescue (no MBR no Partition) "Code 10"
Next: a.out and ELF file formats
From: Mark Hobley on 28 Feb 2010 06:08
In comp.unix.programmer Ian Collins <ian-news(a)hotmail.com> wrote:
> 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.

--
Mark Hobley
Linux User: #370818 http://markhobley.yi.org/

From: Mark Hobley on 28 Feb 2010 08:08
In comp.unix.programmer santosh <santosh.k83(a)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 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.

Mark.

--
Mark Hobley
Linux User: #370818 http://markhobley.yi.org/

From: Mark Hobley on 28 Feb 2010 11:08
In comp.unix.programmer Moi <root(a)invalid.address.org> wrote:

> 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.

Mark.

--
Mark Hobley
Linux User: #370818 http://markhobley.yi.org/

From: William Ahern on 28 Feb 2010 14:14
In comp.lang.c Mark Hobley <markhobley(a)hotpop.donottypethisbit.com> wrote:
> In comp.unix.programmer santosh <santosh.k83(a)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.
From: Martin Neitzel on 28 Feb 2010 16:54
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>.

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
First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: USB stick rescue (no MBR no Partition) "Code 10"
Next: a.out and ELF file formats