Marco Manfredini said:
I'm just a curios visitor, bewildered by the customs of the local natives.
It's simple: if it's not ANSI/ISO C or K&R C, it's considered off-topic
here, though most people who will give that answer also provide a reference
to a group where the question is likely to be on-topic. For POSIX-y things,
e.g. fork(), that's usually comp.unix.programmer.
Anyway, I could point out that this question *is* on-topic, because
the OP found an external library function which seems to undermine C's
memory model *completely*, an inexplicable
behavior.
It's only inexplicable if that external library function is in conforming
ISO C. Of course, since ISO C does not permit fork() to do what it does,
that's obviously not correct. Specifically, ISO C does not acknowledge that
multiple programs can be running at the same time, therefore it has _no_
model of how the behavior of one program can (or can't) affect the behavior
of another running concurrently.
<OT>However, I find fork() an interesting example, because the program
before the call and the two programs after the call appear to be conforming;
they simply have two independent instances of the ISO C memory model,
initially inherited from the single initial instance but potentially
diverging. Without other non-portable interactions (e.g. IPC), they do not
interact in any way that is detectable by a conforming program.</OT>
S