From: John Baldwin <jhb@FreeBSD.org>
To: Simon Marchi <simon.marchi@polymtl.ca>, Nick Clifton <nickc@redhat.com>
Cc: "Павел Крюков" <kryukov@frtk.ru>,
gdb-patches@sourceware.org, binutils@sourceware.org
Subject: Re: [PATCH] Include <string.h> to dis-asm.h to get strchr declaration
Date: Tue, 15 Jan 2019 17:50:00 -0000 [thread overview]
Message-ID: <3d320117-db92-d62a-5db1-a794427343d7@FreeBSD.org> (raw)
In-Reply-To: <9494a3a3f1a68aeeadf94fb70632e143@polymtl.ca>
On 1/15/19 6:14 AM, Simon Marchi wrote:
> On 2019-01-15 09:01, Nick Clifton wrote:
>> Hi Simon,
>>
>>>> Include <string.h> to dis-asm.h to get strchr declaration
>>
>>>> Â #include <stdio.h>
>>>> +#include <string.h>
>>>> Â #include "bfd.h"
>>
>>> I took the liberty of pushing this patch which touches code in
>>> include/, since it seemed obvious enough to me.
>>
>> Do we need to worry about systems that have <strings.h> rather than
>> <string.h> ?
>>
>> There are various places in the binutils sources (eg binutils/sysdep.h)
>> which
>> check for configure macros for these headers, which makes me wonder...
>
> From what I understand, these systems (BSDs, mostly) have strings.h in
> addition to string.h, where strings.h provide additional, non-standard
> functions. But strchr would still be found in string.h.
Yes, that is true on both FreeBSD and OS X at least (both of which have
<strings.h>). On those, <strings.h> defines prototypes for things like
bzero() and bcmp().
--
John Baldwin
                                                                           Â
prev parent reply other threads:[~2019-01-15 17:50 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-11 9:47 Павел Крюков
2019-01-14 21:45 ` Simon Marchi
[not found] ` <ba2125e4-19e6-9a94-e6c4-4d7472c91121@redhat.com>
2019-01-15 14:14 ` Simon Marchi
2019-01-15 17:50 ` John Baldwin [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3d320117-db92-d62a-5db1-a794427343d7@FreeBSD.org \
--to=jhb@freebsd.org \
--cc=binutils@sourceware.org \
--cc=gdb-patches@sourceware.org \
--cc=kryukov@frtk.ru \
--cc=nickc@redhat.com \
--cc=simon.marchi@polymtl.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox