Is "memory.h" wanted?

Is "memory.h" wanted?

[Isaac Dunham]

I recently tried building OpenSSL, and it failed to build due to a missing "memory.h".
At the time, I just sidelined the project.

Since then, I have looked at the glibc version; it amounts to 
#include <features.h>
#include <string.h>

Which, IIRC, means a BSD-flavored/other legacy string.h
Is this header desired for compatability, or should code using it be considered 
non-conformant and patched?

Also, have any SSL libraries (besides openssh internal) have been verified to work with musl?
-- 
Isaac Dunham <idunham@lavabit.com>

Re: Is "memory.h" wanted?

[Rich Felker]

On Mon, Aug 22, 2011 at 06:37:10PM -0700, Isaac Dunham wrote:
> I recently tried building OpenSSL, and it failed to build due to a
> missing "memory.h".
> At the time, I just sidelined the project.
> 
> Since then, I have looked at the glibc version; it amounts to 
> #include <features.h>
> #include <string.h>
> 
> Which, IIRC, means a BSD-flavored/other legacy string.h
> Is this header desired for compatability, or should code using it be considered 
> non-conformant and patched?

Probably both, i.e. we should add it and OpenSSL should be patched. In
the long term I'm thinking about adding #warning to all of the
nonsensical legacy headers and wrong-location headers (missing sys/-
prefix or incorrect sys/- prefix) to help track down and correct such
errors in programs.

> Also, have any SSL libraries (besides openssh internal) have been
> verified to work with musl?

I have bitlbee and irssi both linked with OpenSSL and haven't had any
problems with them, but I haven't tried all the features that depend
on SSL. I think GNU TLS built correctly too but I gave up on trying to
use it when software kept wanting more and more other libs along with
it - some GPG-internal libs if I remember right...

Rich

Re: Is "memory.h" wanted?

[Isaac Dunham]

On Mon, 22 Aug 2011 21:44:33 -0400
Rich Felker <dalias@aerifal.cx> wrote:

> On Mon, Aug 22, 2011 at 06:37:10PM -0700, Isaac Dunham wrote:
> > I recently tried building OpenSSL, and it failed to build due to a
> > missing "memory.h".
<snip>
> > Which, IIRC, means a BSD-flavored/other legacy string.h
> > Is this header desired for compatability, or should code using it be considered 
> > non-conformant and patched?
> 
> Probably both, i.e. we should add it and OpenSSL should be patched. In
> the long term I'm thinking about adding #warning to all of the
> nonsensical legacy headers and wrong-location headers (missing sys/-
> prefix or incorrect sys/- prefix) to help track down and correct such
> errors in programs.
I had assumed the header wanted was a libc header; however, when I looked up memory.h, 
the recommended header to use was a *private* kernel header (not one of the cleaned headers). There was talk about removing the include from OpenSSL (which certainly should happen, considering the hackishness of this).
IIRC, sys/ is part of the linux-libc headers
> 
> > Also, have any SSL libraries (besides openssh internal) have been
> > verified to work with musl?
> 
> I have bitlbee and irssi both linked with OpenSSL and haven't had any
> problems with them, but I haven't tried all the features that depend
> on SSL. 
Since that means you built openssl, I'll try it again--once I've built a self-hosting system (bootstrap-linux, in this case)

-- 
Isaac Dunham <idunham@lavabit.com>

Re: Is "memory.h" wanted?

[Rich Felker]

On Tue, Aug 23, 2011 at 12:06:37AM -0700, Isaac Dunham wrote:
> On Mon, 22 Aug 2011 21:44:33 -0400
> Rich Felker <dalias@aerifal.cx> wrote:
> 
> > On Mon, Aug 22, 2011 at 06:37:10PM -0700, Isaac Dunham wrote:
> > > I recently tried building OpenSSL, and it failed to build due to a
> > > missing "memory.h".
> <snip>
> > > Which, IIRC, means a BSD-flavored/other legacy string.h
> > > Is this header desired for compatability, or should code using it be considered 
> > > non-conformant and patched?
> > 
> > Probably both, i.e. we should add it and OpenSSL should be patched. In
> > the long term I'm thinking about adding #warning to all of the
> > nonsensical legacy headers and wrong-location headers (missing sys/-
> > prefix or incorrect sys/- prefix) to help track down and correct such
> > errors in programs.
> I had assumed the header wanted was a libc header; however, when I
> looked up memory.h, the recommended header to use was a *private*
> kernel header (not one of the cleaned headers). There was talk about

