X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f
X-Received: by 10.200.50.105 with SMTP id y38mr8144686qta.67.1484453063865;
        Sat, 14 Jan 2017 20:04:23 -0800 (PST)
X-Received: by 10.157.14.183 with SMTP id 52mr2346658otj.20.1484453063822;
 Sat, 14 Jan 2017 20:04:23 -0800 (PST)
Newsgroups: comp.os.msdos.djgpp
Date: Sat, 14 Jan 2017 20:04:23 -0800 (PST)
In-Reply-To: <CAA2C=vA8sYus1m75UbeBvgJw_QQ-rs=RDc3hmpfSV_+1kYd3ug@mail.gmail.com>
Complaints-To: groups-abuse AT google DOT com
Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=104.55.20.34; posting-account=p5rsXQoAAAB8KPnVlgg9E_vlm2dvVhfO
NNTP-Posting-Host: 104.55.20.34
References: <CAA2C=vAxwXB1-nsiDMmKQLt7rmkFHonK-8Cxqx4M_2uKN7ZzPA AT mail DOT gmail DOT com>
 <83h951c41o DOT fsf AT gnu DOT org> <CAA2C=vAQsONZ-bG1dnoso3RWno6bDWGeDhnMJk33RypA5JjG=A AT mail DOT gmail DOT com>
 <83d1fpc24q DOT fsf AT gnu DOT org> <CAA2C=vA8sYus1m75UbeBvgJw_QQ-rs=RDc3hmpfSV_+1kYd3ug AT mail DOT gmail DOT com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <33cea7c3-811c-4049-9893-ccdf25baac6e@googlegroups.com>
Subject: Re: memory.h
From: "rugxulo AT gmail DOT com [via djgpp AT delorie DOT com]" <djgpp AT delorie DOT com>
Injection-Date: Sun, 15 Jan 2017 04:04:23 +0000
Content-Type: text/plain; charset=UTF-8
Bytes: 3645
Lines: 59
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Reply-To: djgpp AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

Hi,

On Saturday, January 14, 2017 at 6:11:21 AM UTC-6, Ozkan Sezer (sezeroz AT hates DOT spam) [via djgpp AT spam DOT sux] wrote:
> On 1/14/17, Eli Zaretskii (eliz AT nospam DOT no) [via
> djgpp-workers AT ugh DOT spam] <djgpp-workers AT die DOT spam> wrote:
> >> From: "Ozkan Sezer (sezeroz AT spam DOT hater) [via djgpp AT spammers DOT suck]"
> >> <djgpp AT nospam4 DOT u>
> >> Date: Sat, 14 Jan 2017 14:16:05 +0300
>
> > What problems does including stdlib.h cause?
> 
> Problems are not from including stdlib.h but from not including string.h
> E.g. cpu.c from flac library includes memory.h possibly to get the proto
> for memset(). Their decision might be debatable, but that's what they do
> and it works everywhere except for djgpp, for which I suggested a patch
> http://lists.xiph.org/pipermail/flac-dev/2017-January/006109.html

Since it's non-standard, I can only guess where it comes from.
Presumably MSVC still supports it. I somehow doubt Linux included
it for its own sake.

And yet you go on to say this:

> Ozkan Sezer
> Sat Jan 14 23:27:58 UTC 2017
>
> Simpler patch attached, which just replaces memory.h with string.h
> cpu.c was the only source to use memory.h instead of string.h.

So it sounds moot, it's a non-issue.

FYI, I have various C compilers installed here (why? bored).

Omitting the DJGPP ones gives this:

e:\c\CC386\INCLUDE\MEMORY.H
e:\c\orangec.old\INCLUDE\MEMORY.H
e:\c\lsic86\INCLUDE\MEMORY.H
e:\c\watcom19\H\MEMORY.H
e:\c\watcom19\H\MEM.H
e:\c\tc\INCLUDE\MEM.H
e:\c\tcpp\INCLUDE\MEM.H
e:\c\EMX\INCLUDE\MEMORY.H
e:\c\dev86dos\include\memory.h
e:\c\tinyc\include\memory.h
e:\c\tinyc\include\mem.h

cc386/include/memory.h -- mem* prototypes, #include <stddef.h>
orangec.old/include/memory.h -- mem* prototypes, #include <stddef.h>
lsic86/include/memory.h -- one typedef, mem* prototypes
watcom19/h/memory.h -- almost nothing, #include <string.h>
watcom19/h/mem.h -- various typedefs, #include <string.h>
tc/include/mem.h -- (Turbo C 2.01) some typedefs, mem* prototypes
tcpp/include/mem.h -- (Turbo C++ 1.01) some typedefs, mem* prototypes
emx/include/memory.h -- one typedef, mem* prototypes
dev86dos/include/memory.h -- literally just #include <string.h>
tinyc/include/memory.h -- bunch of mem* prototypes
tinyc/include/mem.h -- #include <string.h>

Does that help?