Stephen M. Kenton asked:
> Should specifiying newlib in the absence of the newlib source continue
> to be treated as meaning "force inhibit_libc" in some cases, or should
> inhibit_libc just be exposed if that is desirable?
FWIW, crosstool.sh has this little snippet in it:
# Building the boot
Snapshot gcc-4.3-20071012 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20071012/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.3 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk
Ross Ridge writes:
The entire parsing of the format string is affected by the multi-byte
> character encoding. I don't know how GCC would be able tell that a byte
> with the same value as '%' in the middle of string would actually be
> interpreted as '%' character rather than a part of an extende
[EMAIL PROTECTED] (Ross Ridge) writes:
> I don't think that's true, but regardless many systems have runtime
> character sets that are dependent on locale. If GCC doesn't support this,
> then GCC is broken.
Geoffrey Keating writes:
> I don't think it's unreasonable to insist that you tell the com
On Thu, Oct 11, 2007 at 07:57:57PM -0400, [EMAIL PROTECTED] wrote:
> Heikki Linnakangas writes:
> >The only features in the printf-family of functions that depends on the
> >locale are the conversion with thousand grouping ("%'d"), and glibc
> >extension of using locale's alternative output digits
[EMAIL PROTECTED] (Ross Ridge) writes:
> Ross Ridge writes:
> >The compiler can't in general know what encoding that printf, fprintf,
> >and sprintf will use to parse the string. It's locale dependent.
>
> Paolo Bonzini writes:
> >It is undefined what happens if you run a program in a different
Ross Ridge wrote:
>The compiler can't in general know what encoding that printf, fprintf,
>and sprintf will use to parse the string. It's locale dependent.
Bernd Schmidt writes:
>Does this mean it can vary from one run of the program to another?
Yes, that's the whole point having locales. So a
Ross Ridge wrote:
> The compiler can't in general know what encoding that printf, fprintf,
> and sprintf will use to parse the string. It's locale dependent.
Does this mean it can vary from one run of the program to another? I'll
admit I don't understand locales very well, but doesn't this sound
Ross Ridge writes:
>The compiler can't in general know what encoding that printf, fprintf,
>and sprintf will use to parse the string. It's locale dependent.
Paolo Bonzini writes:
>It is undefined what happens if you run a program in a different charset
>than in the one you specified for -fexec-ch
Andreas Schwab writes:
The compiler is supposed to know the encoding of the strings.
The compiler can't in general know what encoding that printf, fprintf,
and sprintf will use to parse the string. It's locale dependent.
It is undefined what happens if you run a program in a different char
[EMAIL PROTECTED] (Ross Ridge) writes:
> The entire parsing of the format string is affected by the multi-byte
> character encoding. I don't know how GCC would be able tell that a byte
> with the same value as '%' in the middle of string would actually be
> interpreted as '%' character rather than
Andreas Schwab wrote:
[EMAIL PROTECTED] (Ross Ridge) writes:
The entire parsing of the format string is affected by the multi-byte
character encoding. I don't know how GCC would be able tell that a byte
with the same value as '%' in the middle of string would actually be
interpreted as '%' cha
[EMAIL PROTECTED] (Ross Ridge) writes:
> The entire parsing of the format string is affected by the multi-byte
> character encoding. I don't know how GCC would be able tell that a byte
> with the same value as '%' in the middle of string would actually be
> interpreted as '%' character rather tha
13 matches
Mail list logo
