Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Advanced data structures

Reply
Thread Tools

Advanced data structures

 
 
Ian Collins
Guest
Posts: n/a
 
      01-13-2010
Gareth Owen wrote:
> Eric Sosman <(E-Mail Removed)> writes:
>
>> Whatever the cause, the fact remains: If a call to malloc() causes a
>> conforming program to terminate, the implementation has not followed
>> the specification in the Standard, and has failed to conform.

>
> What if the OS terminates the process without a call to malloc (due to
> some other memory hungry process)?


Then it's a naff OS.

> What if the OS terminates the process without a call to malloc due to
> some other external event (power-off)?


That's irrelevant. The point was malloc shouldn't terminate the
program, it should return NULL.

> If a conforming process must be kept alive regardless of external
> events, can an implementation ever be conforming?


That's irrelevant.

--
Ian Collins
 
Reply With Quote
 
 
 
 
Willem
Guest
Posts: n/a
 
      01-13-2010
Ian Collins wrote:
) That's irrelevant. The point was malloc shouldn't terminate the
) program, it should return NULL.

malloc doesn't terminate the process. At some *later* point in time, when
the malloc()ed memory is actually used, some *other* random process gets
killed.

)> If a conforming process must be kept alive regardless of external
)> events, can an implementation ever be conforming?
)
) That's irrelevant.

False, as shown above.


SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT
 
Reply With Quote
 
 
 
 
Ian Collins
Guest
Posts: n/a
 
      01-13-2010
Willem wrote:
> Ian Collins wrote:
> ) That's irrelevant. The point was malloc shouldn't terminate the
> ) program, it should return NULL.
>
> malloc doesn't terminate the process. At some *later* point in time, when
> the malloc()ed memory is actually used, some *other* random process gets
> killed.


That's awful, but nothing to do with C.

> )> If a conforming process must be kept alive regardless of external
> )> events, can an implementation ever be conforming?
> )
> ) That's irrelevant.
>
> False, as shown above.


How?

--
Ian Collins
 
Reply With Quote
 
gwowen
Guest
Posts: n/a
 
      01-13-2010
On Jan 13, 7:12*am, Ian Collins <(E-Mail Removed)> wrote:
>> What if the OS terminates the process without a call to malloc due to
>> some other external event (power-off)? *

>
> That's irrelevant. *The point was malloc shouldn't terminate the
> program, it should return NULL.


The point is that conforming process should never terminate, unless
the programer calls exit(), abort(), returns from main() or the
like.

int main()
{
while(1) {}
}

Using your description any implementation that kills that process for
any reason is non-conforming. The standard says that program runs for
ever. Therefore, it must run for ever on any conforming
implementation. It's the kind of reductive argument that leads one to
conclude that no implementation is conforming. Possibly logically
true, but completely without merit.
 
Reply With Quote
 
Tim Rentsch
Guest
Posts: n/a
 
      01-13-2010
Eric Sosman <(E-Mail Removed)> writes:

> On 1/12/2010 2:57 PM, Tim Rentsch wrote:
>> Eric Sosman<(E-Mail Removed)> writes:
>>
>>> On 1/8/2010 3:23 AM, gwowen wrote:
>>>> On Jan 7, 10:24 pm, Eric Sosman<(E-Mail Removed)> wrote:
>>>>> That falls under "die catastrophically." If a call to
>>>>> malloc() terminates the program, malloc() has not behaved as
>>>>> the Standard requires.
>>>>
>>>> Well, under linux, a call to malloc() *in someone else's program* can
>>>> cause your program to die catastrophically, so I think looking to the
>>>> C standard for salvation here is not going to help you. One might as
>>>> well look in the C standard to see what happens when your six-year-old
>>>> pulss the power lead out.
>>>
>>> ... and having looked, you'll find that the Standard has
>>> an answer: The implementation ceases to conform.

>>
>> No, because what Linux does isn't part of "the implementation". The
>> Standard identifies the distinction in section 1 paragraph 2, talking
>> about "a data-processing system that is capable of supporting a
>> conforming implementation." Linux is part of the data-processing
>> system, not part of the implementation.

