Prev: getting 64-bit fortran to work on a friend's laptop
Next: deferred length character as subroutine argument
From: robin on 16 May 2010 23:04
"Colin Watters" <boss(a)qomputing.com> wrote in message news:hsn0is$vr7$1(a)news.eternal-september.org...

| IIMO the "default" behaviour ought to be kind to the novice user, because an
| experienced user can be expected to know how to change the default settings
| to achieve the behaviour s/he prefers. So what is the "kindest" thing to
| do?
|
| IMO that is to produce a core file of modest size, so it would be useful
| for the typical size of program the novice might be developing, but small
| enough to ensure no risk of disk space trauma. So I think the default core
| size limit should be "modest", say 100KB.

Why would a core dump be required for an ordinary routine end of file?


From: Colin Watters on 17 May 2010 02:43

"robin" <robin51(a)dodo.com.au> wrote in message
news:4bf0b250$0$89665$c30e37c6(a)exi-reader.telstra.net...
> "Colin Watters" <boss(a)qomputing.com> wrote in message
> news:hsn0is$vr7$1(a)news.eternal-september.org...
>
> | IIMO the "default" behaviour ought to be kind to the novice user,
> because an
> | experienced user can be expected to know how to change the default
> settings
> | to achieve the behaviour s/he prefers. So what is the "kindest" thing
> to
> | do?
> |
> | IMO that is to produce a core file of modest size, so it would be
> useful
> | for the typical size of program the novice might be developing, but
> small
> | enough to ensure no risk of disk space trauma. So I think the default
> core
> | size limit should be "modest", say 100KB.
>
> Why would a core dump be required for an ordinary routine end of file?
>
>
None that I can think of. That's the default behaviour of the OS in the
situation the program finds itself, as RC explained in his original post.
If you are saying that something more "helpful" should occur instead, then
I agree.

--
Qolin

Email: my qname at domain dot com
Domain: qomputing


From: robert.corbett on 18 May 2010 00:43
On May 15, 12:41 pm, Louis Krupp <lkrupp_nos...(a)indra.com.invalid>
wrote:
> On 5/15/2010 4:03 AM, robert.corb...(a)oracle.com wrote:
>
>
>
> > On May 14, 8:36 pm, nos...(a)see.signature (Richard Maine) wrote:
> >> <robert.corb...(a)oracle.com> wrote:
> >>> I recently received a request from a user asking that abort not be
> >>> called for an end-of-file condition. He made the point that on
> >>> modern machines core files are often gigabytes long and take
> >>> some minutes to write.
> >> ...
> >>> I would like to know what others think of this request. Also, should
> >>> abort be called for the end-of-record condition and i/o error
> >>> conditions?
>
> >> I don't see why the size of a core file has anything in particular to do
> >> with end-of-file (or other i/o conditions). It seems to me that this is
> >> a much more general issue unrelated to the i/o conditions. If the user
> >> doesn't want core files because of their size or for any other reason, I
> >> can see that. What I don't see is singling out the i/o conditions for
> >> special attention. Sounds to me like a user focusing on what happened to
> >> him on a particular day instead of looking at a larger and more
> >> consistent picture. Is this same user going to soon turn around and ask
> >> for core files to not be produced for the next particular kind of error
> >> he happens to run into? Much better to show him how to avoid core files
> >> in general than to hack things one at a time for each class of error
> >> that he hits.
>
> >> In addition to setting the core size limit as you mentioned, it isn't
> >> exactly complicated or obscure for the Fortran user to check for
> >> end-of-file conditions and handle them as he likes. Other kinds of
> >> errors that can cause core files aren't always so easy to avoid.
>
> > The user did not say why he thought end-of-file conditions should be
> > treated differently from i/o error conditions or errors. I can think
> > of
> > a possible reason. Many years ago, it was common for people to write
> > programs that looped until a READ statement reached the end of the
> > file
> > it was reading. At that time, the END= and IOSTAT= specifiers were
> > not
> > part of standard Fortran. Someone from that era might not consider an
> > end-of-file condition to be an error and therefore not think that
> > detecting an end-of-file condition calls for production of a core
> > file.
>
> Would it be possible to add an environment variable that would force an
> end-of-file condition to raise SIGTERM instead of SIGABRT?

