Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 23 Aug 2011 08:17:44 -0400
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: Is "memory.h" wanted?

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

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.