Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Jan Kratochvil <jan.kratochvil@redhat.com>
To: Pedro Alves <palves@redhat.com>
Cc: gdb-patches@sourceware.org, Aleksandar Ristovski <ARistovski@qnx.com>
Subject: Re: [patchv3 1/8] Move utility functions to common/
Date: Fri, 28 Feb 2014 21:34:00 -0000	[thread overview]
Message-ID: <20140228213305.GA2466@host2.jankratochvil.net> (raw)
In-Reply-To: <5310FB60.9030105@redhat.com>

On Fri, 28 Feb 2014 22:10:56 +0100, Pedro Alves wrote:
> There are gdb ports out there with TARGET_CHAR_BIT != 8.

OK.  They do not have to be C90/C99/POSIX.


> We don't have any in the tree currently, but I believe most of the code we
> have actually works.  I wouldn't have a problem with accepting such a port.

The problem is you have not accepted such a port.  And there is (probably
unwritten) rule that any GDB code not required by current codebase can be
removed.  With a versioning system any code can be easily returned back later.


> > already C90 defines CHAR_BIT as constant 8.
> 
> Sorry, but that's not true.  I'm looking at N1256 (C99/TC3 draft),
> and in 5.2.4.2.1, it shows:
> 
>   #define CHAR_BIT 8
> 
> _but_, it also says just above:
> 
>  "The minimum magnitudes shown shall be replaced by implementation-defined
>   magnitudes with the same sign."
> 
> So that means it must be _at least_ 8-bit, but it also be wider than 8.

It may be true but I am not completely sure with it.  The whole paragraph is:

	Moreover, except for CHAR_BIT and MB_LEN_MAX, the following shall be
	replaced by expressions that have the same type as would an expression
	that is an object of the corresponding type converted according to the
	integer promotions. Their implementation-defined values shall be equal
	or greater in magnitude (absolute value) to those shown, with the same
	sign.

Whether "except for CHAR_BIT and MB_LEN_MAX" applies only to the first
sentence or even to the last sentence is not clear to me, although it may be
more like you say.


> I could see deleting HOST_CHAR_BIT, that's a different story.

OK.


> host-defs.h
> already exists, and this being macro representing a fundamental
> characteristic of the host, it just feels better than a header
> for common string utilities and such.

OK, moved it to common/host-defs.h when that file already exists.


Thanks,
Jan


      reply	other threads:[~2014-02-28 21:34 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-27 21:32 Jan Kratochvil
2014-02-28 12:06 ` Pedro Alves
2014-02-28 20:11   ` Jan Kratochvil
2014-02-28 21:11     ` Pedro Alves
2014-02-28 21:34       ` Jan Kratochvil [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=20140228213305.GA2466@host2.jankratochvil.net \
    --to=jan.kratochvil@redhat.com \
    --cc=ARistovski@qnx.com \
    --cc=gdb-patches@sourceware.org \
    --cc=palves@redhat.com \
    /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