Re: C String Prefix Operator Idea (Was: gfortran diagnostics and so on)

Craig Dedo wrote:

"James Van Buskirk" <not_valid@xxxxxxxxxxx> wrote in message news:Dq2dnca0_tpIQNranZ2dnUVZ_jKdnZ2d@xxxxxxxxxxxxxx

"Craig Dedo" <cdedo@xxxxxxxxx> wrote in message news:47472586$0$4966$4c368faf@xxxxxxxxxxxxxxxxx

In addition to the other advantages that you list, anyone can implement this idea right now. There is no need to wait for a compiler vendor to provide the functionality. Just write the function to implement the C language substitution rules and then use the defined-operator feature. Of course, it would be a user-defined operator rather than an intrinsic operator, but that should not be much of an inconvenience; defined unary operators have the highest precedence anyway (Fortran 2003, 7.3, Table 7.7).


Someone should implement this and then post it in this newsgroup. Perhaps I could do it, time permitting.


Well, not quite. Having high priority is normally undesirable I
think, but of course we could always use parentheses. Let's see...


Thanks for pointing out the complications, but I believe that all or nearly all of them are already covered by the C 99 Standard, ISO/IEC 9899:1999, especially section 6.4.4.4.

we have to change '\a' to achar(7), '\b' to achar(8), '\f' to achar(12),
'\n' to achar(10), '\r' to achar(13), '\t' to achar(9), '\v' to achar(11),
"\'" to achar(39), '\"' to achar(34), '\\' to achar(92), '\?' to achar(63)
and all that, but also '\1' to achar(1), '\12' to achar(10) and
'\123' to achar(83). Also, achar(92)//achar(10) translates to ''.


All of these are covered by C99, 6.4.4.4.

Microsoft says that '\c' should translate to 'c' but gfortran would
translate it to '\c'.
http://msdn2.microsoft.com/en-us/library/h21280bw(VS.80).aspx


This behavior is Microsoft specific and is labelled as such on the web page you reference. It is most definitely non-standard. See C99, 6.4.4.4, par. 8 and note 64. In fact, note 64 requires an error condition if there is any escape sequence that is not covered by any of the specifically authorized translations.

Translate '\x12' obviously to achar(18), but does that mean
'\x1' becomes achar(1)? How about '\x123' or '\x'? These seem
to not be unambiguously defined.


These are covered by C99, 6.4.4.4, especially par. 1, 5, 6, 7, and 9.

A problem with a user-defined function is the translation of
'\"' and "\'". These can't both be trapped in the same string
without compiler assistance. In a C program most of the
escape sequences are '\n' which is irrelevant in record-oriented
Fortran I/O. Also, do you want to trim the output of the
function to take into account the string contraction? Easily
done with a specification function, but it would stop the
function from being elemental.


I had not thought about the elemental issue before, but making it elemental seems reasonable. It would add useful functionality at next to no cost. Blank padding at the end is not a big deal in Fortran.

Do you want to append the
achar(0) at the end as well? Probably not, because I don't
think existing implementations do so.


I was not planning to add a null character at the end. FWIW, the CVF extension does add a null character at the end, according to the documentation. I have not looked at such strings in the debugger, but, in my experience, DEC, CVF, HP, and Intel documentation is highly accurate.

Even C compilers implement these escape sequences differently.
Therefore anyone who uses them in C has to be ready to change
his escape sequences around as the program is ported to different
compilers. Changing them to invocations of ACHAR is then just
as normal as would be the case in changing C compilers.


If I did it, I would follow the C99 standard rigorously and not worry about compiler-specific deviations from C99. That is the only way to keep the implementation effort to a reasonable amount.

None of these proposals seem to address a generic substitution capability. That's far more broadly useful than simple escape sequences.

--

Gary Scott
mailto:garylscott@sbcglobal dot net

Fortran Library: http://www.fortranlib.com

Support the Original G95 Project: http://www.g95.org
-OR-
Support the GNU GFortran Project: http://gcc.gnu.org/fortran/index.html

If you want to do the impossible, don't hire an expert because he knows it can't be done.

-- Henry Ford
.

Relevant Pages