This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug fortran/65125] New: ISO_10646 characters and transfer statement
- From: "zbeekman at gmail dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Thu, 19 Feb 2015 19:30:17 +0000
- Subject: [Bug fortran/65125] New: ISO_10646 characters and transfer statement
- Auto-submitted: auto-generated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65125
Bug ID: 65125
Summary: ISO_10646 characters and transfer statement
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: zbeekman at gmail dot com
Created attachment 34810
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34810&action=edit
reproducer program
I am on OS X Yosemite, 10.10.2 with a 64bit Intel CPU.
Gfortran is version: NU Fortran (Homebrew gcc49 4.9.2_1 --enable-fortran) 4.9.2
I'm trying to make a portable json library that will behave gracefully when
encountering compilers whose ISO_10646 support is lacking. To achieve this, for
certain variables use the character kind defined as:
integer, parameter :: CK =
merge(tsource=selected_char_kind('ISO_10646'),fsource=selected_char_kind('DEFAULT'),mask=selected_char_kind('ISO_10646')
/= -1)
The error handling of the library needs a way to both DEFAULT and ISO_10646
characters, but overloading the error handling routine to have two interfaces
won't work because when ISO_10646 *isn't* supported the two specific routines
will have matching interfaces. As a work around, I would like to print the hex
representation of characters that are `kind=CK` that is possibly ISO_10646 or
DEFAULT. To accomplish this I have written a function `char_to_hex(c)` to try
to print the hex representation of the character. To do this, I am using
`transfer()` to puth the passed in single character into a sufficiently large
integer, and using the `z8.8` edit descriptor to convert to the function result
which is ALWAYS represented in `kind='DEFAULT'` characters (so that I can
safely pass it to the error handling routine).
The problem is that it appears the transfer statement is only writing 2 nibbles
(one byte) to the integer, or the z8.8 is only fetching two nibbles of the
int32 integer. Forexample, the output for a Unicode SNOWFLAKE is 0x000000E2
when it should be: 0x00E29d84. I think the problem is the transfer statement,
since I observe some strange behavior if I modify the char_to_hex() function to
accept len=4 character strings, and adjust the inputs to be the character in
question followed by 4 spaces, and adjust the storage container to int64 and
edit descriptor to z18.18. Now SNOWFLAKE prints out as 0x0x0000009D000000E2:
two most significant nibbles are on the right, then 6 zero nibbles to the left,
the 3rd and 4th most significant nibbles, then more zeroes.
Am I missing something? If not, I think this is a bug.