Override malloc,calloc,realloc and free?
Marco de Boer
I got a library from the net and I suspect there is a memory leak in it!
What can I do to test if there really is a leak? The problem is: no source
of the library!
Can I override the library allocation/free and do some bookkeeping on these
functions to find out?
Marco
Kevin Easton
Not in standard C, you can't. Depending on your operating system, and
the way in which the library was compiled, it may or may not be
possible. Try asking in a newsgroup dedicated to programming for your
particular operating system.
- Kevin.
CBFalconer
If you are operating under DJGPP, and probably most Unices/Linux,
you could use the malldbg provisions in:
<http://cbfalconer.home.att.net/download/nmalloc.zip>
but in general anything of the sort is system dependant, thus OT
on c.l.c.
Incidentally calloc usually calls malloc, but this is not mandated
by the standard AFAIK. If it doesn't the debuggery won't work
properly.
--
Chuck F (cbfal...@yahoo.com) (cbfal...@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
James Kuyper
Legally? No. However, as a practical matter, the answer is "Yes" on many
systems. The simplest way to find out is to try it, though I'd recommend
caution when doing so. The better way is to find out if your library
provider has provided an alternative debugging version of the malloc()
family. What you want to do is a very common need, and as a result it's
not too hard to find such a debugging version.
Barry Margolin
James Kuyper <kuy...@saicmodis.com> wrote:
>Marco de Boer wrote:
>> Can I override the library allocation/free and do some bookkeeping on these
>> functions to find out?
>
Wow, there's a law prohibiting linking with alternate memory management
libraries? Shudder....
--
Barry Margolin, barry.m...@level3.com
Level(3), Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
James Kuyper
>
> In article <3EDC9CA8...@saicmodis.com>,
> James Kuyper <kuy...@saicmodis.com> wrote:
> >Marco de Boer wrote:
> >> Can I override the library allocation/free and do some bookkeeping on these
> >> functions to find out?
> >
> >Legally? No.
>
> Wow, there's a law prohibiting linking with alternate memory management
> libraries? Shudder....
OK! If you insist, I'll change that to:
With defined behavior? No.
But that sounds a lot clumsier.
Barry Margolin
Since the standard doesn't even provide a way to *try* to do it, I'm not
sure that this characterization even applies.
When you use a debugging memory management library, you're essentially
running the implementation in a non-conforming mode, expressly giving it
permission to display warnings when it detects legal, but unwanted,
activity like memory leaks.
James Kuyper
>
> In article <3EDCB0AD...@saicmodis.com>,
> James Kuyper <kuy...@saicmodis.com> wrote:
> >Barry Margolin wrote:
> >>
> >> In article <3EDC9CA8...@saicmodis.com>,
> >> James Kuyper <kuy...@saicmodis.com> wrote:
> >> >Marco de Boer wrote:
> >> >> Can I override the library allocation/free and do some bookkeeping on these
> >> >> functions to find out?
> >> >
> >> >Legally? No.
> >>
> >> Wow, there's a law prohibiting linking with alternate memory management
> >> libraries? Shudder....
> >
> >OK! If you insist, I'll change that to:
> >
> > With defined behavior? No.
> >
> >But that sounds a lot clumsier.
>
> Since the standard doesn't even provide a way to *try* to do it, I'm not
> sure that this characterization even applies.
The language does provide a way to try it, which the standard explicitly
says has undefined behavior. Define your own functions with external
linkage named malloc(), free(), calloc(), and realloc(), and link them
into your program. that's essentially what alternative memory
management libraries do. This has undefined behavior because you're
defining an identifier in a context in which it's reserved, but only
because of that explicit specification. Those libraries can be relied
upon to work only because they're usually constructed in close
collaboration with the development of the standard library
implementation that they supplement.
On the other hand, I've had good results using my own hand-written
malloc() family written without any collaboration with the standard
library providers. That's because many things that could, in principle
go wrong, don't actually go wrong in some circumstances; not because
it's actually a good way to do things.
> When you use a debugging memory management library, you're essentially
> running the implementation in a non-conforming mode, expressly giving it
And the standard does not define the behavior of non-conforming
implementations.
bd
> Marco de Boer wrote:
>>
>> I got a library from the net and I suspect there is a memory leak in it!
>> What can I do to test if there really is a leak? The problem is: no source
>> of the library!
>> Can I override the library allocation/free and do some bookkeeping on these
>> functions to find out?
>
> If you are operating under DJGPP, and probably most Unices/Linux,
> you could use the malldbg provisions in:
>
> <http://cbfalconer.home.att.net/download/nmalloc.zip>
>
> but in general anything of the sort is system dependant, thus OT
> on c.l.c.
>
> Incidentally calloc usually calls malloc, but this is not mandated
> by the standard AFAIK. If it doesn't the debuggery won't work
> properly.
That's a silly way to implement it - it can't grow an already-allocated
space? I'd think malloc would call calloc...
Barry Margolin
calloc doesn't have to grow an already-allocated space -- I think you're
thinking of realloc.
calloc is usually malloc followed by memset or bzero.
James Kuyper
>
> On Tue, 03 Jun 2003 12:19:54 +0000, CBFalconer wrote:
>
> > Marco de Boer wrote:
> > Incidentally calloc usually calls malloc, but this is not mandated
> > by the standard AFAIK. If it doesn't the debuggery won't work
> > properly.
>
> That's a silly way to implement it - it can't grow an already-allocated
> space? I'd think malloc would call calloc...
Perhaps you're thinking of realloc() rather than calloc()? Having
malloc() call calloc() would be a very inefficient way of doing things.
realloc() can be written so that it does initial allocations by calling
malloc(); whether that's worthwhile depends upon the details.
Eric Sosman
I think you've mis-read "calloc" as "realloc".
The biggest potential problem with substituting your
own memory manager for the implementation's version is
that you're aware of only the public interface: malloc(),
calloc(), realloc(), free(). What you don't know is that
the fopen() function in Frobozz Magic C uses a special
back door _memadjust() function to do some strange task
the implementation needs. If you're lucky you'll get a
complaint at link time when fopen() can't find _memadjust().
If you're unlucky, fopen() *will* find _memadjust(), but
naturally _memadjust() expects to work with data structures
that look nothing like those in your replacement code ...
Of course, there's nothing special about the memory
management parts of the library: any part of the standard
library might have sub rosa hooks into any other part, so
the whole may be interconnected in unadvertised ways. For
example, we know that exit() must call all the functions
registered with atexit(), so the two must communicate
somehow. fflush(NULL) must flush all open output streams,
so it must cooperate with fopen() and fclose() to be able
to find them all. locale() must have a way to affect the
outcome of isalpha() and friends. getc() needs to set an
indicator feof() can interrogate. And the list goes on.
The point is that *all* these "internal interfaces" are
outside the realm of the Standard, need not be documented,
and need not even remain the same from one library version
to the next. Pull on one exposed thread and you risk
unravelling the whole garment.
Dan Pop
What if the alternate memory management libraries are provided by the
implementaion?
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Dan...@ifh.de
James Kuyper
Of course a conforming implementation can provide alternative memory
management as an option, so long as the features that make it
'alternative' don't themselves render it non-conforming. Keep in mind
that my original answer was about the possibility of a user-provided
override, not about an implementation-provided override.
Dan Pop
But the topic has drifted from user provided replacement to linking
alternate memory management libraries and you kept your position...
Furthermore, even user provided replacements are OK, if they are defined
in the same translation unit with the code using them, with internal
linkage and <stdlib.h> is not included.
James Kuyper
Yes, I kept my original position, which was about user-provided
replacements. All I did was re-word my original statement to accomodate
the implied criticism. I didn't suggest that my new wording would apply
to implementation-provided alternatives.
> Furthermore, even user provided replacements are OK, if they are defined
> in the same translation unit with the code using them, with internal
> linkage and <stdlib.h> is not included.
Certainly. The reason I gave was based upon the use an identifier which
is reserved only for identifiers with external linkage. What you're
suggesting isn't much different, for practical purposes, from designing
a memory management system that uses entirely different names from the
standard library's names.
Dan Pop
Except that it uses the same names as the standard library. Which is an
important distinction, when instrumenting an application without hacking
much of its code: the only change needed is replacing #include <stdlib.h>
by #include "debug.h".
In practice, this can also be achieved without touching the source
code at all, by overriding the implementation's <stdlib.h>, but in
these newsgroups we have to pretend that this is not acceptable :-)
Eric Sosman
>
> Except that it uses the same names as the standard library. Which is an
> important distinction, when instrumenting an application without hacking
> much of its code: the only change needed is replacing #include <stdlib.h>
> by #include "debug.h".
The technique Dan describes can be very useful, but
there's one important caveat: You (usually) don't have
the source to the standard library functions themselves,
and thus can't introduce #include "debug.h" into them.
That means that if fopen() or some other library function
calls malloc(), those allocations will not be handled
by your replacement package.
Where this *really* becomes nasty is when a library
function allocates memory, hands you a pointer to it,
and leaves you with the responsibility to free() it.
Off-hand I can think of no Standard library functions
other than the memory allocators themselves that behave
this way, but some common extensions like strdup() do
so. That means that a perfectly correct usage like
char *p = strdup("something");
...
free(p);
turns into trash if #include "debug.h" changes it to
char *p = strdup("something");
...
my_free(__FILE__, __LINE__, p);
because, of course, my_free() expects to be handed a
block of memory obtained from my_malloc() or a close
relative, but the block returned by strdup() wasn't
allocated that way.
Jun Woong
"Eric Sosman" <Eric....@sun.com> wrote in message news:3EDE2580...@sun.com...
> Dan Pop wrote:
> >
> > Except that it uses the same names as the standard library. Which is an
> > important distinction, when instrumenting an application without hacking
> > much of its code: the only change needed is replacing #include <stdlib.h>
> > by #include "debug.h".
>
> The technique Dan describes can be very useful, but
> there's one important caveat: You (usually) don't have
> the source to the standard library functions themselves,
> and thus can't introduce #include "debug.h" into them.
> That means that if fopen() or some other library function
> calls malloc(), those allocations will not be handled
> by your replacement package.
Good point. Some library functions should allocate memory for their
own purpose. If enough source codes of the library is not available,
the only way to avoid this problem is to replace all doubtful library
functions used by the program provided that it works at all. Even if
it's possible to knock out some part of the library by providing
functions of identical names, it's still feasible for the rest of the
library to use internal functions for their memory allocation.
--
Jun, Woong (myco...@hanmail.net)
Dept. of Physics, Univ. of Seoul
Christian Bau
wrote:
If you take an existing Standard conforming implementation of C and
replace malloc/calloc/etc. then obviously the C Standard doesn't say
anything about what will happen. You have created a new implementation,
and you have to decide whether it is a standard conforming C
implementation or not.
A C implementation cannot provide an alternative library. A compiler
vendor can however provide two separate libraries and claim that
(compiler + library 1) is an implementation of C, and that (compiler +
library 2) is also an implementation of C.
Dan Pop
>Dan Pop wrote:
>>
>> Except that it uses the same names as the standard library. Which is an
>> important distinction, when instrumenting an application without hacking
>> much of its code: the only change needed is replacing #include <stdlib.h>
>> by #include "debug.h".
>
> The technique Dan describes can be very useful, but
>there's one important caveat: You (usually) don't have
>the source to the standard library functions themselves,
>and thus can't introduce #include "debug.h" into them.
And you don't want to do that, either.
>That means that if fopen() or some other library function
>calls malloc(), those allocations will not be handled
>by your replacement package.
The replacement package I was describing above is useful for replacing
malloc and friends in one translation unit only. And there are good
reasons for wanting to do that. If the replacements are actually
wrappers on the implementation's functions, you've got full
interoperativity between the various parts of the program.
If you want to replace them everywhere, linking in an alternate library
is a much simpler and cleaner solution.
Dan Pop
>In article <bbke59$l14$1...@sunnews.cern.ch>, Dan...@cern.ch (Dan Pop)
>wrote:
>
>> In <3EDCB0AD...@saicmodis.com> James Kuyper <kuy...@saicmodis.com>
>> writes:
>>
>> >Barry Margolin wrote:
>> >>
>> >> In article <3EDC9CA8...@saicmodis.com>,
>> >> James Kuyper <kuy...@saicmodis.com> wrote:
>> >> >Marco de Boer wrote:
>> >> >> Can I override the library allocation/free and do some bookkeeping on
>> >> >> these
>> >> >> functions to find out?
>> >> >
>> >> >Legally? No.
>> >>
>> >> Wow, there's a law prohibiting linking with alternate memory management
>> >> libraries? Shudder....
>> >
>> >OK! If you insist, I'll change that to:
>> >
>> > With defined behavior? No.
>> >
>> >But that sounds a lot clumsier.
>>
>> What if the alternate memory management libraries are provided by the
>> implementaion?
>
>A C implementation cannot provide an alternative library.
Chapter and verse, please.
>A compiler
>vendor can however provide two separate libraries and claim that
>(compiler + library 1) is an implementation of C, and that (compiler +
>library 2) is also an implementation of C.
This is not what happens in practice. It is common to have two or three
libraries for the same compiler (shared, static, profiling) without the
vendor claiming that he is providing three different implementations.
Eric Sosman
>
> If you want to replace [malloc(), etc] everywhere, linking in an
> alternate library is a much simpler and cleaner solution.
... A solution that invokes undefined behavior, of course,
unless you replace the *entire* Standard library. As it
happens, the undefined behavior quite often turns out to
be exactly what you wanted. But there's no guarantee of
that, and I personally have used a C implementation where
it wouldn't work at all.
Also, the my_malloc() approach allows for the gathering
of more debugging information: __FILE__ and __LINE__ of
the point where a block of memory was allocated, or of the
point where somebody tried to my_free() or my_realloc() a
chunk of already-free or non-dynamic memory, for example.
Some systems offer non-portable means to discover some of
this data (a return address, at minimum), but I personally
favor debugging packages that don't have to be rewritten
every time I move to a new machine.
The "link an alternate implementation" approach has the
advantages of simplicity and of full coverage, and the
disadvantages of inflexibility and non-portability. The
"rename the API" approach has the advantages of portability
and flexibility, but the disadvantages of incomplete coverage
and the mix-'n-match problems I described earlier. You pays
your money and you takes your choice.
Dan Pop
>Dan Pop wrote:
>>
>> If you want to replace [malloc(), etc] everywhere, linking in an
>> alternate library is a much simpler and cleaner solution.
>
>... A solution that invokes undefined behavior, of course,
>unless you replace the *entire* Standard library.
Again, where is the undefined behaviour, if the alternate library is part
of the implementation?
>As it
>happens, the undefined behavior quite often turns out to
>be exactly what you wanted. But there's no guarantee of
>that, and I personally have used a C implementation where
>it wouldn't work at all.
Carefully written implementations actually take care to use the library
version of a function for their own purposes *even* in the cases when
the user replaces them by his own version. E.g. fopen could call
__malloc() instead of malloc(), to be sure that it uses the right memory
allocation function even if the user has replaced the definition of
malloc().
It's not guaranteed by the standard, but this doesn't prevent the
competent implementor from doing it.
> The "link an alternate implementation" approach has the
>advantages of simplicity and of full coverage, and the
>disadvantages of inflexibility and non-portability.
Since this is done for debugging purposes, these are non-issues. The
final application is supposed to be linked against the "official"
libraries.
Christian Bau
wrote:
> In <christian.bau-591...@slb-newsm1.svr.pol.co.uk> Christian
> Bau <christ...@cbau.freeserve.co.uk> writes:
>
> >A C implementation cannot provide an alternative library.
>
> Chapter and verse, please.
No chapter and verse, pure logic. If there is an alternative library,
then it is a different implementation.
> >A compiler
> >vendor can however provide two separate libraries and claim that
> >(compiler + library 1) is an implementation of C, and that (compiler +
> >library 2) is also an implementation of C.
>
> This is not what happens in practice. It is common to have two or three
> libraries for the same compiler (shared, static, profiling) without the
> vendor claiming that he is providing three different implementations.
Doesn't matter what the vendor claims. They are three different
implementations.
Dan Pop
>In article <bbn29j$6uj$2...@sunnews.cern.ch>, Dan...@cern.ch (Dan Pop)
>wrote:
>
>> In <christian.bau-591...@slb-newsm1.svr.pol.co.uk> Christian
>> Bau <christ...@cbau.freeserve.co.uk> writes:
>>
>> >A C implementation cannot provide an alternative library.
>>
>> Chapter and verse, please.
>
>No chapter and verse, pure logic. If there is an alternative library,
>then it is a different implementation.
Not if, from the standard conformance point of view, the two libraries
behave identically.
Keith Thompson
If two compilers, developed independently, happen to behave
identically, they're still two different implementations (or rather,
when combined with a library, they're *part of* two different
implementations).
On the other hand, the question of whether compiler C with library L1
and compiler C with library L2 are two different implementations is,
as far as I can tell, spectactularly unimportant.
--
Keith Thompson (The_Other_Keith) k...@cts.com <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"
E. Robert Tisdale
> I got a library from the net and I suspect there is a memory leak in it!
> What can I do to test if there really is a leak?
> The problem is: no source of the library!
> Can I override the library allocation/free
> and do some bookkeeping on these functions to find out?
> expand malloc.c
#include<stdio.h>
#include<stdlib.h>
void *malloc(size_t size) {
fprintf(stdout, "Hello from malloc!\n"); fflush(stdout);
return NULL;
}
int main(int argc, char* argv[]) {
void* p = malloc(666);
return 0;
}
> gcc -Wall -std=c99 -pedantic -o malloc malloc.c
malloc.c: In function `main':
malloc.c:9: warning: unused variable `p'
> ./malloc
Hello from malloc!
Keith Thompson
Very nice. Now watch what happens when I add a call to strdup().
% cat malloc2.c
#include<stdio.h>
#include<stdlib.h>
#include<string.h>
void *malloc(size_t size) {
fprintf(stdout, "Hello from malloc!\n"); fflush(stdout);
return NULL;
}
int main(int argc, char* argv[]) {
void* p = malloc(666);
char *s = strdup("Hello from strdup!\n");
printf("s = \"%s\"\n", s);
return 0;
}
% gcc -Wall -std=c99 -pedantic -o malloc2 malloc2.c
malloc2.c: In function `main':
malloc2.c:11: warning: implicit declaration of function `strdup'
malloc2.c:11: warning: initialization makes pointer from integer without a cast
malloc2.c:10: warning: unused variable `p'
% ./malloc2
Hello from malloc!
Hello from malloc!
Segmentation fault
Of course, strdup() is not a standard C function (which is why we get
the extra warnings), but other functions in the standard library could
just as easily call malloc().
Dan Pop
>Dan...@cern.ch (Dan Pop) writes:
>> In <christian.bau-B98...@slb-newsm1.svr.pol.co.uk>
>> Christian Bau <christ...@cbau.freeserve.co.uk> writes:
>> >In article <bbn29j$6uj$2...@sunnews.cern.ch>, Dan...@cern.ch (Dan Pop)
>> >wrote:
>> >> In <christian.bau-591...@slb-newsm1.svr.pol.co.uk>
>> >> Christian Bau <christ...@cbau.freeserve.co.uk> writes:
>> >> >A C implementation cannot provide an alternative library.
>> >>
>> >> Chapter and verse, please.
>> >
>> >No chapter and verse, pure logic. If there is an alternative library,
>> >then it is a different implementation.
>>
>> Not if, from the standard conformance point of view, the two libraries
>> behave identically.
>
>If two compilers, developed independently, happen to behave
>identically, they're still two different implementations (or rather,
>when combined with a library, they're *part of* two different
>implementations).
Which is irrelevant here, since all the components are coming from the
same implementor.
>On the other hand, the question of whether compiler C with library L1
>and compiler C with library L2 are two different implementations is,
>as far as I can tell, spectactularly unimportant.
But this didn't prevent you from joining the discussion, did it? ;-)
Jun Woong
"Dan Pop" <Dan...@cern.ch> wrote in message news:bc4ink$nu1$2...@sunnews.cern.ch...
> In <yec65nj...@king.cts.com> Keith Thompson <k...@cts.com> writes:
>
> >Dan...@cern.ch (Dan Pop) writes:
> >> In <christian.bau-B98...@slb-newsm1.svr.pol.co.uk>
> >> Christian Bau <christ...@cbau.freeserve.co.uk> writes:
> >> >In article <bbn29j$6uj$2...@sunnews.cern.ch>, Dan...@cern.ch (Dan Pop)
> >> >wrote:
> >> >> In <christian.bau-591...@slb-newsm1.svr.pol.co.uk>
> >> >> Christian Bau <christ...@cbau.freeserve.co.uk> writes:
> >> >> >A C implementation cannot provide an alternative library.
> >> >>
> >> >> Chapter and verse, please.
> >> >
> >> >No chapter and verse, pure logic. If there is an alternative library,
> >> >then it is a different implementation.
> >>
> >> Not if, from the standard conformance point of view, the two libraries
> >> behave identically.
> >
> >If two compilers, developed independently, happen to behave
> >identically, they're still two different implementations (or rather,
> >when combined with a library, they're *part of* two different
> >implementations).
>
> Which is irrelevant here, since all the components are coming from the
> same implementor.
>
You seems to be only one here to not understand what the
"implementation" means. I don't think it's sane to call a translator
combined with two different libraries the same implementation only
because they behave identically from the the standard conformance
point of view. Switching an option makes a different implementation by
the definition of the "implementation."
Dan Pop
>"Dan Pop" <Dan...@cern.ch> wrote in message news:bc4ink$nu1$2...@sunnews.cern.ch...
>> In <yec65nj...@king.cts.com> Keith Thompson <k...@cts.com> writes:
>>
>> >Dan...@cern.ch (Dan Pop) writes:
>> >> In <christian.bau-B98...@slb-newsm1.svr.pol.co.uk>
>> >> Christian Bau <christ...@cbau.freeserve.co.uk> writes:
>> >> >In article <bbn29j$6uj$2...@sunnews.cern.ch>, Dan...@cern.ch (Dan Pop)
>> >> >wrote:
>> >> >> In <christian.bau-591...@slb-newsm1.svr.pol.co.uk>
>> >> >> Christian Bau <christ...@cbau.freeserve.co.uk> writes:
>> >> >> >A C implementation cannot provide an alternative library.
>> >> >>
>> >> >> Chapter and verse, please.
>> >> >
>> >> >No chapter and verse, pure logic. If there is an alternative library,
>> >> >then it is a different implementation.
>> >>
>> >> Not if, from the standard conformance point of view, the two libraries
>> >> behave identically.
>> >
>> >If two compilers, developed independently, happen to behave
>> >identically, they're still two different implementations (or rather,
>> >when combined with a library, they're *part of* two different
>> >implementations).
>>
>> Which is irrelevant here, since all the components are coming from the
>> same implementor.
>
>You seems to be only one here to not understand what the
>"implementation" means.
It means what the standard says it means:
3.12
1 implementation
particular set of software, running in a particular translation
environment under particular control options, that performs
translation of programs for, and supports execution of functions
in, a particular execution environment
>I don't think it's sane to call a translator
>combined with two different libraries the same implementation only
>because they behave identically from the the standard conformance
>point of view.
If the "particular set of software" includes two libraries, the definition
of "implementation" is satisfied, regardless of what *you* think.
>Switching an option makes a different implementation by
>the definition of the "implementation."
I don't think so, as long as the option doesn't affect the
implementation's conformance. E.g. if I enable additional diagnostics
(not required by the standard) or the compiler's verbose mode, I don't
have another implementation.
Keith Thompson
> In <bc4p2m$13q$1...@news.hananet.net> "Jun Woong" <myco...@hanmail.net> writes:
> It means what the standard says it means:
>
> 3.12
> 1 implementation
> particular set of software, running in a particular translation
> environment under particular control options, that performs
> translation of programs for, and supports execution of functions
> in, a particular execution environment
> >Switching an option makes a different implementation by
> >the definition of the "implementation."
>
> I don't think so, as long as the option doesn't affect the
> implementation's conformance. E.g. if I enable additional diagnostics
> (not required by the standard) or the compiler's verbose mode, I don't
> have another implementation.
Why wouldn't that be covered by the phrase "under particular control
options"? As I read it, 3.12 states pretty clearly that a different
set of control options implies a different implementation.
I don't see that the "as long as the option doesn't affect the
implementation's conformance" qualification is meaningful. If an
implementation no longer conforms, it arguably isn't an implementation
at all.
Jun Woong
> >
> >You seems to be only one here to not understand what the
> >"implementation" means.
>
> It means what the standard says it means:
>
> 3.12
> 1 implementation
> particular set of software, running in a particular translation
> environment under particular control options, that performs
> translation of programs for, and supports execution of functions
> in, a particular execution environment
>
> >I don't think it's sane to call a translator
> >combined with two different libraries the same implementation only
> >because they behave identically from the the standard conformance
> >point of view.
>
> If the "particular set of software" includes two libraries, the definition
> of "implementation" is satisfied, regardless of what *you* think.
Good point, I accept it. Now you gain a basis for your argument with
losing a basis against the others' argument in the same time. I think,
the definition is described in a vague way intentionally, which
doesn't prohibit either interpretation.
>
> >Switching an option makes a different implementation by
> >the definition of the "implementation."
>
> I don't think so, as long as the option doesn't affect the
> implementation's conformance.
Do you think that the definition has a legal force for non-conforming
implementations?
> E.g. if I enable additional diagnostics
> (not required by the standard) or the compiler's verbose mode, I don't
> have another implementation.
>
Which is explicitly covered by the definition.
Jun Woong
"Jun Woong" <myco...@hanmail.net> wrote in message news:bc8vjn$df2$1...@news.hananet.net...[...]
>
> Do you think that the definition has a legal force for non-conforming
> implementations?
>
> > E.g. if I enable additional diagnostics
> > (not required by the standard) or the compiler's verbose mode, I don't
> > have another implementation.
> >
>
> Which is explicitly covered by the definition.
>
I mean, there is nothing to prevent them from being regarded as
different implementations.
Christian Bau
wrote:
> I don't see that the "as long as the option doesn't affect the
> implementation's conformance" qualification is meaningful. If an
> implementation no longer conforms, it arguably isn't an implementation
> at all.
The CodeWarrior compiler has an option "char is signed" vs. "char is
unsigned". Which one you choose doesn't affect the implementation's
conformance. But that is certainly a different implementation. And I
have seen compilers that let you choose whether int = 16 bit or int = 32
bit.
Black Phantom
> >Switching an option makes a different implementation by
> >the definition of the "implementation."
>
> I don't think so, as long as the option doesn't affect the
> implementation's conformance. E.g. if I enable additional diagnostics
> (not required by the standard) or the compiler's verbose mode, I don't
> have another implementation.
OTOH if you toggle an option "treat char as signed/unsigned" you
definitely do have two distinct implementations, both conforming.
/BP
Dan Pop
>In article <yec4r2w...@king.cts.com>, Keith Thompson <k...@cts.com>
>wrote:
>
>> I don't see that the "as long as the option doesn't affect the
>> implementation's conformance" qualification is meaningful. If an
>> implementation no longer conforms, it arguably isn't an implementation
>> at all.
What I meant to say was: it doesn't affect the implementation's document
of conformance. The implementation is still conforming, but certain
implementation-defined characteristics are different.
>The CodeWarrior compiler has an option "char is signed" vs. "char is
>unsigned". Which one you choose doesn't affect the implementation's
>conformance. But that is certainly a different implementation. And I
>have seen compilers that let you choose whether int = 16 bit or int = 32
>bit.
It does affect the implementation's document of conformance:
8 An implementation shall be accompanied by a document that defines
all implementation-defined and locale-specific characteristics
and all extensions.
OTOH, enabling additional warnings doesn't affect this document at all:
nothing in the observable behaviour of the implementation (as far as the
standard is concerned) changes.
Dan Pop
But with different documents of conformance.
Dan Pop
>Dan...@cern.ch (Dan Pop) writes:
>> In <bc4p2m$13q$1...@news.hananet.net> "Jun Woong" <myco...@hanmail.net> writes:
>[...]
>> It means what the standard says it means:
>>
>> 3.12
>> 1 implementation
>> particular set of software, running in a particular translation
>> environment under particular control options, that performs
>> translation of programs for, and supports execution of functions
>> in, a particular execution environment
>[...]
>> >Switching an option makes a different implementation by
>> >the definition of the "implementation."
>>
>> I don't think so, as long as the option doesn't affect the
>> implementation's conformance. E.g. if I enable additional diagnostics
>> (not required by the standard) or the compiler's verbose mode, I don't
>> have another implementation.
>
>Why wouldn't that be covered by the phrase "under particular control
>options"? As I read it, 3.12 states pretty clearly that a different
>set of control options implies a different implementation.
Then, the implementation would have to provide a different document of
conformance for each option that doesn't render it non-conforming, right?
Since no implementation does that, the logical conclusion, according to
your argument, is that there is no conforming implementation.
Jun Woong
"Dan Pop" <Dan...@cern.ch> wrote in message news:bc9ccg$rjl$1...@sunnews.cern.ch...
> In <christian.bau-E55...@slb-newsm1.svr.pol.co.uk> Christian Bau <christ...@cbau.freeserve.co.uk> writes:
>
>
> >The CodeWarrior compiler has an option "char is signed" vs. "char is
> >unsigned". Which one you choose doesn't affect the implementation's
> >conformance. But that is certainly a different implementation. And I
> >have seen compilers that let you choose whether int = 16 bit or int = 32
> >bit.
>
> It does affect the implementation's document of conformance:
>
> 8 An implementation shall be accompanied by a document that defines
> all implementation-defined and locale-specific characteristics
> and all extensions.
>
> OTOH, enabling additional warnings doesn't affect this document at all:
> nothing in the observable behaviour of the implementation (as far as the
> standard is concerned) changes.
>
What if a software to manage compilation of the program is considered
to be part of the "implementation?" For example, the implemention can
behave differently depedning on the contents or the number of the
diagnostics. And what if the implementer defines execution with the
option for additional diagnotics as a different implementation in the
document? What prevents him from doing it? I don't think that the
definition of "implementation" is intended to be interpreted so
tightly.
Jun Woong
"Dan Pop" <Dan...@cern.ch> wrote in message news:bc9co3$rjl$4...@sunnews.cern.ch...[...]
> >
> >Why wouldn't that be covered by the phrase "under particular control
> >options"? As I read it, 3.12 states pretty clearly that a different
> >set of control options implies a different implementation.
>
> Then, the implementation would have to provide a different document of
> conformance for each option that doesn't render it non-conforming, right?
>
You mean "one document per one implementation?"
Dan Pop
>"Dan Pop" <Dan...@cern.ch> wrote in message news:bc9ccg$rjl$1...@sunnews.cern.ch...
>> In <christian.bau-E55...@slb-newsm1.svr.pol.co.uk> Christian Bau <christ...@cbau.freeserve.co.uk> writes:
>>
>[...]
>>
>> >The CodeWarrior compiler has an option "char is signed" vs. "char is
>> >unsigned". Which one you choose doesn't affect the implementation's
>> >conformance. But that is certainly a different implementation. And I
>> >have seen compilers that let you choose whether int = 16 bit or int = 32
>> >bit.
>>
>> It does affect the implementation's document of conformance:
>>
>> 8 An implementation shall be accompanied by a document that defines
>> all implementation-defined and locale-specific characteristics
>> and all extensions.
>>
>> OTOH, enabling additional warnings doesn't affect this document at all:
>> nothing in the observable behaviour of the implementation (as far as the
>> standard is concerned) changes.
>>
>
>What if a software to manage compilation of the program is considered
>to be part of the "implementation?" For example, the implemention can
>behave differently depedning on the contents or the number of the
>diagnostics.
Once the implementation has issued *one* required diagnostic, it has
fully satisfied all the requirements imposed on it by the standard.
Issuing non-required diagnostics is entirely irrelevant from the point
of view of conformance.
>And what if the implementer defines execution with the
>option for additional diagnotics as a different implementation in the
>document?
If the implementor provides two documents of conformance, one for each
case, we have two different implementations.
>What prevents him from doing it? I don't think that the
>definition of "implementation" is intended to be interpreted so
>tightly.
Then, submit a DR :-)
Dan Pop
>"Dan Pop" <Dan...@cern.ch> wrote in message news:bc9co3$rjl$4...@sunnews.cern.ch...
>> In <yec4r2w...@king.cts.com> Keith Thompson <k...@cts.com> writes:
>[...]
>> >
>> >Why wouldn't that be covered by the phrase "under particular control
>> >options"? As I read it, 3.12 states pretty clearly that a different
>> >set of control options implies a different implementation.
>>
>> Then, the implementation would have to provide a different document of
>> conformance for each option that doesn't render it non-conforming, right?
>
>You mean "one document per one implementation?"
Yes. Well, this is actually what the standard requires.
David Hopwood
Dan Pop wrote:
> In <bcc694$r2t$1...@news.hananet.net> "Jun Woong" <myco...@hanmail.net> writes:
> >"Dan Pop" <Dan...@cern.ch> wrote in message news:bc9co3$rjl$4...@sunnews.cern.ch...
> >> In <yec4r2w...@king.cts.com> Keith Thompson <k...@cts.com> writes:
> >[...]
> >> >
> >> >Why wouldn't that be covered by the phrase "under particular control
> >> >options"? As I read it, 3.12 states pretty clearly that a different
> >> >set of control options implies a different implementation.
Yes.
> >> Then, the implementation would have to provide a different document of
> >> conformance for each option that doesn't render it non-conforming, right?
> >
> >You mean "one document per one implementation?"
>
> Yes. Well, this is actually what the standard requires.
The standard requires that, for each implementation, there exists a document
that defines the implementation-defined behaviour of that implementation.
It does not say that all such documents must be distinct. If a vendor
provides a single document that contains some text that is conditional on
which of their implementations was selected, that is a perfectly reasonable
way of meeting the requirement.
- --
David Hopwood <david....@zetnet.co.uk>
Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: noconv
iQEVAwUBPujHejkCAxeYt5gVAQHq2wgAkd2y+R+e2ZIR1RwNUttft1KHhyhJNIcj
j+1vYr3ZpMHWPDAiVIBiZ98K0Bkvl5F2q45QKmfygY4jY+ZcjDoBlRmNM18rDh0b
+Adj/eQmZJjEk1cUd9PW+K+KS5O62ogXrWoYkwmsZR0GIcmrz251pOvknS7O7Ut6
mXBKUKVki4B+PiOLgPEgIxqdMrRITmUY2l2rpGRGNKTZMa+qeowpOdHBlaiNtxwO
O9bu0tjZBsZkKBIS5VaBL9c+YyBkN6hjOd4kBLoub9IgWayZb1JqmkGpLwtSP7Ii
G87WMJSkntSAkbuXcRWYuFQLCeOF0FWAW2fCbiGKUpMEqXzZoaOXcA==
=b9HH
-----END PGP SIGNATURE-----
Dan Pop
>Dan Pop wrote:
>> In <bcc694$r2t$1...@news.hananet.net> "Jun Woong" <myco...@hanmail.net> writes:
>> >"Dan Pop" <Dan...@cern.ch> wrote in message news:bc9co3$rjl$4...@sunnews.cern.ch...
>> >> In <yec4r2w...@king.cts.com> Keith Thompson <k...@cts.com> writes:
>> >[...]
>> >> >
>> >> >Why wouldn't that be covered by the phrase "under particular control
>> >> >options"? As I read it, 3.12 states pretty clearly that a different
>> >> >set of control options implies a different implementation.
>
>Yes.
>
>> >> Then, the implementation would have to provide a different document of
>> >> conformance for each option that doesn't render it non-conforming, right?
>> >
>> >You mean "one document per one implementation?"
>>
>> Yes. Well, this is actually what the standard requires.
>
>The standard requires that, for each implementation, there exists a document
>that defines the implementation-defined behaviour of that implementation.
>It does not say that all such documents must be distinct. If a vendor
>provides a single document that contains some text that is conditional on
>which of their implementations was selected, that is a perfectly reasonable
>way of meeting the requirement.
Agreed. But it's still, logically, two different documents (one applying
to one implementation, the other applying to the other), even if,
physically, it is a single document.
OTOH, such documents don't contain conditional parts related to options
that don't alter the compiler's behaviour, from the standard's point of
view (e.g. enable additional warnings). Which was actually my point.
Jun Woong
"Dan Pop" <Dan...@cern.ch> wrote in message news:bccj6o$454$1...@sunnews.cern.ch...
> In <bcc66g$r1v$1...@news.hananet.net> "Jun Woong" <myco...@hanmail.net> writes:
>
> >"Dan Pop" <Dan...@cern.ch> wrote in message news:bc9ccg$rjl$1...@sunnews.cern.ch...
> >> In <christian.bau-E55...@slb-newsm1.svr.pol.co.uk> Christian Bau <christ...@cbau.freeserve.co.uk> writes:
> >>
> >[...]
> >>
> >> >The CodeWarrior compiler has an option "char is signed" vs. "char is
> >> >unsigned". Which one you choose doesn't affect the implementation's
> >> >conformance. But that is certainly a different implementation. And I
> >> >have seen compilers that let you choose whether int = 16 bit or int = 32
> >> >bit.
> >>
> >> It does affect the implementation's document of conformance:
> >>
> >> 8 An implementation shall be accompanied by a document that defines
> >> all implementation-defined and locale-specific characteristics
> >> and all extensions.
> >>
> >> OTOH, enabling additional warnings doesn't affect this document at all:
> >> nothing in the observable behaviour of the implementation (as far as the
> >> standard is concerned) changes.
> >>
> >
> >What if a software to manage compilation of the program is considered
> >to be part of the "implementation?" For example, the implemention can
> >behave differently depedning on the contents or the number of the
> >diagnostics.
>
> Once the implementation has issued *one* required diagnostic, it has
> fully satisfied all the requirements imposed on it by the standard.
>
> Issuing non-required diagnostics is entirely irrelevant from the point
> of view of conformance.
If the implementation (which is a particular set of softwares) decides
a way to treat its conforming programs depending on the number of the
(non-required) diagnostics (which can't be issued by s.c. programs,
it's conforming and the option can make a different implementation.
>
> >And what if the implementer defines execution with the
> >option for additional diagnotics as a different implementation in the
> >document?
>
> If the implementor provides two documents of conformance, one for each
> case, we have two different implementations.
The number of documents is irrelevant. What the standard ways with the
citation above is just that a conforming implementation should
documents something to be required to do so. If other softwares like
an OS count as part of an implementation, in general, there are more
than one document for the implementation.
>
> >What prevents him from doing it? I don't think that the
> >definition of "implementation" is intended to be interpreted so
> >tightly.
>
> Then, submit a DR :-)
>
I don't see nothing wrong with the current state in the light of that
the definition is written in a vague way intentionally.
Jun Woong
"Dan Pop" <Dan...@cern.ch> wrote in message news:bccsq7$nqc$2...@sunnews.cern.ch...[...]
> >
> >The standard requires that, for each implementation, there exists a document
> >that defines the implementation-defined behaviour of that implementation.
> >It does not say that all such documents must be distinct. If a vendor
> >provides a single document that contains some text that is conditional on
> >which of their implementations was selected, that is a perfectly reasonable
> >way of meeting the requirement.
>
> Agreed. But it's still, logically, two different documents (one applying
> to one implementation, the other applying to the other), even if,
> physically, it is a single document.
Which can imply that the number of the documents doesn't matter in
fact.
>
> OTOH, such documents don't contain conditional parts related to options
> that don't alter the compiler's behaviour, from the standard's point of
> view (e.g. enable additional warnings). Which was actually my point.
>
The standard doesn't cover every possible execution of an
implementation. If it can affect the behavior of a conforming program
translated and executed in the implementation whether a certain
diagnostic is issued, there is no problem in defining it as a
different implementation. And even if an option doesn't actually
affect translation or execution of a given program, it's still allowed
for an implementer to define the implementation with the option as
invocation for a different one by definition, which is certainly rare
in practice.
Dan Pop
The non-required diagnostics can only make a difference in the case of
programs invoking undefined behaviour. But such programs raise no
conformance issues. In the case of correct C programs, the non required
diagnostics are not allowed to affect the translation process, if the
implementation is used in conforming mode. Modulo the infamous quote that
requires the implementation to only translate and execute one program.
Dan Pop
>"Dan Pop" <Dan...@cern.ch> wrote in message news:bccsq7$nqc$2...@sunnews.cern.ch...
>> In <3EE8C798...@zetnet.co.uk> David Hopwood <david....@zetnet.co.uk> writes:
>[...]
>> >
>> >The standard requires that, for each implementation, there exists a document
>> >that defines the implementation-defined behaviour of that implementation.
>> >It does not say that all such documents must be distinct. If a vendor
>> >provides a single document that contains some text that is conditional on
>> >which of their implementations was selected, that is a perfectly reasonable
>> >way of meeting the requirement.
>>
>> Agreed. But it's still, logically, two different documents (one applying
>> to one implementation, the other applying to the other), even if,
>> physically, it is a single document.
>
>Which can imply that the number of the documents doesn't matter in
>fact.
The number of logical documents does count. If the implementation has
3 options, but only 2 logical files, you can have only 2 conforming
implementations. The other options either render the implementation
non-conforming or don't affect the implementation's conformance.
Jun Woong
> >
> >If the implementation (which is a particular set of softwares) decides
> >a way to treat its conforming programs depending on the number of the
> >(non-required) diagnostics (which can't be issued by s.c. programs,
> >it's conforming and the option can make a different implementation.
>
> The non-required diagnostics can only make a difference in the case of
> programs invoking undefined behaviour.
I'm talking about "conforming programs", not strictly conforming
programs, which makes the rest of your argument moot. And the standard
doesn't prohibit execution of a conforming implementation from being
identified as a different implementation when its treatment of
conforming programs changes. That's what I'd like to say.
Jun Woong
"Dan Pop" <Dan...@cern.ch> wrote in message news:bck40d$jci$3...@sunnews.cern.ch...[...]
> >
> >Which can imply that the number of the documents doesn't matter in
> >fact.
>
> The number of logical documents does count. If the implementation has
> 3 options, but only 2 logical files, you can have only 2 conforming
> implementations. The other options either render the implementation
> non-conforming or don't affect the implementation's conformance.
Agreed. And the number and structure of logical documents (maybe
contained in one physical document) could be so complicated that it's
uneasy to divide it into parts for different implementations each.
Dan Pop
>"Dan Pop" <Dan...@cern.ch> wrote in message news:bck3r2$jci$2...@sunnews.cern.ch...
>> In <bcdlbq$2oq$1...@news.hananet.net> "Jun Woong" <myco...@hanmail.net> writes:
>[...]
>> >
>> >If the implementation (which is a particular set of softwares) decides
>> >a way to treat its conforming programs depending on the number of the
>> >(non-required) diagnostics (which can't be issued by s.c. programs,
>> >it's conforming and the option can make a different implementation.
>>
>> The non-required diagnostics can only make a difference in the case of
>> programs invoking undefined behaviour.
>
>I'm talking about "conforming programs", not strictly conforming
>programs, which makes the rest of your argument moot.
Nope, it doesn't. There are two categories of conforming programs:
correct programs and programs requiring a diagnostic or invoking
undefined behaviour. The standard handles each of them quite
differently.
Jun Woong
"Dan Pop" <Dan...@cern.ch> wrote in message news:bckoe8$ghd$1...@sunnews.cern.ch...[...]
> >
> >I'm talking about "conforming programs", not strictly conforming
> >programs, which makes the rest of your argument moot.
>
> Nope, it doesn't. There are two categories of conforming programs:
> correct programs and programs requiring a diagnostic or invoking
> undefined behaviour.
More precisely, the former is called "strictly conforming programs,"
and the latter just "conforming programs."
> The standard handles each of them quite
> differently.
>
I don't see what this fact does with your argument in the previous
posting or the definition of "implementation." It's quite true that
an option purely related to the number of not-required diagnostics
should not affect s. c. programs, there is no problem with the current
definition of "implementation" for an implementer to define execution
with the option as invocation of a different implementation whether or
not the additional diagnostic affects conforming programs.
Dan Pop
>"Dan Pop" <Dan...@cern.ch> wrote in message news:bckoe8$ghd$1...@sunnews.cern.ch...
>> In <bck9i8$1c7$1...@news.hananet.net> "Jun Woong" <myco...@hanmail.net> writes:
>>
>[...]
>> >
>> >I'm talking about "conforming programs", not strictly conforming
>> >programs, which makes the rest of your argument moot.
>>
>> Nope, it doesn't. There are two categories of conforming programs:
>> correct programs and programs requiring a diagnostic or invoking
>> undefined behaviour.
>
>More precisely, the former is called "strictly conforming programs,"
>and the latter just "conforming programs."
You're in dire need of a clue:
3 A program that is correct in all other aspects, operating on
correct data, containing unspecified behavior shall be a correct
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
program and act in accordance with 5.1.2.3.
This specification doesn't seem to match the definition of a strictly
conforming program, does it? Therefore, such a program can only be
a conforming program (the standard defines only these two categories of
programs).
Jun Woong
"Dan Pop" <Dan...@cern.ch> wrote in message news:bcmnak$b8d$1...@sunnews.cern.ch...[...]
> >
> >More precisely, the former is called "strictly conforming programs,"
> >and the latter just "conforming programs."
>
> You're in dire need of a clue:
>
> 3 A program that is correct in all other aspects, operating on
> correct data, containing unspecified behavior shall be a correct
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> program and act in accordance with 5.1.2.3.
>
> This specification doesn't seem to match the definition of a strictly
> conforming program, does it?
A s.c. program can contain unspecified behavior, as long as its output
doesn't depend on that behavior. The wording you cited is for emphasis
on the fact (that mere existence of unspecified behavior in a program
doesn't make the program invalid). There wasn't such a wording in C90
and IIRC it was first introduced as a supplement to the definition of
"unspecified behavior." I don't know why the committee moved it there
instead of making it just a note on the definition. Maybe it might be
an attempt to introduce a new level for conformance, but if so, it
failed because of the ambiguous word "correct." There was a proposal
to introduce a new well-defined term to replace "correct", but
rejected by the committee on the ground of that the current state of
conformance was good enough.
> Therefore, such a program can only be
> a conforming program (the standard defines only these two categories of
> programs).
>
A conforming program is explicitly defined by the standard:
A conforming program is one that is acceptable to a conforming
implementation.
This is even more tolerative concept than one used in general. For
example, if an implementation decides to accept Fortran programs
additionally, then they are conforming programs to the implementation.
Dan Pop
>"Dan Pop" <Dan...@cern.ch> wrote in message news:bcmnak$b8d$1...@sunnews.cern.ch...
>> In <bclpoa$een$1...@news.hananet.net> "Jun Woong" <myco...@hanmail.net> writes:
>>
>[...]
>> >
>> >More precisely, the former is called "strictly conforming programs,"
>> >and the latter just "conforming programs."
>>
>> You're in dire need of a clue:
>>
>> 3 A program that is correct in all other aspects, operating on
>> correct data, containing unspecified behavior shall be a correct
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> program and act in accordance with 5.1.2.3.
>>
>> This specification doesn't seem to match the definition of a strictly
>> conforming program, does it?
>
>A s.c. program can contain unspecified behavior, as long as its output
>doesn't depend on that behavior.
The quoted paragraph is not restricted to programs whose unspecified
behaviour does NOT affect their output. Therefore, strictly conforming
programs are a non-issue in context.
>The wording you cited is for emphasis
>on the fact (that mere existence of unspecified behavior in a program
>doesn't make the program invalid). There wasn't such a wording in C90
>and IIRC it was first introduced as a supplement to the definition of
>"unspecified behavior." I don't know why the committee moved it there
>instead of making it just a note on the definition. Maybe it might be
>an attempt to introduce a new level for conformance,
Nope, it ain't: the paragraph contains no text in italics.
>but if so, it failed because of the ambiguous word "correct."
The ambiguity of "correct" is a non-issue. If the paragraph contained
the words "correct program" in italics, it would have effectively
introduced a new level of conformance. As it is, it merely specifies
that a certain class of conforming programs has the same status as
the strictly conforming programs.
>There was a proposal
>to introduce a new well-defined term to replace "correct", but
>rejected by the committee on the ground of that the current state of
>conformance was good enough.
The current state of conformance is next to useless: strictly conforming
programs are seldom found among real life applications and a conforming
program, as defined by the standard, can be practically anything.
>> Therefore, such a program can only be
>> a conforming program (the standard defines only these two categories of
>> programs).
>>
>
>A conforming program is explicitly defined by the standard:
I have read the standard myself, thank you. The definition doesn't
contradict anything I have said above.
Jun Woong
3 A program that is correct in all other aspects, operating on
correct data, containing unspecified behavior shall be a correct
program and act in accordance with 5.1.2.3.
> >
> >A s.c. program can contain unspecified behavior, as long as its output
> >doesn't depend on that behavior.
>
> The quoted paragraph is not restricted to programs whose unspecified
> behaviour does NOT affect their output. Therefore, strictly conforming
> programs are a non-issue in context.
Yes, it covers both categories, some of conforming programs and
effectively all of s.c. programs.
>
> >The wording you cited is for emphasis
> >on the fact (that mere existence of unspecified behavior in a program
> >doesn't make the program invalid). There wasn't such a wording in C90
> >and IIRC it was first introduced as a supplement to the definition of
> >"unspecified behavior." I don't know why the committee moved it there
> >instead of making it just a note on the definition. Maybe it might be
> >an attempt to introduce a new level for conformance,
>
> Nope, it ain't: the paragraph contains no text in italics.
I said about the real intent of the committee behind the wording, not
its literal interpretation since I wondered (and wonder) about why the
committee cares about the behavior of some conforming programs at all.
>
> >but if so, it failed because of the ambiguous word "correct."
>
> The ambiguity of "correct" is a non-issue.
There was an attemp to replace the "correct" with a well-defined term
and to introduce a uesful level for conformance in practice, which is
what I meant to say.
> If the paragraph contained
> the words "correct program" in italics, it would have effectively
> introduced a new level of conformance. As it is, it merely specifies
> that a certain class of conforming programs has the same status as
> the strictly conforming programs.
Agreed.
>
> >There was a proposal
> >to introduce a new well-defined term to replace "correct", but
> >rejected by the committee on the ground of that the current state of
> >conformance was good enough.
>
> The current state of conformance is next to useless:
Yes, useless to programmers, but it might satisfy implementers.
> >
> >A conforming program is explicitly defined by the standard:
>
> I have read the standard myself, thank you. The definition doesn't
> contradict anything I have said above.
>
Okay, I see your point. Sorry for my misunderstanding of your wording
in the previous posting. Back to the discussion:
[...]
> It's quite true that an option purely related to the number of
> not-required diagnostics should not affect s. c. programs [and some
> conforming programs], [but] there is no problem with the current
> definition of "implementation" for an implementer to define
> execution with the option as invocation of a different
> implementation whether or not the additional diagnostic affects
> conforming programs.
Still holds, doesn't it?
Dan Pop
>"Dan Pop" <Dan...@cern.ch> wrote in message news:bcn6ig$jfi$1...@sunnews.cern.ch...
>> In <bcmvfo$gp2$1...@news.hananet.net> "Jun Woong" <myco...@hanmail.net> writes:
>>
>[...]
>
>3 A program that is correct in all other aspects, operating on
> correct data, containing unspecified behavior shall be a correct
> program and act in accordance with 5.1.2.3.
>
>> >A s.c. program can contain unspecified behavior, as long as its output
>> >doesn't depend on that behavior.
>>
>> The quoted paragraph is not restricted to programs whose unspecified
>> behaviour does NOT affect their output. Therefore, strictly conforming
>> programs are a non-issue in context.
>
>Yes, it covers both categories, some of conforming programs and
>effectively all of s.c. programs.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Where did you get the idea that all strictly conforming programs
contain unspecified behavior?
I'm not saying that strictly conforming programs aren't correct programs,
merely that the paragraph quoted above doesn't talk about them.
>> >The wording you cited is for emphasis
>> >on the fact (that mere existence of unspecified behavior in a program
>> >doesn't make the program invalid). There wasn't such a wording in C90
>> >and IIRC it was first introduced as a supplement to the definition of
>> >"unspecified behavior." I don't know why the committee moved it there
>> >instead of making it just a note on the definition. Maybe it might be
>> >an attempt to introduce a new level for conformance,
>>
>> Nope, it ain't: the paragraph contains no text in italics.
>
>I said about the real intent of the committee behind the wording, not
>its literal interpretation since I wondered (and wonder) about why the
>committee cares about the behavior of some conforming programs at all.
For the obvious reason that a standard that provides guarantees *only*
for strictly conforming programs is next to useless. This paragraph
extends the guarantees to an important class of non-strictly conforming
programs (programs that don't require a diagnostic and don't invoke
undefined behaviour).
>> >but if so, it failed because of the ambiguous word "correct."
>>
>> The ambiguity of "correct" is a non-issue.
>
>There was an attemp to replace the "correct" with a well-defined term
>and to introduce a uesful level for conformance in practice, which is
>what I meant to say.
"Correct program" can be as well defined as the standard makes it to be,
just as "strictly conforming program" and "conforming program". There is
need to replace "correct" by any word, if the standard provides a formal
definition for "correct program" (which is currently not the case).
>> If the paragraph contained
>> the words "correct program" in italics, it would have effectively
>> introduced a new level of conformance. As it is, it merely specifies
>> that a certain class of conforming programs has the same status as
>> the strictly conforming programs.
>
>Agreed.
>
>>
>> >There was a proposal
>> >to introduce a new well-defined term to replace "correct", but
>> >rejected by the committee on the ground of that the current state of
>> >conformance was good enough.
>>
>> The current state of conformance is next to useless:
>
>Yes, useless to programmers, but it might satisfy implementers.
How?
>> It's quite true that an option purely related to the number of
>> not-required diagnostics should not affect s. c. programs [and some
>> conforming programs], [but] there is no problem with the current
>> definition of "implementation" for an implementer to define
>> execution with the option as invocation of a different
>> implementation whether or not the additional diagnostic affects
>> conforming programs.
>
>Still holds, doesn't it?
Given the current definition of implementation, the implementor can
even claim that each installation of his implementation is a different
implementation (i.e. foo-c on your computer is a different implementation
than foo-c on my computer, even if they are otherwise identical). Many
foolish things are allowed by the definition, so what?
Jun Woong
"Dan Pop" <Dan...@cern.ch> wrote in message news:bcngk3$ep2$1...@sunnews.cern.ch...[...]
> >
> >Yes, it covers both categories, some of conforming programs and
> >effectively all of s.c. programs.
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> Where did you get the idea that all strictly conforming programs
> contain unspecified behavior?
For quick search, from the informative list of unspecified behaviors
and the definition of "behavior."
>
> I'm not saying that strictly conforming programs aren't correct programs,
> merely that the paragraph quoted above doesn't talk about them.
Is there any problem in saying that all s.c. programs contain
unspecified behavior with their output not depending on it?
> >
> >I said about the real intent of the committee behind the wording, not
> >its literal interpretation since I wondered (and wonder) about why the
> >committee cares about the behavior of some conforming programs at all.
>
> For the obvious reason that a standard that provides guarantees *only*
> for strictly conforming programs is next to useless. This paragraph
> extends the guarantees to an important class of non-strictly conforming
> programs (programs that don't require a diagnostic and don't invoke
> undefined behaviour).
But in a vague way with the term "correct." What is the correct data
and what is the program that's correct in all other aspects? The
standard transfers the interpretation problem to the readers' common
sense which can vary in context.
> >
> >There was an attemp to replace the "correct" with a well-defined term
> >and to introduce a uesful level for conformance in practice, which is
> >what I meant to say.
>
> "Correct program" can be as well defined as the standard makes it to be,
> just as "strictly conforming program" and "conforming program".
Nevertheless, the committee decided not to define it on the ground of
that ...
[...]
> >>
> >> The current state of conformance is next to useless:
> >
> >Yes, useless to programmers, but it might satisfy implementers.
>
> How?
>
What I meant is, s.c. programs are too strict and conforming programs
too loose, and an implementer can easily make his implementation
conform to the standard with them.
> >
> >Still holds, doesn't it?
>
> Given the current definition of implementation, the implementor can
> even claim that each installation of his implementation is a different
> implementation (i.e. foo-c on your computer is a different implementation
> than foo-c on my computer, even if they are otherwise identical). Many
> foolish things are allowed by the definition, so what?
>
Nothing. I just wanted to check my understanding of the definition,
not to claim anything.
Dan Pop
>"Dan Pop" <Dan...@cern.ch> wrote in message news:bcngk3$ep2$1...@sunnews.cern.ch...
>> In <bcnbpd$3pr$1...@news.hananet.net> "Jun Woong" <myco...@hanmail.net> writes:
>>
>[...]
>> >
>> >Yes, it covers both categories, some of conforming programs and
>> >effectively all of s.c. programs.
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> Where did you get the idea that all strictly conforming programs
>> contain unspecified behavior?
>
>For quick search, from the informative list of unspecified behaviors
>and the definition of "behavior."
???
I can give you countless examples of s.c. programs with no unspecified
behaviour. Starting with the one doing nothing, continuing with the
canonical "hello world" program and so on.
>> I'm not saying that strictly conforming programs aren't correct programs,
>> merely that the paragraph quoted above doesn't talk about them.
>
>Is there any problem in saying that all s.c. programs contain
>unspecified behavior with their output not depending on it?
Yes, because it is a patently false statement. See above.
>> >I said about the real intent of the committee behind the wording, not
>> >its literal interpretation since I wondered (and wonder) about why the
>> >committee cares about the behavior of some conforming programs at all.
>>
>> For the obvious reason that a standard that provides guarantees *only*
>> for strictly conforming programs is next to useless. This paragraph
>> extends the guarantees to an important class of non-strictly conforming
>> programs (programs that don't require a diagnostic and don't invoke
>> undefined behaviour).
>
>But in a vague way with the term "correct." What is the correct data
>and what is the program that's correct in all other aspects? The
>standard transfers the interpretation problem to the readers' common
>sense which can vary in context.
The standard doesn't allow much room for variation: no diagnostic
required, no undefined behaviour (caused by either the program or its
data).
>> >There was an attemp to replace the "correct" with a well-defined term
>> >and to introduce a uesful level for conformance in practice, which is
>> >what I meant to say.
>>
>> "Correct program" can be as well defined as the standard makes it to be,
>> just as "strictly conforming program" and "conforming program".
>
>Nevertheless, the committee decided not to define it on the ground of
>that ...
>
>[...]
>> >>
>> >> The current state of conformance is next to useless:
>> >
>> >Yes, useless to programmers, but it might satisfy implementers.
>>
>> How?
>
>What I meant is, s.c. programs are too strict and conforming programs
>too loose, and an implementer can easily make his implementation
>conform to the standard with them.
But the paragraph in question effectively gives status of strictly
conforming program to a certain class of conforming programs, thus
rendering the C89 classification (SC vs C) pointless.
Douglas A. Gwyn
The category of (not strictly-) "conforming program" has no real
impact on implementation conformance to the standard.
> But the paragraph in question effectively gives status of strictly
> conforming program to a certain class of conforming programs, thus
> rendering the C89 classification (SC vs C) pointless.
Of course s.c. programs that make modest demands on resources are
likely to be conforming programs also, being accepted by several
conforming implementations.
Whatever confusion there is on this score is probably due to the
use of the word "conforming" in a context where implementation
conformance is not an issue. The category of (not strictly-)
"conforming program" can and should simply be ignored; its only
practical value is/was a political one.
Jun Woong
"Dan Pop" <Dan...@cern.ch> wrote in message news:bcpfne$5t4$2...@sunnews.cern.ch...[...]
> >
> >For quick search, from the informative list of unspecified behaviors
> >and the definition of "behavior."
>
> ???
>
> I can give you countless examples of s.c. programs with no unspecified
> behaviour. Starting with the one doing nothing, continuing with the
> canonical "hello world" program and so on.
How about
The following are unspecified:
- The manner and timing of static initialization (5.1.2).
[...]
- Many aspects of the representations of types (6.2.6).
and the definition of "behavior,"
external appearance or action
?
I think the following s.c. program does contain unspecified behavior
without depending on it:
int a;
int main(void)
{
return 0;
}
but not quite sure about this:
int main(void)
{
return 0;
}
with use of the type "int" about which many things are unspecified.
> >
> >But in a vague way with the term "correct." What is the correct data
> >and what is the program that's correct in all other aspects? The
> >standard transfers the interpretation problem to the readers' common
> >sense which can vary in context.
>
> The standard doesn't allow much room for variation: no diagnostic
> required, no undefined behaviour (caused by either the program or its
> data).
I don't think so. The term "correct" isn't defined technically and
used in common sense. Even if a program doesn't invoke any undefined
behavior, if it doesn't behave as the programmer intends for any
reason, then it can be said that it's not correct. The standard
doesn't use "correct" in defining "undefined behavior" or something
like that. I doubt usefulness of the paragraph.
> >
> >What I meant is, s.c. programs are too strict and conforming programs
> >too loose, and an implementer can easily make his implementation
> >conform to the standard with them.
>
> But the paragraph in question effectively gives status of strictly
> conforming program to a certain class of conforming programs, thus
> rendering the C89 classification (SC vs C) pointless.
>
As Doug said, conforming programs does nothing with conformance
problem in fact. My understanding and the author's intent of the
paragraph is emphasis on the fact that the mere existence of
unspecified behavior is irrelevant with conformance problem; IIRC it
was written by Clive to be appended to the definition of "unspecified
behavior."
Douglas A. Gwyn
> How about
> The following are unspecified:
> - The manner and timing of static initialization (5.1.2).
> [...]
> - Many aspects of the representations of types (6.2.6).
So long as the behavior ("output") of the program does not
depend on the unspecified aspects, the program remains s.c.
Jun Woong
"Douglas A. Gwyn" <DAG...@null.net> wrote in message news:3EF1AEC3...@null.net...
Yes, that's what I'd like to say. And another question is whether or
not the two s.c. programs in my previous posting contain unspecified
behavior (or aspect).
Clive D. W. Feather
<barry.m...@level3.com> writes
>Wow, there's a law prohibiting linking with alternate memory management
>libraries?
Computer Misuse Act?
--
Clive D.W. Feather, writing for himself | Home: <cl...@davros.org>
Tel: +44 20 8371 1138 (work) | Web: <http://www.davros.org>
Fax: +44 870 051 9937 | Work: <cl...@demon.net>
Written on my laptop; please observe the Reply-To address
Dan Pop
>"Dan Pop" <Dan...@cern.ch> wrote in message news:bcpfne$5t4$2...@sunnews.cern.ch...
>> In <bcnjm1$pr2$1...@news.hananet.net> "Jun Woong" <myco...@hanmail.net> writes:
>[...]
>> >
>> >For quick search, from the informative list of unspecified behaviors
>> >and the definition of "behavior."
>>
>> ???
>>
>> I can give you countless examples of s.c. programs with no unspecified
>> behaviour. Starting with the one doing nothing, continuing with the
>> canonical "hello world" program and so on.
>
>How about
>
> The following are unspecified:
> - The manner and timing of static initialization (5.1.2).
> [...]
> - Many aspects of the representations of types (6.2.6).
>
>and the definition of "behavior,"
>
> external appearance or action
>
>?
>
>I think the following s.c. program does contain unspecified behavior
>without depending on it:
>
> int a;
>
> int main(void)
> {
> return 0;
> }
Where is that "unspecified behavior", according the definition of
"behaviour" you have posted above?
>but not quite sure about this:
>
> int main(void)
> {
> return 0;
> }
What makes you unsure about this one?
>with use of the type "int" about which many things are unspecified.
But we're talking about unspecified *behaviour* here, not about
unspecified things in general.
>> >But in a vague way with the term "correct." What is the correct data
>> >and what is the program that's correct in all other aspects? The
>> >standard transfers the interpretation problem to the readers' common
>> >sense which can vary in context.
>>
>> The standard doesn't allow much room for variation: no diagnostic
>> required, no undefined behaviour (caused by either the program or its
>> data).
>
>I don't think so. The term "correct" isn't defined technically and
>used in common sense. Even if a program doesn't invoke any undefined
>behavior, if it doesn't behave as the programmer intends for any
>reason, then it can be said that it's not correct.
Correctness from the point of view of the standard is not the same thing
as correctness from the point of view of the user. I thought this was
obvious. The following program is correct from the point of view of the
user (it works on most (if not all) conforming implementations), but
obviously not from the point of view of the standard:
int printf();
int main()
{
printf("hello, world\n");
}
>The standard
>doesn't use "correct" in defining "undefined behavior" or something
>like that.
It actually does:
1 undefined behavior
behavior, upon use of a nonportable or erroneous program
construct or of erroneous data, for which this International
Standard imposes no requirements
"Erroneous" is a synonym for "incorrect". Do I also have to mention the
relationship between "correct" and "incorrect"?
>I doubt usefulness of the paragraph.
One has to be a patent idiot or deliberately obtuse to misinterpret the
paragraph. Remember, it is supposed to be read in the context of the
whole standard, not as a standalone piece of text.
>> >What I meant is, s.c. programs are too strict and conforming programs
>> >too loose, and an implementer can easily make his implementation
>> >conform to the standard with them.
>>
>> But the paragraph in question effectively gives status of strictly
>> conforming program to a certain class of conforming programs, thus
>> rendering the C89 classification (SC vs C) pointless.
>
>As Doug said, conforming programs does nothing with conformance
>problem in fact.
This was true in C89. In C99, correct programs, which are a class of
conforming programs, must be properly handled by a conforming
implementation. The rest of the conforming programs are still irrelevant.
>My understanding and the author's intent of the
>paragraph is emphasis on the fact that the mere existence of
>unspecified behavior is irrelevant with conformance problem; IIRC it
>was written by Clive to be appended to the definition of "unspecified
>behavior."
Considering the actual place where the paragraph appears and its actual
wording, the paragraph is quite relevant. It says that the following
program:
#include <stdio.h>
#include <limits.h>
int main()
{
printf("%d\n", INT_MAX);
}
has the same status as a strictly conforming program, as far the
implementation's conformance is concerned. C89 provided no such
guarantee.
Jun Woong
"Dan Pop" <Dan...@cern.ch> wrote in message news:bcur8q$hjv$3...@sunnews.cern.ch...[...]
> >
> >How about
> >
> > The following are unspecified:
> > - The manner and timing of static initialization (5.1.2).
> > [...]
> > - Many aspects of the representations of types (6.2.6).
> >
> >and the definition of "behavior,"
> >
> > external appearance or action
> >
> >?
> >
> >I think the following s.c. program does contain unspecified behavior
> >without depending on it:
> >
> > int a;
> >
> > int main(void)
> > {
> > return 0;
> > }
>
> Where is that "unspecified behavior", according the definition of
> "behaviour" you have posted above?
The manner and timing of static initialization.
>
> >but not quite sure about this:
> >
> > int main(void)
> > {
> > return 0;
> > }
>
> What makes you unsure about this one?
Many aspects of the type "int" are unspecified. But I have no idea
about whether or not this means that I can say the program contains
unspecified behavior.
>
> >with use of the type "int" about which many things are unspecified.
>
> But we're talking about unspecified *behaviour* here, not about
> unspecified things in general.
>
But the definition of "behavior" also includes "external appearance,"
which is the major reason I suspect the above two contain unspecified
behavior.
[...]
> Do I also have to mention the
> relationship between "correct" and "incorrect"?
>
[...]
> One has to be a patent idiot or deliberately obtuse to misinterpret the
> paragraph. Remember, it is supposed to be read in the context of the
> whole standard, not as a standalone piece of text.
>
What you said looks like a reasonable interpretation which can be
gotten from the text of the standard. But in the light of some history
about the paragraph, I'm asking about the intent of the author.
BTW I'm sorry to say this but, what do you think about the reason that
people say you are rude? I don't want to start a childish flame war
with you again.
Douglas A. Gwyn
> "Dan Pop" <Dan...@cern.ch> wrote...
> > Where is that "unspecified behavior", according the definition of
> > "behaviour" you have posted above?
> The manner and timing of static initialization.
That's not "behavior" in the sense that matters for conformance.
It's an unspecified *aspect* of the implementation. It would be
very difficult to make a program have its behavior depend on the
details of this aspect.
> But the definition of "behavior" also includes "external appearance,"
> which is the major reason I suspect the above two contain unspecified
> behavior.
? So far as the C standard is concerned, the behavior of a program
manifests itself in the output of the program, for example in
modifications it makes to external files.
Dan Pop
>"Dan Pop" <Dan...@cern.ch> wrote in message news:bcur8q$hjv$3...@sunnews.cern.ch...
>> In <bcrf23$lt0$1...@news.hananet.net> "Jun Woong" <myco...@hanmail.net> writes:
>[...]
>> >
>> >How about
>> >
>> > The following are unspecified:
>> > - The manner and timing of static initialization (5.1.2).
>> > [...]
>> > - Many aspects of the representations of types (6.2.6).
>> >
>> >and the definition of "behavior,"
>> >
>> > external appearance or action
>> >
>> >?
>> >
>> >I think the following s.c. program does contain unspecified behavior
>> >without depending on it:
>> >
>> > int a;
>> >
>> > int main(void)
>> > {
>> > return 0;
>> > }
>>
>> Where is that "unspecified behavior", according the definition of
>> "behaviour" you have posted above?
>
>The manner and timing of static initialization.
How is it affecting the *program's behaviour*? Keep in mind the
definition of behaviour you have posted above.
>> >but not quite sure about this:
>> >
>> > int main(void)
>> > {
>> > return 0;
>> > }
>>
>> What makes you unsure about this one?
>
>Many aspects of the type "int" are unspecified. But I have no idea
>about whether or not this means that I can say the program contains
>unspecified behavior.
If you have no idea, then check the relevant definitions.
>> >with use of the type "int" about which many things are unspecified.
>>
>> But we're talking about unspecified *behaviour* here, not about
>> unspecified things in general.
>
>But the definition of "behavior" also includes "external appearance,"
>which is the major reason I suspect the above two contain unspecified
>behavior.
How is the program's "external appearance" affected by these issues?
Jun Woong
"Dan Pop" <Dan...@cern.ch> wrote in message news:bd7061$npe$2...@sunnews.cern.ch...[...]
> >
> >But the definition of "behavior" also includes "external appearance,"
> >which is the major reason I suspect the above two contain unspecified
> >behavior.
>
> How is the program's "external appearance" affected by these issues?
>
Then, what's the purpose of the "external appearance" in the
definition? For what aspect of programs can I say its "external
appearance?" That's what I'd like to know.
Jun Woong
> Jun Woong wrote:
> > "Dan Pop" <Dan...@cern.ch> wrote...
> > > Where is that "unspecified behavior", according the definition of
> > > "behaviour" you have posted above?
> > The manner and timing of static initialization.
>
> That's not "behavior" in the sense that matters for conformance.
> It's an unspecified *aspect* of the implementation. It would be
> very difficult to make a program have its behavior depend on the
> details of this aspect.
I accept it.
>
> > But the definition of "behavior" also includes "external appearance,"
> > which is the major reason I suspect the above two contain unspecified
> > behavior.
>
> ?
What I'd like to know is the purpose of "external appearance" in the
definition. What's the "external appearance" of a program exactly?
> So far as the C standard is concerned, the behavior of a program
> manifests itself in the output of the program, for example in
> modifications it makes to external files.
But, is there behavior which doesn't affect the program's output but
which still affects the program's conformance?
Dan Pop
>"Dan Pop" <Dan...@cern.ch> wrote in message news:bd7061$npe$2...@sunnews.cern.ch...
>> In <bcvh4n$il$1...@news.hananet.net> "Jun Woong" <myco...@hanmail.net> writes:
>[...]
>> >
>> >But the definition of "behavior" also includes "external appearance,"
>> >which is the major reason I suspect the above two contain unspecified
>> >behavior.
>>
>> How is the program's "external appearance" affected by these issues?
>
>Then, what's the purpose of the "external appearance" in the
>definition? For what aspect of programs can I say its "external
>appearance?" That's what I'd like to know.
Since I'm not the author of the definition, I'm afraid I can't enlighten
you. In my view, the "external appearance" is defined exclusively by the
program's actions, so the definition contains some redundancy.
Douglas A. Gwyn
> But, is there behavior which doesn't affect the program's output but
> which still affects the program's conformance?
I still don't understand what the problem is supposed to be.
A program might not *have* any output if it is rejected by the
implementation for containing undefined behavior etc.
There are essentially three kinds of program behavior:
(1) specified.
(2) unspecified but "stable".
(3) undefined.
A s.c. program contains no instances of (3).
A s.c. program can contain instances of (2), but its output
shall not depend on which of the allowed choices the
implementation has made for each such instance (except for
locale-specific behavior, which we intentionally allow to
affect the output as a special kludge to encourage use of
locales).
Dan Pop
>I still don't understand what the problem is supposed to be.
>A program might not *have* any output if it is rejected by the
>implementation for containing undefined behavior etc.
>There are essentially three kinds of program behavior:
>(1) specified.
>(2) unspecified but "stable".
>(3) undefined.
>A s.c. program contains no instances of (3).
>A s.c. program can contain instances of (2), but its output
>shall not depend on which of the allowed choices the
>implementation has made for each such instance
What *exactly* is defining the program's behaviour, apart from its
output (in the context of the C standard)?
If it's only its output, then it makes no sense to say that a strictly
conforming program can contain unspecified behaviour if its output does
not depend on it.
Douglas A. Gwyn
What I said makes perfect sense. It is your attempt to reduce
the semantic content to a mere macro expansion of definitions
that prevents understanding.
Dan Pop
>Dan Pop wrote:
>> In <3EFB3935...@null.net> "Douglas A. Gwyn" <DAG...@null.net> writes:
>> >There are essentially three kinds of program behavior:
>> >(1) specified.
>> >(2) unspecified but "stable".
>> >(3) undefined.
>> >A s.c. program contains no instances of (3).
>> >A s.c. program can contain instances of (2), but its output
>> >shall not depend on which of the allowed choices the
>> >implementation has made for each such instance
>> What *exactly* is defining the program's behaviour, apart from its
>> output (in the context of the C standard)?
>> If it's only its output, then it makes no sense to say that a strictly
>> conforming program can contain unspecified behaviour if its output does
>> not depend on it.
>
>What I said makes perfect sense.
To you, maybe.
>It is your attempt to reduce
>the semantic content to a mere macro expansion of definitions
>that prevents understanding.
I fail to see how this is supposed to clarify the statements you've made
in your previous post. Sheer insult doesn't make a particularly
convincing argument. But if this is the best you can produce...
Jun Woong
"Douglas A. Gwyn" <DAG...@null.net> wrote in message news:3EFB3935...@null.net...
> Jun Woong wrote:
> > But, is there behavior which doesn't affect the program's output but
> > which still affects the program's conformance?
>
> I still don't understand what the problem is supposed to be.
The real problem is the meaning of the definition for "behavior,"
especially the purpose of the phrase "external appearance" in it.
> A program might not *have* any output if it is rejected by the
> implementation for containing undefined behavior etc.
This was what I said in my previous posting as quoted above.
> There are essentially three kinds of program behavior:
> (1) specified.
> (2) unspecified but "stable".
> (3) undefined.
> A s.c. program contains no instances of (3).
> A s.c. program can contain instances of (2), but its output
> shall not depend on which of the allowed choices the
> implementation has made for each such instance (except for
> locale-specific behavior, which we intentionally allow to
> affect the output as a special kludge to encourage use of
> locales).
Thanks for the answer.
Jun Woong
"Dan Pop" <Dan...@cern.ch> wrote in message news:bdh74o$m55$1...@sunnews.cern.ch...
It seems that some misunderstanding is in existence here even if both
of you are saying the same and correct thing.
Jun Woong
[...]
>
> But the paragraph in question effectively gives status of strictly
> conforming program to a certain class of conforming programs,
After reading most of relevant committee documents for the wording in
question, I concluded that your interpretation is right and intended.
Thanks.
Jun Woong
"Jun Woong" <myco...@hanmail.net> wrote in message news:94f0654c.03062...@posting.google.com...
> Dan...@cern.ch (Dan Pop) wrote in message news:<bcpfne$5t4$2...@sunnews.cern.ch>...
> [...]
> >
> > But the paragraph in question effectively gives status of strictly
> > conforming program to a certain class of conforming programs,
>
> After reading most of relevant committee documents for the wording in
> question, I concluded that your interpretation is right and intended.
>
And I also learned that the new paragraph in C99 was wording
improvement for the definition of "unspecified behavior" in C90
to make the committee's intent explicit.
Trewth Seeker
> >> >"Dan Pop" <Dan...@cern.ch> wrote in message news:bc9co3$rjl$4...@sunnews.cern.ch...
> >> >> In <yec4r2w...@king.cts.com> Keith Thompson <k...@cts.com> writes:
> [...]
> >> >> >
> >> >> >Why wouldn't that be covered by the phrase "under particular control
> >> >> >options"? As I read it, 3.12 states pretty clearly that a different
> >> >> >set of control options implies a different implementation.
> >
> >Yes.
> >
> >> >> Then, the implementation would have to provide a different document of
> >> >> conformance for each option that doesn't render it non-conforming, right?
> >> >
> >> >You mean "one document per one implementation?"
> >>
> >> Yes. Well, this is actually what the standard requires.
> >
> >The standard requires that, for each implementation, there exists a document
> >that defines the implementation-defined behaviour of that implementation.
> >It does not say that all such documents must be distinct. If a vendor
> >provides a single document that contains some text that is conditional on
> >which of their implementations was selected, that is a perfectly reasonable
> >way of meeting the requirement.
>
> Agreed. But it's still, logically, two different documents (one applying
> to one implementation, the other applying to the other), even if,
> physically, it is a single document.
Which you falsely claimed no implementation provides. You lose.
> OTOH, such documents don't contain conditional parts related to options
> that don't alter the compiler's behaviour, from the standard's point of
> view (e.g. enable additional warnings). Which was actually my point.
Your point seems to have been sophistry. The issue was whether
alternative libraries constitute separate implementations, and
3.12 makes it quite clear that they do.