>
> (Take note of the start of paragraph 2: "This International
> Standard does *not* [emphasis mine] specify" ...


Yes, that's precisely the point.

> The root cause of non-conforming behavior is of interest
> only for diagnosis and finger-pointing. Whatever the cause,
> the fact remains: If a call to malloc() causes a conforming
> program to terminate, the implementation has not followed the
> specification in the Standard, and has failed to conform. Or,
> the data-processing system capable of supporting a conforming
> implementation has chosen not to do so or has turned out to be
> incapable.


It's relevant because in one case the item in question is
something covered by the Standard and in another case it isn't.
An implemenation might be conforming but work only on some
versions of Linux, just as an implementation might be conforming
but work only some processor configurations (thsoe with at least
64K of RAM, for example). A conforming C compiler won't run on
my toaster; that doesn't mean my toaster isn't conforming, only
that it can't support a C compiler, and the Standard explicitly
doesn't concern itself with such things.

I have no argument with the essential point you're making,
I just think it's important to say it in a way that's
faithful to the view taken and the language used in
the Standard, because otherwise the meaning gets confused.
If I turn my computer off that doesn't mean my C compiler
suddenly becomes non-conforming; it just means my computer
is off and can't run the (conforming) C compiler.
 
Reply With Quote
 
Ian Collins
Guest
Posts: n/a
 
      01-13-2010
gwowen wrote:
> On Jan 13, 7:12 am, Ian Collins <(E-Mail Removed)> wrote:
>>> What if the OS terminates the process without a call to malloc due to
>>> some other external event (power-off)?

>> That's irrelevant. The point was malloc shouldn't terminate the
>> program, it should return NULL.

>
> The point is that conforming process should never terminate, unless
> the programer calls exit(), abort(), returns from main() or the
> like.


Who or what made that claim?

> int main()
> {
> while(1) {}
> }
>
> Using your description any implementation that kills that process for
> any reason is non-conforming.


Can you cite my description? I don't recall writing one.

> The standard says that program runs for
> ever. Therefore, it must run for ever on any conforming
> implementation.


C&V please.

--
Ian Collins
 
Reply With Quote
 
Eric Sosman
Guest
Posts: n/a
 
      01-13-2010
On 1/13/2010 1:45 AM, Gareth Owen wrote:
> Eric Sosman<(E-Mail Removed)> writes:
>
>> Whatever the cause, the fact remains: If a call to malloc() causes a
>> conforming program to terminate, the implementation has not followed
>> the specification in the Standard, and has failed to conform.

>
> What if the OS terminates the process without a call to malloc (due to
> some other memory hungry process)?
>
> What if the OS terminates the process without a call to malloc due to
> some other external event (power-off)?
>
> If a conforming process must be kept alive regardless of external
> events, can an implementation ever be conforming?


The Standard describes various things that can cause program
termination: returning from the original invocation of main(),
calling exit() or _Exit() or abort(), or receiving a signal that
causes termination (there are implementation-defined aspects
here). Plus, of course, undefined behavior may include program
termination -- or even programmer termination, as illustrated
at <http://dialspace.dial.pipex.com/town/green/gfd34/art/>.

The Standard also describes how a program executes (5.1.2.3,
also 6.8p2), and in these descriptions I see no leeway that
allows `x = y' or any such innocuous construct to terminate the
program (barring U.B., which is the program's fault and not the
implementation's worry).

The only "out" a conforming implementation can use to force
termination is to send a signal, presumably an uncatchable one
or a member of the implementation-defined set for which the
behavior is undefined if a handler attempts to return. But as
far as I can see the signal must actually be raised, even if the
root cause of termination is a bobby pin in the backplane. An
implementation that terminates a conforming program by any means
other than those documented is non-conforming; in language used
elsethread, the data-processing system "capable" of supporting
a conforming implementation has become "incapable."

In the specific case of Linux' Out-Of-Memory killer, I do
not happen to know whether it uses a signal as its murder weapon.
I also don't happen to know whether there's a "losing power"
interrupt that sends SIGPWR to every running program in the last
few milliseconds before the voltage falls too low. I sincerely
doubt the existence of SIGBOBBYPIN ...

--
Eric Sosman
http://www.velocityreviews.com/forums/(E-Mail Removed)lid
 
Reply With Quote
 
gwowen
Guest
Posts: n/a
 
      01-13-2010
On Jan 13, 2:29*pm, Eric Sosman <(E-Mail Removed)> wrote:
> * * *In the specific case of Linux' Out-Of-Memory killer, I do
> not happen to know whether it uses a signal as its murder weapon.


It does. SIGKILL, which POSIX tells us cannot be caught or handled.
 
Reply With Quote
 
Nobody
Guest
Posts: n/a
 
      01-15-2010
On Wed, 13 Jan 2010 09:29:57 -0500, Eric Sosman wrote:

> In the specific case of Linux' Out-Of-Memory killer, I do
> not happen to know whether it uses a signal as its murder weapon.


It uses SIGKILL.

> I also don't happen to know whether there's a "losing power"
> interrupt that sends SIGPWR to every running program in the last
> few milliseconds before the voltage falls too low.


Linux and Solaris have SIGPWR. On Linux, the default (uncaught) behaviour
is to terminate the process, while Solaris ignores it. In both cases, it
can be caught or explicitly ignored.

> I sincerely doubt the existence of SIGBOBBYPIN ...


System failure arguably doesn't result in any processes "terminating".
E.g. a parent process wait()ing on its child will not perceive termination.

If we're competing for the most ridiculous definition of conformance,
it's more interesting to consider the case of partial failure (e.g. cosmic
rays), where (unlike total failure) the rest of the system is still around
to witness the non-conforming behaviour.

 
Reply With Quote
 
Richard Herring
Guest
Posts: n/a
 
      01-22-2010
In message <(E-Mail Removed)-berlin.de>, Stefan
Ram <(E-Mail Removed)-berlin.de> writes
>(E-Mail Removed)-berlin.de (Stefan Ram) writes:
>>In Haskell, the GCD is very ›straightforward‹, as it's
>>fundamental assertions can be written ›directly‹:

>
> ›it's‹ should be ›its‹ instead.


Since you're posting in English, ›its‹ should be "its".

HTH.
--
Richard Herring
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Re: Advanced Python Programming Oxford Lectures [was: Re: *Advanced*Python book?] Michele Simionato Python 1 03-27-2010 06:10 AM
Help with Repeater control and advanced data manipulation Mike Cain ASP .Net 2 10-22-2006 09:31 AM
structures, structures and more structures (questions about nestedstructures) Alfonso Morra C Programming 11 09-24-2005 07:42 PM
ADVANCED data matching? HotRod ASP .Net 2 04-12-2005 01:13 PM
Type Casting IPv4 and IPv6 structures to Generic Structures tweak C Programming 14 06-11-2004 02:43 PM



Advertisments