Where did this information come from? The *only* thing "memory.h" is
for is memcpy, memset, etc. which belong in string.h and have always
been in string.h. The whole "memory.h" thing was some BSD nonsense,
probably because they preferred their bzero, bcopy, etc. interfaces
and were bitter than mem* was adopted by ANSI/ISO C.

Rich

Re: Is "memory.h" wanted?

[Isaac Dunham]

On Tue, 23 Aug 2011 08:17:44 -0400
Rich Felker <dalias@aerifal.cx> wrote:

> On Tue, Aug 23, 2011 at 12:06:37AM -0700, Isaac Dunham wrote:
> > On Mon, 22 Aug 2011 21:44:33 -0400
> > Rich Felker <dalias@aerifal.cx> wrote:
> > 
> > > On Mon, Aug 22, 2011 at 06:37:10PM -0700, Isaac Dunham wrote:
> > > > I recently tried building OpenSSL, and it failed to build due
> > > > to a missing "memory.h".
> > <snip>
> > > > Which, IIRC, means a BSD-flavored/other legacy string.h
> > > > Is this header desired for compatability, or should code using
> > > > it be considered non-conformant and patched?
> > > 
> > > Probably both, i.e. we should add it and OpenSSL should be
> > > patched. In the long term I'm thinking about adding #warning to
> > > all of the nonsensical legacy headers and wrong-location headers
> > > (missing sys/- prefix or incorrect sys/- prefix) to help track
> > > down and correct such errors in programs.
> > I had assumed the header wanted was a libc header; however, when I
> > looked up memory.h, the recommended header to use was a *private*
> > kernel header (not one of the cleaned headers). There was talk about
> 
> Where did this information come from? The *only* thing "memory.h" is
> for is memcpy, memset, etc. which belong in string.h and have always
> been in string.h. The whole "memory.h" thing was some BSD nonsense,
> probably because they preferred their bzero, bcopy, etc. interfaces
> and were bitter than mem* was adopted by ANSI/ISO C.
> 
> Rich
http://www.mail-archive.com/openssl-dev@openssl.org/msg28700.html
I quote:
"memory.h is in the following path: [ I am using Linux debian
2.6.26-2-686 #1 SMP Thu Nov 25 01:53:57 UTC 2010 i686 GNU/Linux ]
                 /usr/src/linux-headers-2.6.26-2-686/include/linux/memory.h
So make sure your path is set properly to include the linux include
files"
I'm not certain if this fellow got things right, though.

Re: Is "memory.h" wanted?

[Szabolcs Nagy]

* Isaac Dunham <idunham@lavabit.com> [2011-08-24 23:37:16 -0700]:
> http://www.mail-archive.com/openssl-dev@openssl.org/msg28700.html
> I quote:
> "memory.h is in the following path: [ I am using Linux debian
> 2.6.26-2-686 #1 SMP Thu Nov 25 01:53:57 UTC 2010 i686 GNU/Linux ]
>                  /usr/src/linux-headers-2.6.26-2-686/include/linux/memory.h
> So make sure your path is set properly to include the linux include
> files"
> I'm not certain if this fellow got things right, though.

he did not

including memory.h is a bug
it's non-standard, useless and hurts everyone everywhere

use string.h instead
find . -name '*.[ch]' -exec sed -i 's/<memory\.h>/<string.h>/' {} \;

Re: Is "memory.h" wanted?

[Rich Felker]

On Wed, Aug 24, 2011 at 11:37:16PM -0700, Isaac Dunham wrote:
> http://www.mail-archive.com/openssl-dev@openssl.org/msg28700.html
> I quote:
> "memory.h is in the following path: [ I am using Linux debian
> 2.6.26-2-686 #1 SMP Thu Nov 25 01:53:57 UTC 2010 i686 GNU/Linux ]
>                  /usr/src/linux-headers-2.6.26-2-686/include/linux/memory.h
> So make sure your path is set properly to include the linux include
> files"
> I'm not certain if this fellow got things right, though.

This is simply nonsense. That would be <linux/memory.h>, not
<memory.h>, and there's certainly no reason openssl or any userspace
software should need to include it.

Rich

Re: Is "memory.h" wanted?

[Szabolcs Nagy]

* Rich Felker <dalias@aerifal.cx> [2011-08-22 21:44:33 -0400]:
> the long term I'm thinking about adding #warning to all of the
> nonsensical legacy headers and wrong-location headers (missing sys/-
> prefix or incorrect sys/- prefix) to help track down and correct such
> errors in programs.

sounds like a good plan

(actually certain function calls would deserve a
compile time warning as well..)