public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Martin Sebor <msebor@gmail.com>
To: sotrdg sotrdg <euloanty@live.com>,
	"libc-alpha@sourceware.org" <libc-alpha@sourceware.org>
Subject: Re: A question about EBCDIC compiler
Date: Tue, 15 Sep 2020 13:46:32 -0600	[thread overview]
Message-ID: <47cc6408-3057-0315-4da3-ede6d1132c6e@gmail.com> (raw)
In-Reply-To: <CH2PR02MB6522603A0A9868E3644C4142B2230@CH2PR02MB6522.namprd02.prod.outlook.com>

On 9/13/20 10:36 PM, sotrdg sotrdg via Libc-alpha wrote:
> How does the compiler deal with characters with EBCDIC string literals enabled?
> 
> How does glibc deal with EBCDIC compiler?
> For example
> 
> printf(“Hello World: %d\n”,4);
> 
> What encoding would this be on EBCDIC compiler? Will 4  become EBCDIC’s “4” or ASCII’s “4”?

GCC has a number of options that control the character sets it uses.
-finput-charset=<charset> tells it what character set to interpret
the source file in, and -fexec-charset=<charset> what multibyte
character set to use at execution time.

GCC can be configured to compile in an environment with one native
input character set and target an environment with a different set,
so the term "EBCDIC compiler" isn't completely unambiguous.  But
when it refers to a native GCC running on an EBCDIC host and
emitting code for an EBCDIC target there's no translation involved
since both charsets are EBCDIC.  It only becomes interesting when
the host and target charsets differ.

That said, not all parts of GCC honor the options so not everything
works completely seamlessly.  AFAIK, the -Wformat option, is one
that doesn't respect the charset options, so the -Wformat warnings
for printf format strings may not make complete sense (Joseph will
correct me here).  On the other hand, the -Wformat-overflow option
does respect the charset options so it should work correctly (there
are tests that verify it does).

Martin

> 
> How does the filename get dealt with on EBCDIC compilers?
> 
> 
> Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10
> 


  parent reply	other threads:[~2020-09-15 19:46 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-14  4:36 sotrdg sotrdg
2020-09-14  8:54 ` Florian Weimer
2020-09-15 19:46 ` Martin Sebor [this message]
2020-09-15 22:00   ` Joseph Myers

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=47cc6408-3057-0315-4da3-ede6d1132c6e@gmail.com \
    --to=msebor@gmail.com \
    --cc=euloanty@live.com \
    --cc=libc-alpha@sourceware.org \
    /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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).