Re: Length of the ERRMSG result

[Francisco Pena <fran dot pena at usc dot es>]

Thank you Tobias,

I believe your answer solved this thread.

Best,
Fran

2014-10-01 15:27 GMT+02:00 Tobias Burnus <tobias.burnus@physik.fu-berlin.de>:
> 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



-- 

Francisco Josà Pena Brage
Departamento de MatemÃtica Aplicada
Facultade de MatemÃticas. Campus Vida
15782 Santiago de Compostela - Spain
Tel.: +34 8818 13194
Fax: +34 8818 13197
Email: fran(dot)pena(at)usc(dot)es
http://www.usc.es/ingmat