This is the mail archive of the fortran@gcc.gnu.org mailing list for the GNU Fortran project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Length of the ERRMSG result


Hi Francisco,

Francisco Pena wrote:
> Thank you again for your answer. Let's see if somebody can clarify
> whether the maximum size of the ERRMSG result depends on the compiler
> or the OS.

In general, on both. However, I think currently you get for all errmsg
a compiler (or: coarray-runtime specific) error message and no error
message from the operating system. (Contrary to the stat value which for
some procdures/statements passes the errno value through, e.g. for I/O
issues.)


As you asked about ALLOCATE: In that case, stat does not match the errno
and gfortran currently uses the following hard-coded strings
  "Attempting to allocate already allocated variable '%s'"
  "Allocation would exceed memory limit"

As the %s indicates, it the length also depends on the variable name.

Additionally, the string is marked as translatable, i.e. if you *compile*
with a locale set, you will get localized strings, e.g. for en_ES.UTF-8:
  Se intentó alojar la variable ya alojada '%s'
  La asignación excedería el límite de memoria

[I regard this compile-time dependence on the locale as bug, but one can also
see it as feature. If the text looks mangled, either my mailer or your mailer
has mangled the UTF-8 characters. If you have that locale but get an English
string, your GCC has been built without locale support.]

In principle, the "errno" variable could be evaluated for allocate ("malloc"),
but I doubt that the errno would be anything but ENOMEM. gfortran does ignore
the errno value.

Tobias


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]