It is possible. Why would raising SIGTERM be better than a normal
exit?
The requesting user wanted a normal exit.

Bob Corbett
From: robert.corbett on 18 May 2010 00:55
On May 15, 4:01 pm, "Gary L. Scott" <garylsc...(a)sbcglobal.net> wrote:

> Core dump should never be the default, only a user selectable option.
> Termination (depending) with a nice RT message should be the default.

I take some pride in the run-time error messages produced by Oracle
Solaris Fortran. One example is

****** FORTRAN RUN-TIME SYSTEM ******
End-of-file: -1
Location: the READ statement at line 1 of "eof.f"
Unit: *
File: standard input
Abort (core dumped)

The complexity of producing nice error messages while supporting I/O
in
a threaded environment caused some people to complain that it was not
worth the cost. I disagree.

Bob Corbett
From: Louis Krupp on 18 May 2010 06:59
On 5/17/2010 10:43 PM, robert.corbett(a)oracle.com wrote:
> On May 15, 12:41 pm, Louis Krupp<lkrupp_nos...(a)indra.com.invalid>
> wrote:
>> On 5/15/2010 4:03 AM, robert.corb...(a)oracle.com wrote:
>>
>>
>>
>>> On May 14, 8:36 pm, nos...(a)see.signature (Richard Maine) wrote:
>>>> <robert.corb...(a)oracle.com> wrote:
>>>>> I recently received a request from a user asking that abort not be
>>>>> called for an end-of-file condition. He made the point that on
>>>>> modern machines core files are often gigabytes long and take
>>>>> some minutes to write.
>>>> ...
>>>>> I would like to know what others think of this request. Also, should
>>>>> abort be called for the end-of-record condition and i/o error
>>>>> conditions?
>>
>>>> I don't see why the size of a core file has anything in particular to do
>>>> with end-of-file (or other i/o conditions). It seems to me that this is
>>>> a much more general issue unrelated to the i/o conditions. If the user
>>>> doesn't want core files because of their size or for any other reason, I
>>>> can see that. What I don't see is singling out the i/o conditions for
>>>> special attention. Sounds to me like a user focusing on what happened to
>>>> him on a particular day instead of looking at a larger and more
>>>> consistent picture. Is this same user going to soon turn around and ask
>>>> for core files to not be produced for the next particular kind of error
>>>> he happens to run into? Much better to show him how to avoid core files
>>>> in general than to hack things one at a time for each class of error
>>>> that he hits.
>>
>>>> In addition to setting the core size limit as you mentioned, it isn't
>>>> exactly complicated or obscure for the Fortran user to check for
>>>> end-of-file conditions and handle them as he likes. Other kinds of
>>>> errors that can cause core files aren't always so easy to avoid.
>>
>>> The user did not say why he thought end-of-file conditions should be
>>> treated differently from i/o error conditions or errors. I can think
>>> of
>>> a possible reason. Many years ago, it was common for people to write
>>> programs that looped until a READ statement reached the end of the
>>> file
>>> it was reading. At that time, the END= and IOSTAT= specifiers were
>>> not
>>> part of standard Fortran. Someone from that era might not consider an
>>> end-of-file condition to be an error and therefore not think that
>>> detecting an end-of-file condition calls for production of a core
>>> file.
>>
>> Would it be possible to add an environment variable that would force an
>> end-of-file condition to raise SIGTERM instead of SIGABRT?
>
> It is possible. Why would raising SIGTERM be better than a normal
> exit?
> The requesting user wanted a normal exit.

As far as I can tell, SIGTERM doesn't trigger a core dump, and it can be
caught in case the user decides that quietly exiting on end-of-file
isn't the greatest idea. It's sort of a compromise between a
30-something-year-old coding style and what today's nerds expect to see.

Louis


First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: getting 64-bit fortran to work on a friend's laptop
Next: deferred length character as subroutine argument