Hi All,
I am using sprintf and getting starnge output in following case
char temp_rn[12];
memset(temp_rn,'\0',12);
sprintf(temp_rn,"0%s",temp_rn);
the final value in temp_rn is 00
how it is behaving like this, when source string and output string is
same.
66  3042 
Hi gyan
When you are using memeset you are filling temp_rn will NULLs
Thus first character of the string will be a NULL characet or in other
words temp_rn becomes a empty string.
Now when you are using sprintf you are changing the first character of
temp_rn to '0' (zero). Thus at this point temp_rn has value "0" now you
append temp_rm to itself hence it becomes "00"
Hope that clears it
Rohin Koul
gyan wrote:
Hi All,
I am using sprintf and getting starnge output in following case
char temp_rn[12];
memset(temp_rn,'\0',12);
sprintf(temp_rn,"0%s",temp_rn);
the final value in temp_rn is 00
how it is behaving like this, when source string and output string is
same.
gyan <gy********@tcs.comwrote:
Hi All,
I am using sprintf and getting starnge output in following case
char temp_rn[12];
memset(temp_rn,'\0',12);
sprintf(temp_rn,"0%s",temp_rn);
the final value in temp_rn is 00
how it is behaving like this, when source string and output string is
same.
it is behaving undefined
--
:wq
^X^Cy^K^X^C^C^C^C
yeti <ro********@gmail.comwrote:
(Please don't top post.)
gyan wrote:
char temp_rn[12];
memset(temp_rn,'\0',12);
sprintf(temp_rn,"0%s",temp_rn);
When you are using memeset you are filling temp_rn will NULLs
That's "NUL"; NULL is a macro which yields a null pointer constant.
The difference is subtle but non-trivial.
Thus first character of the string will be a NULL characet
That would be correct as "null character" (note capitalization).
Now when you are using sprintf you are changing the first character of
temp_rn to '0' (zero). Thus at this point temp_rn has value "0" now you
append temp_rm to itself hence it becomes "00"
No. Annex J.2 of n869 describes undefined behavior, which includes
"The snprintf, sprintf, sscanf, vsnprintf, vsprintf, mbstowcs,
wcstombs, memcpy, strcpy, strncpy, strcat, strncat, strxfrm, or
strftime function, or any of the functions declared by <wchar.h>
(except where otherwise specified), is used to copy between
overlapping objects."
What OP was trying to do is Wrong, and the Standard allows the
implementation to do *anything*, which includes the behavior OP
noticed.
--
C. Benson Manica | I *should* know what I'm talking about - if I
cbmanica(at)gmail.com | don't, I need to know. Flames welcome.
gyan said:
Hi All,
I am using sprintf and getting starnge output in following case
char temp_rn[12];
memset(temp_rn,'\0',12);
sprintf(temp_rn,"0%s",temp_rn);
the final value in temp_rn is 00
how it is behaving like this, when source string and output string is
same.
Note in particular the last sentence of the following quote from the
Standard:
4.9.6.5 The sprintf function
Synopsis
#include <stdio.h>
int sprintf(char *s, const char *format, ...);
Description
The sprintf function is equivalent to fprintf , except that the
argument s specifies an array into which the generated output is to be
written, rather than to a stream. A null character is written at the
end of the characters written; it is not counted as part of the
returned sum. If copying takes place between objects that overlap,
the behavior is undefined.
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999 http://www.cpax.org.uk
email: rjh at the above domain, - www.
gyan <gy********@tcs.comwrote:
Hi All,
I am using sprintf and getting starnge output in following case
char temp_rn[12];
memset(temp_rn,'\0',12);
sprintf(temp_rn,"0%s",temp_rn);
the final value in temp_rn is 00
how it is behaving like this, when source string and output string is
same.
C99 7.19.6.6-2: "... If copying takes place between objects that
overlap, the behavior is undefined."
--
Ioan - Ciprian Tandau
tandau _at_ freeshell _dot_ org (hope it's not too late)
(... and that it still works...)
Nelu wrote:
gyan <gy********@tcs.comwrote:
Hi All,
I am using sprintf and getting starnge output in following case
char temp_rn[12];
memset(temp_rn,'\0',12);
sprintf(temp_rn,"0%s",temp_rn);
the final value in temp_rn is 00
how it is behaving like this, when source string and output string is
same.
C99 7.19.6.6-2: "... If copying takes place between objects that
overlap, the behavior is undefined."
--
Ioan - Ciprian Tandau
tandau _at_ freeshell _dot_ org (hope it's not too late)
(... and that it still works...)
Yes I agree that standard says that the behaviour is undefined but
leaving it at that won't answer the question.
There still should be an explination for the behaviour. Computers as
yet don't have free will ;-)
"yeti" <ro********@gmail.comwrites:
Nelu wrote:
gyan <gy********@tcs.comwrote:
I am using sprintf and getting starnge output in following case
>
char temp_rn[12];
memset(temp_rn,'\0',12);
sprintf(temp_rn,"0%s",temp_rn);
>
the final value in temp_rn is 00
how it is behaving like this, when source string and output string is
same.
>
C99 7.19.6.6-2: "... If copying takes place between objects that
overlap, the behavior is undefined."
Yes I agree that standard says that the behaviour is undefined but
leaving it at that won't answer the question.
There still should be an explination for the behaviour. Computers as
yet don't have free will ;-)
There is no C answer. The behavior is undefined; the reason for any
particular behavior is going to depend on the implementation, and
possibly on the phase of the moon.
Yes, there's likely to be a specific reason for whatever behavior you
see on a specific system under specific circumstances -- but we can't
guess what that reason might be. The meta-answer: don't worry about
it, just fix the code.
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Keith Thompson wrote:
"yeti" <ro********@gmail.comwrites:
Nelu wrote:
gyan <gy********@tcs.comwrote:
I am using sprintf and getting starnge output in following case
char temp_rn[12];
memset(temp_rn,'\0',12);
sprintf(temp_rn,"0%s",temp_rn);
the final value in temp_rn is 00
how it is behaving like this, when source string and output string is
same.
>
C99 7.19.6.6-2: "... If copying takes place between objects that
overlap, the behavior is undefined."
Yes I agree that standard says that the behaviour is undefined but
leaving it at that won't answer the question.
There still should be an explination for the behaviour. Computers as
yet don't have free will ;-)
There is no C answer. The behavior is undefined; the reason for any
particular behavior is going to depend on the implementation, and
possibly on the phase of the moon.
Yes, there's likely to be a specific reason for whatever behavior you
see on a specific system under specific circumstances -- but we can't
guess what that reason might be. The meta-answer: don't worry about
it, just fix the code.
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Ah I see. Perhaps then universal answer to all the questions would be
"Refer to C standard"
yeti wrote:
Nelu wrote:
gyan <gy********@tcs.comwrote:
Hi All,
>
I am using sprintf and getting starnge output in following case
>
char temp_rn[12];
memset(temp_rn,'\0',12);
sprintf(temp_rn,"0%s",temp_rn);
>
the final value in temp_rn is 00
how it is behaving like this, when source string and output string is
same.
>
C99 7.19.6.6-2: "... If copying takes place between objects that
overlap, the behavior is undefined."
--
Ioan - Ciprian Tandau
tandau _at_ freeshell _dot_ org (hope it's not too late)
(... and that it still works...)
Yes I agree that standard says that the behaviour is undefined but
leaving it at that won't answer the question.
There still should be an explination for the behaviour. Computers as
yet don't have free will ;-)
Of course there's an explanation for the behaviour, and if you really
wanted to, you could find it.
And if you put in the effort, you'd find the explanation for this
particular combination of compiler, libraries and platform. It would
tell you precisely nothing that would be certain to apply to a
different combination.
I've got better things to do with my time.
yeti wrote:
Keith Thompson wrote:
"yeti" <ro********@gmail.comwrites:
Nelu wrote:
C99 7.19.6.6-2: "... If copying takes place between objects that
overlap, the behavior is undefined."
>
Yes I agree that standard says that the behaviour is undefined but
leaving it at that won't answer the question.
There still should be an explination for the behaviour. Computers as
yet don't have free will ;-)
There is no C answer. The behavior is undefined; the reason for any
particular behavior is going to depend on the implementation, and
possibly on the phase of the moon.
Yes, there's likely to be a specific reason for whatever behavior you
see on a specific system under specific circumstances -- but we can't
guess what that reason might be. The meta-answer: don't worry about
it, just fix the code.
Ah I see. Perhaps then universal answer to all the questions would be
"Refer to C standard"
No. Just to questions regarding standard C.
santosh wrote:
yeti wrote:
Keith Thompson wrote:
"yeti" <ro********@gmail.comwrites:
Nelu wrote:
C99 7.19.6.6-2: "... If copying takes place between objects that
overlap, the behavior is undefined."
Yes I agree that standard says that the behaviour is undefined but
leaving it at that won't answer the question.
There still should be an explination for the behaviour. Computers as
yet don't have free will ;-)
>
There is no C answer. The behavior is undefined; the reason for any
particular behavior is going to depend on the implementation, and
possibly on the phase of the moon.
>
Yes, there's likely to be a specific reason for whatever behavior you
see on a specific system under specific circumstances -- but we can't
guess what that reason might be. The meta-answer: don't worry about
it, just fix the code.
Ah I see. Perhaps then universal answer to all the questions would be
"Refer to C standard"
No. Just to questions regarding standard C.
We are talking about question where standard says "I don't know"
yeti wrote:
Nelu wrote:
[...attribution lost...]]
sprintf(temp_rn,"0%s",temp_rn);
>
the final value in temp_rn is 00
how it is behaving like this, when source string and output string is
same.
>
C99 7.19.6.6-2: "... If copying takes place between objects that
overlap, the behavior is undefined."
[...]
Yes I agree that standard says that the behaviour is undefined but
leaving it at that won't answer the question.
The answer is "Because that's the way that particular implementation
does it."
There still should be an explination for the behaviour. Computers as
yet don't have free will ;-)
The standard doesn't preclude that. Computers are even allowed to have
magical powers, and make demons fly from your nose. I'm not aware of
any that actually do that, however.
Regards,
-=Dave
yeti <ro********@gmail.comwrote:
>
Nelu wrote:
>gyan <gy********@tcs.comwrote:
Hi All,
I am using sprintf and getting starnge output in following case
char temp_rn[12];
memset(temp_rn,'\0',12);
sprintf(temp_rn,"0%s",temp_rn);
the final value in temp_rn is 00
how it is behaving like this, when source string and output string is
same.
C99 7.19.6.6-2: "... If copying takes place between objects that
overlap, the behavior is undefined."
<snip signature>
Yes I agree that standard says that the behaviour is undefined but
leaving it at that won't answer the question.
That is the answer to the question. If it said that the behavior was
implementation defined then you could look for an explanation in the
implementation's documentation. In this case it's undefined.
There still should be an explination for the behaviour. Computers as
yet don't have free will ;-)
How do you know? In the worst case scenario, for undefined behavior, they borrow it from the programmer :-).
--
Ioan - Ciprian Tandau
tandau _at_ freeshell _dot_ org (hope it's not too late)
(... and that it still works...)
Dave Hansen wrote:
yeti wrote:
Nelu wrote:
[...attribution lost...]]
sprintf(temp_rn,"0%s",temp_rn);
the final value in temp_rn is 00
how it is behaving like this, when source string and output string is
same.
>
C99 7.19.6.6-2: "... If copying takes place between objects that
overlap, the behavior is undefined."
[...]
Yes I agree that standard says that the behaviour is undefined but
leaving it at that won't answer the question.
The answer is "Because that's the way that particular implementation
does it."
There still should be an explination for the behaviour. Computers as
yet don't have free will ;-)
The standard doesn't preclude that. Computers are even allowed to have
magical powers, and make demons fly from your nose. I'm not aware of
any that actually do that, however.
Sorry, in fact standard requires computers to have deterministic
behaviour. There would be no standard if if demons flew from my nose.
All lines in the standard would shrink to "How am I supposed to know.Go
ask your computer"
>
Regards,
-=Dave
In article <11**********************@v45g2000cwv.googlegroups .com>,
yeti <ro********@gmail.comwrote:
....
>Sorry, in fact standard requires computers to have deterministic
behaviour. There would be no standard if if demons flew from my nose.
All lines in the standard would shrink to "How am I supposed to know.Go
ask your computer"
The dogmatic position is that the behaviour is only required to be
deterministic in those areas covered by the standard. For anything
outside the standard (i.e., the various "XXX defined" categories; e.g.,
"un"defined), the behaviour can, indeed, be random (or seemingly
determined by "free will").
In article <11**********************@v45g2000cwv.googlegroups .com>,
yeti <ro********@gmail.comwrote:
>Dave Hansen wrote:
>The standard doesn't preclude that. Computers are even allowed to have
magical powers, and make demons fly from your nose. I'm not aware of
any that actually do that, however.
>Sorry, in fact standard requires computers to have deterministic
behaviour. There would be no standard if if demons flew from my nose.
Within your own logic: if for a particular code situation, demons
-always- flew from your nose, then that would be deterministic,
and thus within the bounds of what you claim about the Standard.
But your claim that the Standard requires computers to have
deterministic behaviour is doubtful. The ISO C89 Rationale
(not normative) indicates,
Undefined behavior gives the implementor license to not catch
certain program errors that are difficult to diagnose. It also
identifies areas of possible conforming language extension:
the implementor may augment the language by providing a definition
of the officially undefined behavior.
Thus, for any particular "undefined behavior", the implementor could
choose to define the behavior as being non-deterministic, and that
would be within the scope of allowed designs.
Also, if the program does something like overwrites the end of
a local variable, and so doing bashes control information being
used by the implementation, then flow of control could end up
directed to any point in memory, through any -possible- machine
instruction sequence. That instruction sequence could include
invoking a machine-level instruction that was defined
non-deterministically, or even a machine-level instruction that
was not well defined and whose operation turned out to depend upon
random transient voltages. Similar things can happen if function
pointers are abused -- remember the old trick of taking an
array of integers and casting that to a function pointer and invoking
that. If you believe that the Standard actively disallows the
implementation from ever branching into arbitrary code, then we
will be wanting Chapter and Verse (C&V) of the sections of the
Standard that you believe nails down the behaviour.
--
Okay, buzzwords only. Two syllables, tops. -- Laurie Anderson
"yeti" <ro********@gmail.comwrites:
santosh wrote:
yeti wrote:
Keith Thompson wrote:
"yeti" <ro********@gmail.comwrites:
Nelu wrote:
C99 7.19.6.6-2: "... If copying takes place between objects that
overlap, the behavior is undefined."
>
Yes I agree that standard says that the behaviour is undefined but
leaving it at that won't answer the question.
There still should be an explination for the behaviour. Computers as
yet don't have free will ;-)
There is no C answer. The behavior is undefined; the reason for any
particular behavior is going to depend on the implementation, and
possibly on the phase of the moon.
Yes, there's likely to be a specific reason for whatever behavior you
see on a specific system under specific circumstances -- but we can't
guess what that reason might be. The meta-answer: don't worry about
it, just fix the code.
>
Ah I see. Perhaps then universal answer to all the questions would be
"Refer to C standard"
No. Just to questions regarding standard C.
We are talking about question where standard says "I don't know"
And in that case, the correct answer is "I don't know".
What answer other than that did you have in mind?
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Christopher Benson-Manica <at***@ukato.freeshell.orgwrote:
No. Annex J.2 of n869 describes undefined behavior, which includes
"The snprintf, sprintf, sscanf, vsnprintf, vsprintf, mbstowcs,
wcstombs, memcpy, strcpy, strncpy, strcat, strncat, strxfrm, or
strftime function, or any of the functions declared by <wchar.h>
(except where otherwise specified), is used to copy between
overlapping objects."
I should correct myself slightly - Annex J.2 is informative, and
Richard Heathfield's quotation of 4.9.6.5 (which I presume to be
normative) is therefore preferable.
--
C. Benson Manica | I *should* know what I'm talking about - if I
cbmanica(at)gmail.com | don't, I need to know. Flames welcome.
Christopher Benson-Manica <at***@norge.freeshell.orgwrites:
Christopher Benson-Manica <at***@ukato.freeshell.orgwrote:
No. Annex J.2 of n869 describes undefined behavior, which includes
"The snprintf, sprintf, sscanf, vsnprintf, vsprintf, mbstowcs,
wcstombs, memcpy, strcpy, strncpy, strcat, strncat, strxfrm, or
strftime function, or any of the functions declared by <wchar.h>
(except where otherwise specified), is used to copy between
overlapping objects."
I should correct myself slightly - Annex J.2 is informative, and
Richard Heathfield's quotation of 4.9.6.5 (which I presume to be
normative) is therefore preferable.
That would be 4.9.6.5 in the ANSI C89 standard, which corresponds to
7.9.6.5 in the ISO C90 standard, and 7.19.6.6 in the C99 standard.
I've never even seen a copy of the 1989 ANSI C standard; it was
superseded a year later, when ANSI adopted the ISO version of the
standard. In general, sections 4 and 5 of C89 correspond to sections
6 and 7, respectively, of the C90 standard. C99 has the same section
numbers, but subsections differ.
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
yeti wrote:
Dave Hansen wrote:
>yeti wrote:
.... snip ...
>>
>>Yes I agree that standard says that the behaviour is undefined
but leaving it at that won't answer the question.
The answer is "Because that's the way that particular
implementation does it."
>>There still should be an explination for the behaviour.
Computers as yet don't have free will ;-)
The standard doesn't preclude that. Computers are even allowed
to have magical powers, and make demons fly from your nose. I'm
not aware of any that actually do that, however.
Sorry, in fact standard requires computers to have deterministic
behaviour. There would be no standard if if demons flew from my
nose. All lines in the standard would shrink to "How am I supposed
to know.Go ask your computer"
while (!(near_an_insane_bomb_laden_jihadist())) continue;
puts("\aDeadly insult to Mohammed and Allah\a");
exhibits undefined behaviour and free will.
--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>
CBFalconer wrote:
yeti wrote:
Dave Hansen wrote:
yeti wrote:
... snip ...
>
Yes I agree that standard says that the behaviour is undefined
but leaving it at that won't answer the question.
The answer is "Because that's the way that particular
implementation does it."
There still should be an explination for the behaviour.
Computers as yet don't have free will ;-)
The standard doesn't preclude that. Computers are even allowed
to have magical powers, and make demons fly from your nose. I'm
not aware of any that actually do that, however.
Sorry, in fact standard requires computers to have deterministic
behaviour. There would be no standard if if demons flew from my
nose. All lines in the standard would shrink to "How am I supposed
to know.Go ask your computer"
while (!(near_an_insane_bomb_laden_jihadist())) continue;
puts("\aDeadly insult to Mohammed and Allah\a");
exhibits undefined behaviour and free will.
Unfortunately NO. near_an_insane_bomb_laden_jihadist() will never show
unpredictable behaviour.
Computers (as of now) always have predictable behaviour (at least in
theory... or else we would be in trouble.. think of an autopilot).
Ever heard a DFA generate a true randome number ?? I haven't.
"Free will" if it exists at all is yet not suitable enough for
computers.
And perhaps it would be benificial for serinity of this group if we
refrain from remarks or code ( for code is just another way to express)
which would not be taken in good taste by a lot of people. I hope you
understand.
>
--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>
Walter Roberson wrote:
In article <11**********************@v45g2000cwv.googlegroups .com>,
yeti <ro********@gmail.comwrote:
Dave Hansen wrote:
The standard doesn't preclude that. Computers are even allowed to have
magical powers, and make demons fly from your nose. I'm not aware of
any that actually do that, however.
Sorry, in fact standard requires computers to have deterministic
behaviour. There would be no standard if if demons flew from my nose.
Within your own logic: if for a particular code situation, demons
-always- flew from your nose, then that would be deterministic,
and thus within the bounds of what you claim about the Standard.
Ah.. futility of reason. Well my mistake. I thought "flying of demons
from my nose" was rather an unproabable event and if it did happen then
the behaviour would not be deterministic for demons at least may have
mood swings.
>
But your claim that the Standard requires computers to have
deterministic behaviour is doubtful. The ISO C89 Rationale
(not normative) indicates,
Undefined behavior gives the implementor license to not catch
certain program errors that are difficult to diagnose. It also
identifies areas of possible conforming language extension:
the implementor may augment the language by providing a definition
of the officially undefined behavior.
Where do the lines above say about the bahaviour of the computer. It is
basic assumption for all programming languages (including assembly and
machine code) that computers should have perfectly predictable
bahaviour.
Without this asumption you won't be sure what a computer would do after
you gave it an instruction to execute.
And the words ".. by providing a definition of the officially
undefined behavior .." in fact suggests that what is left undefined by
the standard need not be inherently unpredictable, for a particular
implementation can define it anyway.
>
Thus, for any particular "undefined behavior", the implementor could
choose to define the behavior as being non-deterministic, and that
would be within the scope of allowed designs.
Also, if the program does something like overwrites the end of
a local variable, and so doing bashes control information being
used by the implementation, then flow of control could end up
directed to any point in memory, through any -possible- machine
instruction sequence. That instruction sequence could include
invoking a machine-level instruction that was defined
non-deterministically, or even a machine-level instruction that
was not well defined and whose operation turned out to depend upon
random transient voltages. Similar things can happen if function
pointers are abused -- remember the old trick of taking an
array of integers and casting that to a function pointer and invoking
that. If you believe that the Standard actively disallows the
implementation from ever branching into arbitrary code, then we
will be wanting Chapter and Verse (C&V) of the sections of the
Standard that you believe nails down the behaviour.
LoL...behaviour will still be perfectly predictable (if not easy to
predict). If you take the same computer with same intial state and run
the same crap code which messes up the control information then you
WILL end up with the same sequence of instruction and output EVERYTIME.
>
--
Okay, buzzwords only. Two syllables, tops. -- Laurie Anderson
On 17 Jan 2007 23:47:07 -0800, "yeti" <ro********@gmail.comwrote:
>
Walter Roberson wrote:
>In article <11**********************@v45g2000cwv.googlegroups .com>,
yeti <ro********@gmail.comwrote:
>Dave Hansen wrote:
>The standard doesn't preclude that. Computers are even allowed to have
magical powers, and make demons fly from your nose. I'm not aware of
any that actually do that, however.
>Sorry, in fact standard requires computers to have deterministic
behaviour. There would be no standard if if demons flew from my nose.
Within your own logic: if for a particular code situation, demons
-always- flew from your nose, then that would be deterministic,
and thus within the bounds of what you claim about the Standard.
Ah.. futility of reason. Well my mistake. I thought "flying of demons
from my nose" was rather an unproabable event and if it did happen then
the behaviour would not be deterministic for demons at least may have
mood swings.
>>
But your claim that the Standard requires computers to have
deterministic behaviour is doubtful. The ISO C89 Rationale
(not normative) indicates,
Undefined behavior gives the implementor license to not catch
certain program errors that are difficult to diagnose. It also
identifies areas of possible conforming language extension:
the implementor may augment the language by providing a definition
of the officially undefined behavior.
Where do the lines above say about the bahaviour of the computer. It is
basic assumption for all programming languages (including assembly and
machine code) that computers should have perfectly predictable
bahaviour.
Without this asumption you won't be sure what a computer would do after
you gave it an instruction to execute.
And the words ".. by providing a definition of the officially
undefined behavior .." in fact suggests that what is left undefined by
the standard need not be inherently unpredictable, for a particular
implementation can define it anyway.
>>
Thus, for any particular "undefined behavior", the implementor could
choose to define the behavior as being non-deterministic, and that
would be within the scope of allowed designs.
Also, if the program does something like overwrites the end of
a local variable, and so doing bashes control information being
used by the implementation, then flow of control could end up
directed to any point in memory, through any -possible- machine
instruction sequence. That instruction sequence could include
invoking a machine-level instruction that was defined
non-deterministically, or even a machine-level instruction that
was not well defined and whose operation turned out to depend upon
random transient voltages. Similar things can happen if function
pointers are abused -- remember the old trick of taking an
array of integers and casting that to a function pointer and invoking
that. If you believe that the Standard actively disallows the
implementation from ever branching into arbitrary code, then we
will be wanting Chapter and Verse (C&V) of the sections of the
Standard that you believe nails down the behaviour.
LoL...behaviour will still be perfectly predictable (if not easy to
predict). If you take the same computer with same intial state and run
the same crap code which messes up the control information then you
WILL end up with the same sequence of instruction and output EVERYTIME.
I think you're right, but you may be erroneously equating
"predictable" behavior to "undefined" behavior. The C Standard is
perfectly fine with predictable, undefined behavior (it's even
perfectly fine with unpredictable, undefined behavior, which I think
is what you are arguing against, and within the context of your
arguments, as far as I can tell, I agree with you).
Undefined behavior is undefined behavior, and it should be avoided if
you aspire to be a C programmer, especially if you put these kinds of
bullets in your resume:
-- expert at ANSI C
Best Regards
--
jay
>>>>"y" == yeti <ro********@gmail.comwrites:
>exhibits undefined behaviour and free will.
yUnfortunately NO. near_an_insane_bomb_laden_jihadist() will
ynever show unpredictable behaviour. Computers (as of now)
yalways have predictable behaviour (at least in theory... or
yelse we would be in trouble.. think of an autopilot). Ever
yheard a DFA generate a true randome number ?? I haven't. "Free
ywill" if it exists at all is yet not suitable enough for
ycomputers.
You're not understanding what the Standard means by "undefined
behavior." It doesn't mean that *any given* compiler will produce
unpredictable behavior; it means that the behavior of the computer
when it encounters that particular bit of code is defined by the
implementation, and there is no guarantee at all about what the
behavior will be.
For instance, I can know with an absolute certainty what one compiler
will do if I say i = i++ * i++; but that knowledge is limited to that
compiler. Another compiler, written by someone more pedantic and
hostile, might take advantage of flaws in the hardware to make the
computer catch on fire when it encounters that code. Both of these
would be acceptable behavior according to the C standard.
yAnd perhaps it would be benificial for serinity of this group
yif we refrain from remarks or code ( for code is just another
yway to express) which would not be taken in good taste by a lot
yof people. I hope you understand.
It is most beneficial for the serenity of this group for people to not
post as experts when they are demonstrably wrong and then not continue
to post defensive responses when their error is pointed out.
Remaining in good political taste is a distant second.
Charlton
--
Charlton Wilbur cw*****@chromatico.net
Charlton Wilbur <cw*****@chromatico.netwrites:
>>>"y" == yeti <ro********@gmail.comwrites:
>exhibits undefined behaviour and free will.
yUnfortunately NO. near_an_insane_bomb_laden_jihadist() will
ynever show unpredictable behaviour. Computers (as of now)
yalways have predictable behaviour (at least in theory... or
yelse we would be in trouble.. think of an autopilot). Ever
yheard a DFA generate a true randome number ?? I haven't. "Free
ywill" if it exists at all is yet not suitable enough for
ycomputers.
You're not understanding what the Standard means by "undefined
behavior." It doesn't mean that *any given* compiler will produce
unpredictable behavior; it means that the behavior of the computer
when it encounters that particular bit of code is defined by the
implementation, and there is no guarantee at all about what the
behavior will be.
Correct, but the phrase "defined by the implementation" is a bit
problematic. The standard uses the word "defined" to refer to
something that must be documented. There is a class of behavior
called "implementation-defined behavior", defined as
unspecified behavior where each implementation documents how the
choice is made
"Unspecified behavior" is
use of an unspecified value, or other behavior where this
International Standard provides two or more possibilities and
imposes no further requirements on which is chosen in any instance
For completeness, the definition of "undefined behavior" is
behavior, upon use of a nonportable or erroneous program construct
or of erroneous data, for which this International Standard
imposes no requirements
The implementation needn't document what happens, and the behavior
needn't be consistent or even deterministic. You can argue that all
computer behavior must be deterministic on some level, and it may be
so for many systems, but the C standard does not require this. A
computer system might, for example, provide a device that generates
truly random (not pseudo-random) data, and undefined behavior can
legally depend on the output of such a device. (Note that the rand()
function can't use truly random data.) Perhaps more realistically, it
can depend on the content and timing of keyboard input, which can
depend on anything you like.
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
>>>>"KT" == Keith Thompson <ks***@mib.orgwrites:
KTThe implementation needn't document what happens, and the
KTbehavior needn't be consistent or even deterministic.
True; I usually think in terms of programs where the source is
available, and thus the source is a sort of documentation. Obviously
this colors my thinking.
Charlton
--
Charlton Wilbur cw*****@chromatico.net
Charlton Wilbur <cw*****@chromatico.netwrites:
>>>"KT" == Keith Thompson <ks***@mib.orgwrites:
KTThe implementation needn't document what happens, and the
KTbehavior needn't be consistent or even deterministic.
True; I usually think in terms of programs where the source is
available, and thus the source is a sort of documentation. Obviously
this colors my thinking.
Do you mean the source of the implementation (e.g., of the compiler)?
The source of the application won't do you any good in determining how
the program will behave in cases of undefined behavior. (You probably
know that; I just wanted to make sure.)
Incidentally, your non-standard quoting style is ok, but a bit
verbose. You might consider just using attribution lines and ""
prefixes like the rest of us do. Or at least drop the whitspace in
front of the "KT" tags. Thanks.
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Charlton Wilbur <cw*****@chromatico.netwrote:
>>>>>"KT" == Keith Thompson <ks***@mib.orgwrites:
KTThe implementation needn't document what happens, and the
KTbehavior needn't be consistent or even deterministic.
True; I usually think in terms of programs where the source is
available, and thus the source is a sort of documentation. Obviously
this colors my thinking.
I don't think the source will do you any good (or at least not in all
cases). For example free releases memory allocated with malloc, calloc,
realloc. If those functions are just forwarding requests to
the operating system when you free memory that was not allocated with
those 3 functions the behavior may not be dictated by the compiler but
by the operating system.
--
Ioan - Ciprian Tandau
tandau _at_ freeshell _dot_ org (hope it's not too late)
(... and that it still works...)
Nelu <sp*******@gmail.comwrites:
Charlton Wilbur <cw*****@chromatico.netwrote:
>>>>>>"KT" == Keith Thompson <ks***@mib.orgwrites:
KTThe implementation needn't document what happens, and the
KTbehavior needn't be consistent or even deterministic.
True; I usually think in terms of programs where the source is
available, and thus the source is a sort of documentation. Obviously
this colors my thinking.
I don't think the source will do you any good (or at least not in all
cases). For example free releases memory allocated with malloc, calloc,
realloc. If those functions are just forwarding requests to
the operating system when you free memory that was not allocated with
those 3 functions the behavior may not be dictated by the compiler but
by the operating system.
That just means you need source for the operating system.
--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan
Ben Pfaff <bl*@cs.stanford.eduwrote:
Nelu <sp*******@gmail.comwrites:
>Charlton Wilbur <cw*****@chromatico.netwrote:
>>>>>>>"KT" == Keith Thompson <ks***@mib.orgwrites:
KTThe implementation needn't document what happens, and the
KTbehavior needn't be consistent or even deterministic.
True; I usually think in terms of programs where the source is
available, and thus the source is a sort of documentation. Obviously
this colors my thinking.
I don't think the source will do you any good (or at least not in all
cases). For example free releases memory allocated with malloc, calloc,
realloc. If those functions are just forwarding requests to
the operating system when you free memory that was not allocated with
those 3 functions the behavior may not be dictated by the compiler but
by the operating system.
That just means you need source for the operating system.
Right, but I was referring to the source code for the implementation.
--
Ioan - Ciprian Tandau
tandau _at_ freeshell _dot_ org (hope it's not too late)
(... and that it still works...)
In article <11********************@11g2000cwr.googlegroups.co m>,
yeti <ro********@gmail.comwrote:
>LoL...behaviour will still be perfectly predictable (if not easy to
predict). If you take the same computer with same intial state and run
the same crap code which messes up the control information then you
WILL end up with the same sequence of instruction and output EVERYTIME.
You are basically arguing the mechanistic view of the universe --
that if you just knew the state of everything precisely enough, that
you could predict -exactly- what would happen. That view has
been disproven by quantum physics experiments. And basically,
every modern fast computer is a quantum physics experiment -- modern
chip designers put a lot of work into reducing the influence of
random quantum behaviour (except where they -want- random quantum
behaviour.)
You also have a restricted view of what a computer is, and of how
computing is performed. There are, for example, biological computers,
in which starting and ending protein hooks are inserted into vats of
proteins, allowing the answer to self-assemble biologically. And Q-bit
(Quantum bit) based computers are actively being worked on;
unfortunately they aren't particularily stable as yet.
>It is
basic assumption for all programming languages (including assembly and
machine code) that computers should have perfectly predictable
bahaviour.
Without this asumption you won't be sure what a computer would do after
you gave it an instruction to execute.
You are ignoring multiprocessor computers: when you have multiple
processors, the relative order that things happen in becomes
indeterminate, with one run seldom being like the next; nanosecond
differences in interrupts determine which processor gets a shared
resource first, and the happenstance orders *do* propogate into
the problem as a whole.
You are also not taking into account network computers. When
computer X sends a message to computer Y, the timing with which
Y receives the message is variable, and it is trivial to construct
examples in which the timing variations trigger different actions.
Y might not receive the message at all. Y might receive two (or
more) copies of the message. Y might sometimes be able to detect
that something went missing (or is taking the slow boat), but
for some protocols Y won't be able to tell. Y might request
a resend -- that's different behaviour, not predictable by X.
Possibly everything will be straightened out by the time you
get to the application layer, but there are important applications
(such as video broadcasting) in which losses are expected and
a lot of work goes into making the data stream robust "enough"
for use.
And you are not taking into account that some cpus have
(deliberate) random-number generators, and that those random
numbers are important to a variety of activities, including
various kinds of security (or even just making a computer
game less predictable.)
Non-determinism happens in a wide variety of circumstances
in computing, and there are different strategies for dealing
with it, down to chip doping strategies and up to the application
layers.
When the C standard says that something has undefined behaviour and
that the implementation can define that behaviour if it wants, the
standard *does* mean to include the possibility that the implementation
will behave non-deterministically. There is a different kind of
behaviour, "unspecified behavior" if my mind isn't too asleep yet, for
which the standard does not say exactly what happens, but for which the
implementation is not allowed to cause the program to fail. For
undefined behaviour, the results really are subject to change without
notice.
--
"It is important to remember that when it comes to law, computers
never make copies, only human beings make copies. Computers are given
commands, not permission. Only people can be given permission."
-- Brad Templeton
Charlton Wilbur wrote:
>>>"y" == yeti <ro********@gmail.comwrites:
>exhibits undefined behaviour and free will.
yUnfortunately NO. near_an_insane_bomb_laden_jihadist() will
ynever show unpredictable behaviour. Computers (as of now)
yalways have predictable behaviour (at least in theory... or
yelse we would be in trouble.. think of an autopilot). Ever
yheard a DFA generate a true randome number ?? I haven't. "Free
ywill" if it exists at all is yet not suitable enough for
ycomputers.
You're not understanding what the Standard means by "undefined
behavior." It doesn't mean that *any given* compiler will produce
unpredictable behavior; it means that the behavior of the computer
when it encounters that particular bit of code is defined by the
implementation, and there is no guarantee at all about what the
behavior will be.
For instance, I can know with an absolute certainty what one compiler
will do if I say i = i++ * i++; but that knowledge is limited to that
compiler. Another compiler, written by someone more pedantic and
hostile, might take advantage of flaws in the hardware to make the
computer catch on fire when it encounters that code. Both of these
would be acceptable behavior according to the C standard.
Thankyou and I certainly appericiate the pedagogic value of what you
have written. But I'm sorry it doesn't say anything which I don't know.
The whole argument started with people (correctly) saying that
behaviour was left "undefined" in the C standard and I asked a simple
question "should we leave it at that?". Does saying that "C standard
doesn't have an answer" answer the question ?? Some code is behaving in
a particular way and there has to be an explination why it is doing so.
Yes it may vary from one implementation to another. But everywhere it
will have a rational explination. Even if it puts your computer on
fire, there still will be an explination "why" and "how" it did so.
>
yAnd perhaps it would be benificial for serinity of this group
yif we refrain from remarks or code ( for code is just another
yway to express) which would not be taken in good taste by a lot
yof people. I hope you understand.
It is most beneficial for the serenity of this group for people to not
post as experts when they are demonstrably wrong and then not continue
to post defensive responses when their error is pointed out.
Remaining in good political taste is a distant second.
Well I just hoped that you will understand it doesn't matter if you
didn't.
>
Charlton
--
Charlton Wilbur
cw*****@chromatico.net
Walter Roberson wrote:
In article <11********************@11g2000cwr.googlegroups.co m>,
yeti <ro********@gmail.comwrote:
LoL...behaviour will still be perfectly predictable (if not easy to
predict). If you take the same computer with same intial state and run
the same crap code which messes up the control information then you
WILL end up with the same sequence of instruction and output EVERYTIME.
You are basically arguing the mechanistic view of the universe --
that if you just knew the state of everything precisely enough, that
you could predict -exactly- what would happen. That view has
been disproven by quantum physics experiments. And basically,
every modern fast computer is a quantum physics experiment -- modern
chip designers put a lot of work into reducing the influence of
random quantum behaviour (except where they -want- random quantum
behaviour.)
Now why do chip designers put in a lot of efforts to reduce influence
of randome quantum behaviour ??
Perhaps to make things more deterministic and thats what I stated.
>
You also have a restricted view of what a computer is, and of how
computing is performed. There are, for example, biological computers,
in which starting and ending protein hooks are inserted into vats of
proteins, allowing the answer to self-assemble biologically. And Q-bit
(Quantum bit) based computers are actively being worked on;
unfortunately they aren't particularily stable as yet.
It is
basic assumption for all programming languages (including assembly and
machine code) that computers should have perfectly predictable
bahaviour.
Without this asumption you won't be sure what a computer would do after
you gave it an instruction to execute.
You are ignoring multiprocessor computers: when you have multiple
processors, the relative order that things happen in becomes
indeterminate, with one run seldom being like the next; nanosecond
differences in interrupts determine which processor gets a shared
resource first, and the happenstance orders *do* propogate into
the problem as a whole.
Indeterminate possibly is not the right word here.
>
You are also not taking into account network computers. When
computer X sends a message to computer Y, the timing with which
Y receives the message is variable, and it is trivial to construct
examples in which the timing variations trigger different actions.
Y might not receive the message at all. Y might receive two (or
more) copies of the message. Y might sometimes be able to detect
that something went missing (or is taking the slow boat), but
for some protocols Y won't be able to tell. Y might request
a resend -- that's different behaviour, not predictable by X.
Oh I guess then nothing in world is deterministic for everything in
world is composed of quantum particles which inherently have
non-deterministic behaviour. But what I may like to point out is that
all the non-determinism applies at the quantum level and not in the
macro world. Nice thing about nature is that all the randome behaviour
at sub-atomic level sums up into deterministic bahaviour at macro
level.
Possibly everything will be straightened out by the time you
get to the application layer, but there are important applications
(such as video broadcasting) in which losses are expected and
a lot of work goes into making the data stream robust "enough"
for use.
Again why is it "straightened out" ?? isn't it that we want things to
behave deterministically ??
>
And you are not taking into account that some cpus have
(deliberate) random-number generators, and that those random
numbers are important to a variety of activities, including
various kinds of security (or even just making a computer
game less predictable.)
Now why exactly are special randome number generators needed if cup's
themselves behave non-deterministically ??
Well why talk of a "Randome number generator" a human attached to the
computer may do the job as well.
But then this randomeness would be externally generated and not
inherent to the computing device.
We need seperate randome number generators just because computers
themselves are unable to generate randome numbers.
>
Non-determinism happens in a wide variety of circumstances
in computing, and there are different strategies for dealing
with it, down to chip doping strategies and up to the application
layers.
When the C standard says that something has undefined behaviour and
that the implementation can define that behaviour if it wants, the
standard *does* mean to include the possibility that the implementation
will behave non-deterministically. There is a different kind of
behaviour, "unspecified behavior" if my mind isn't too asleep yet, for
which the standard does not say exactly what happens, but for which the
implementation is not allowed to cause the program to fail. For
undefined behaviour, the results really are subject to change without
notice.
--
"It is important to remember that when it comes to law, computers
never make copies, only human beings make copies. Computers are given
commands, not permission. Only people can be given permission."
-- Brad Templeton
>exhibits undefined behaviour and free will.
>
yUnfortunately NO. near_an_insane_bomb_laden_jihadist() will
ynever show unpredictable behaviour. Computers (as of now)
yalways have predictable behaviour (at least in theory... or
yelse we would be in trouble.. think of an autopilot). Ever
yheard a DFA generate a true randome number ?? I haven't. "Free
ywill" if it exists at all is yet not suitable enough for
ycomputers.
You're not understanding what the Standard means by "undefined
behavior." It doesn't mean that *any given* compiler will produce
unpredictable behavior;
Although it *COULD* do exactly that. Some CPUs have hardware
random-number generators that use thermal noise to generate numbers
that, according to quantum theory, are true random numbers. (Intel
put this in some Pentium CPUs). The compiler *could* generate code
to use these random numbers to determine which of many obnoxious
things to do, like it was written:
switch(_PentiumTrueRandomGenerator()) {
case 1: abort(); break;
case 0: break; /* do nothing */
case 2: _ElectrifyKeyboardWith50000Volts(); break;
...
}
>it means that the behavior of the computer
when it encounters that particular bit of code is defined by the
implementation, and there is no guarantee at all about what the
behavior will be.
For instance, I can know with an absolute certainty what one compiler
will do if I say i = i++ * i++; but that knowledge is limited to that
compiler. Another compiler, written by someone more pedantic and
hostile, might take advantage of flaws in the hardware to make the
computer catch on fire when it encounters that code. Both of these
would be acceptable behavior according to the C standard.
Another way of saying this is, no matter what it does, you have
no right to complain about it or try to collect on the warranty.
yAnd perhaps it would be benificial for serinity of this group
yif we refrain from remarks or code ( for code is just another
yway to express) which would not be taken in good taste by a lot
yof people. I hope you understand.
It is most beneficial for the serenity of this group for people to not
post as experts when they are demonstrably wrong and then not continue
to post defensive responses when their error is pointed out.
Remaining in good political taste is a distant second.
Keith Thompson wrote:
Charlton Wilbur <cw*****@chromatico.netwrites:
>>>>"y" == yeti <ro********@gmail.comwrites:
>exhibits undefined behaviour and free will.
yUnfortunately NO. near_an_insane_bomb_laden_jihadist() will
ynever show unpredictable behaviour. Computers (as of now)
yalways have predictable behaviour (at least in theory... or
yelse we would be in trouble.. think of an autopilot). Ever
yheard a DFA generate a true randome number ?? I haven't. "Free
ywill" if it exists at all is yet not suitable enough for
ycomputers.
You're not understanding what the Standard means by "undefined
behavior." It doesn't mean that *any given* compiler will produce
unpredictable behavior; it means that the behavior of the computer
when it encounters that particular bit of code is defined by the
implementation, and there is no guarantee at all about what the
behavior will be.
Correct, but the phrase "defined by the implementation" is a bit
problematic. The standard uses the word "defined" to refer to
something that must be documented. There is a class of behavior
called "implementation-defined behavior", defined as
unspecified behavior where each implementation documents how the
choice is made
"Unspecified behavior" is
use of an unspecified value, or other behavior where this
International Standard provides two or more possibilities and
imposes no further requirements on which is chosen in any instance
For completeness, the definition of "undefined behavior" is
behavior, upon use of a nonportable or erroneous program construct
or of erroneous data, for which this International Standard
imposes no requirements
The implementation needn't document what happens, and the behavior
needn't be consistent or even deterministic. You can argue that all
computer behavior must be deterministic on some level, and it may be
so for many systems, but the C standard does not require this. A
computer system might, for example, provide a device that generates
truly random (not pseudo-random) data, and undefined behavior can
legally depend on the output of such a device. (Note that the rand()
function can't use truly random data.) Perhaps more realistically, it
can depend on the content and timing of keyboard input, which can
depend on anything you like.
A randome number generator or a human sitting in front are both
external entities.
And if at all the implementation makes use of the randome numbers
generated either by the human or a randome number generator, there
still would be an explination, taking into account that a randome
number has been used.
Now I do understand that C standard may not ( for the behaviour left
"undefined") say anything about what will happen at runtime, but that
doesn't mean that we can't explain the runtime behaviour of the
program.
>
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
"yeti" <ro********@gmail.comwrote:
Charlton Wilbur wrote:
>>>>"y" == yeti <ro********@gmail.comwrites:
>exhibits undefined behaviour and free will.
yUnfortunately NO. near_an_insane_bomb_laden_jihadist() will
ynever show unpredictable behaviour. Computers (as of now)
yalways have predictable behaviour (at least in theory... or
yelse we would be in trouble.. think of an autopilot). Ever
yheard a DFA generate a true randome number ?? I haven't. "Free
ywill" if it exists at all is yet not suitable enough for
ycomputers.
You're not understanding what the Standard means by "undefined
behavior." It doesn't mean that *any given* compiler will produce
unpredictable behavior; it means that the behavior of the computer
when it encounters that particular bit of code is defined by the
implementation, and there is no guarantee at all about what the
behavior will be.
For instance, I can know with an absolute certainty what one compiler
will do if I say i = i++ * i++; but that knowledge is limited to that
compiler. Another compiler, written by someone more pedantic and
hostile, might take advantage of flaws in the hardware to make the
computer catch on fire when it encounters that code. Both of these
would be acceptable behavior according to the C standard.
Thankyou and I certainly appericiate the pedagogic value of what you
have written. But I'm sorry it doesn't say anything which I don't know.
It clearly states something you may know in theory, but obviously don't
really understand, though.
The whole argument started with people (correctly) saying that
behaviour was left "undefined" in the C standard and I asked a simple
question "should we leave it at that?".
Yes.
Does saying that "C standard doesn't have an answer" answer the question ??
Yes.
Some code is behaving in a particular way and there has to be an
explination why it is doing so.
No. There doesn't even have to be an expl_a_nation.
Yes it may vary from one implementation to another. But everywhere it
will have a rational explination.
No.
Really. You're just fundamentally mistaken on this issue. I know that's
hard to grasp, but that's no reason to be stubborn in the face of better
experts than you or me.
Richard
Gordon Burditt wrote:
>exhibits undefined behaviour and free will.
yUnfortunately NO. near_an_insane_bomb_laden_jihadist() will
ynever show unpredictable behaviour. Computers (as of now)
yalways have predictable behaviour (at least in theory... or
yelse we would be in trouble.. think of an autopilot). Ever
yheard a DFA generate a true randome number ?? I haven't. "Free
ywill" if it exists at all is yet not suitable enough for
ycomputers.
You're not understanding what the Standard means by "undefined
behavior." It doesn't mean that *any given* compiler will produce
unpredictable behavior;
Although it *COULD* do exactly that. Some CPUs have hardware
random-number generators that use thermal noise to generate numbers
that, according to quantum theory, are true random numbers. (Intel
put this in some Pentium CPUs). The compiler *could* generate code
to use these random numbers to determine which of many obnoxious
things to do, like it was written:
switch(_PentiumTrueRandomGenerator()) {
case 1: abort(); break;
case 0: break; /* do nothing */
case 2: _ElectrifyKeyboardWith50000Volts(); break;
...
}
it means that the behavior of the computer
when it encounters that particular bit of code is defined by the
implementation, and there is no guarantee at all about what the
behavior will be.
For instance, I can know with an absolute certainty what one compiler
will do if I say i = i++ * i++; but that knowledge is limited to that
compiler. Another compiler, written by someone more pedantic and
hostile, might take advantage of flaws in the hardware to make the
computer catch on fire when it encounters that code. Both of these
would be acceptable behavior according to the C standard.
Another way of saying this is, no matter what it does, you have
no right to complain about it or try to collect on the warranty.
Certainly. But I am not complaining. I am just seeking a explination
for the behaviour. And the explination can be simple that "behaviour is
governed by the hardware randome number generator"
>
yAnd perhaps it would be benificial for serinity of this group
yif we refrain from remarks or code ( for code is just another
yway to express) which would not be taken in good taste by a lot
yof people. I hope you understand.
It is most beneficial for the serenity of this group for people to not
post as experts when they are demonstrably wrong and then not continue
to post defensive responses when their error is pointed out.
Remaining in good political taste is a distant second.
Richard Bos wrote:
"yeti" <ro********@gmail.comwrote:
Charlton Wilbur wrote:
>>>"y" == yeti <ro********@gmail.comwrites:
>exhibits undefined behaviour and free will.
>
yUnfortunately NO. near_an_insane_bomb_laden_jihadist() will
ynever show unpredictable behaviour. Computers (as of now)
yalways have predictable behaviour (at least in theory... or
yelse we would be in trouble.. think of an autopilot). Ever
yheard a DFA generate a true randome number ?? I haven't. "Free
ywill" if it exists at all is yet not suitable enough for
ycomputers.
>
You're not understanding what the Standard means by "undefined
behavior." It doesn't mean that *any given* compiler will produce
unpredictable behavior; it means that the behavior of the computer
when it encounters that particular bit of code is defined by the
implementation, and there is no guarantee at all about what the
behavior will be.
>
For instance, I can know with an absolute certainty what one compiler
will do if I say i = i++ * i++; but that knowledge is limited to that
compiler. Another compiler, written by someone more pedantic and
hostile, might take advantage of flaws in the hardware to make the
computer catch on fire when it encounters that code. Both of these
would be acceptable behavior according to the C standard.
Thankyou and I certainly appericiate the pedagogic value of what you
have written. But I'm sorry it doesn't say anything which I don't know.
It clearly states something you may know in theory, but obviously don't
really understand, though.
The whole argument started with people (correctly) saying that
behaviour was left "undefined" in the C standard and I asked a simple
question "should we leave it at that?".
Yes.
Does saying that "C standard doesn't have an answer" answer the question ??
Yes.
Some code is behaving in a particular way and there has to be an
explination why it is doing so.
No. There doesn't even have to be an expl_a_nation.
Yes there has to be, maybe not required by C standard but required by
common sense.
>
Yes it may vary from one implementation to another. But everywhere it
will have a rational explination.
No.
Really. You're just fundamentally mistaken on this issue. I know that's
hard to grasp, but that's no reason to be stubborn in the face of better
experts than you or me.
1. I do accept that C standard leaves the behaviour (refer to first
post) undefined.
2. I am arguing that there has to be a rational explanation for all
kinds of behaviour shown by a computer. It doesn't matter if C standard
covers it or not.
3. Due to point 2 all the behaviour (of computers), even those left
undefined( or defined by the implementation) in C standard have a
rational explanation.
4. I am no expert at computing and hence am trying to learn form the
people who are
5. So far none of the posts here have been able to convience me.
PS: I'm sorry if you felt that I am being stubborn, but thats the way
it is.
>
Richard
Nelu <sp*******@gmail.comwrites:
Ben Pfaff <bl*@cs.stanford.eduwrote:
Nelu <sp*******@gmail.comwrites:
Charlton Wilbur <cw*****@chromatico.netwrote:
>>"KT" == Keith Thompson <ks***@mib.orgwrites:
KTThe implementation needn't document what happens, and the
KTbehavior needn't be consistent or even deterministic.
True; I usually think in terms of programs where the source is
available, and thus the source is a sort of documentation. Obviously
this colors my thinking.
I don't think the source will do you any good (or at least not in all
cases). For example free releases memory allocated with malloc, calloc,
realloc. If those functions are just forwarding requests to
the operating system when you free memory that was not allocated with
those 3 functions the behavior may not be dictated by the compiler but
by the operating system.
That just means you need source for the operating system.
Right, but I was referring to the source code for the implementation.
The standard's definition of "implementation" is (C99 3.12):
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"
If the OS "supports execution of functions", it's part of the
implementation.
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
"yeti" <ro********@gmail.comwrites:
[...]
1. I do accept that C standard leaves the behaviour (refer to first
post) undefined.
2. I am arguing that there has to be a rational explanation for all
kinds of behaviour shown by a computer. It doesn't matter if C standard
covers it or not.
[...]
There may be a rational explanation. That doesn't mean the behavior
is necessarily deterministic.
Digital computer hardware is *intended* to be deterministic, but it's
built out of real-world matter, which is ultimately made up of
subatomic particles that, according to quantum theory, exhibit
genuinely nondeterministic behavior. Nothing in the C standard says
or implies that these nondeterministic phenomena cannot affect the
behavior of a C program.
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Keith Thompson wrote:
"yeti" <ro********@gmail.comwrites:
[...]
1. I do accept that C standard leaves the behaviour (refer to first
post) undefined.
2. I am arguing that there has to be a rational explanation for all
kinds of behaviour shown by a computer. It doesn't matter if C standard
covers it or not.
[...]
There may be a rational explanation. That doesn't mean the behavior
is necessarily deterministic.
Digital computer hardware is *intended* to be deterministic, but it's
built out of real-world matter, which is ultimately made up of
subatomic particles that, according to quantum theory, exhibit
genuinely nondeterministic behavior.
Does this mean that a *digital* computer can sow non-deterministic
behaviour even for the programs which standard expects to behave in a
particular fashion. for example
take the statement
int i =0;
I guess standard doesn't cast any doubt over the fact that "i" will be
assigned zero as a value. But it may happen in practise (probably due a
glitch in hardware) that "i" may get some non-zero value ( assuming
that computers are made up of real world matter and those effects can
effect the behaviour C program ). Would then the behaviour of the
statement int i=0 be implementation defined??
>Nothing in the C standard says
or implies that these nondeterministic phenomena cannot affect the
behavior of a C program.
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
yeti wrote:
>
Keith Thompson wrote:
>"yeti" <ro********@gmail.comwrites:
[...]
1. I do accept that C standard leaves the behaviour (refer to first
post) undefined.
2. I am arguing that there has to be a rational explanation for all
kinds of behaviour shown by a computer. It doesn't matter if C standard
covers it or not.
Nothing stops an implementation having access to genuine non-deterministic
behaviour [1] (or even physically impossible behaviour [2]), so long
as that doesn't leak through into the defined behaviours.
More practically, nothing stops an implementation being /deterministic/
but /unpredictable/, by virtue of us not having access to the entire
changing machine state. Suppose some piece of behaviour depends on
the state of an IO register that depends on some checksum of the last
block read from some disk attached to the machine. To reproduce some
piece of undefined behaviour would mean having to read /that/ disc
block at the right moment. Good luck.
take the statement
int i =0;
I guess standard doesn't cast any doubt over the fact that "i" will be
assigned zero as a value. But it may happen in practise (probably due a
glitch in hardware) that "i" may get some non-zero value ( assuming
that computers are made up of real world matter and those effects can
effect the behaviour C program ). Would then the behaviour of the
statement int i=0 be implementation defined??
The implementation would be non-conformant.
[1] Assuming it exists (via QM, for example).
[2] The C standard doesn't require implementations to conform to
what we "know" about physics, so an imaginary implementation
can be conformant /and/ have demons fly out of the user's
nose [3].
[3] And what evidence do you have that /you're/ not imaginary,
perhaps a simulation running on an advanced-by-our-puny-
standards machine?
--
Chris "hence, /electric/ hedgehog" Dollin
"Who do you serve, and who do you trust?" /Crusade/
Chris Dollin wrote:
yeti wrote:
Keith Thompson wrote:
"yeti" <ro********@gmail.comwrites:
[...]
1. I do accept that C standard leaves the behaviour (refer to first
post) undefined.
2. I am arguing that there has to be a rational explanation for all
kinds of behaviour shown by a computer. It doesn't matter if C standard
covers it or not.
Nothing stops an implementation having access to genuine non-deterministic
behaviour [1] (or even physically impossible behaviour [2]), so long
as that doesn't leak through into the defined behaviours.
More practically, nothing stops an implementation being /deterministic/
but /unpredictable/, by virtue of us not having access to the entire
changing machine state. Suppose some piece of behaviour depends on
the state of an IO register that depends on some checksum of the last
block read from some disk attached to the machine. To reproduce some
piece of undefined behaviour would mean having to read /that/ disc
block at the right moment. Good luck.
take the statement
int i =0;
I guess standard doesn't cast any doubt over the fact that "i" will be
assigned zero as a value. But it may happen in practise (probably due a
glitch in hardware) that "i" may get some non-zero value ( assuming
that computers are made up of real world matter and those effects can
effect the behaviour C program ). Would then the behaviour of the
statement int i=0 be implementation defined??
The implementation would be non-conformant.
Thats what I am saying. Standard does want machine to behave as it
expects (and hence deterministic) and if implementation doesn't behave
in deterministic way (way predefined by standard) all the time then it
would become non-conformant.
>
[1] Assuming it exists (via QM, for example).
[2] The C standard doesn't require implementations to conform to
what we "know" about physics, so an imaginary implementation
can be conformant /and/ have demons fly out of the user's
nose [3].
[3] And what evidence do you have that /you're/ not imaginary,
perhaps a simulation running on an advanced-by-our-puny-
standards machine?
Damn!!..I have passed the Turing test.
>
--
Chris "hence, /electric/ hedgehog" Dollin
"Who do you serve, and who do you trust?" /Crusade/
yeti wrote:
Chris Dollin wrote:
>yeti wrote:
take the statement
int i =0;
I guess standard doesn't cast any doubt over the fact that "i" will be
assigned zero as a value. But it may happen in practise (probably due a
glitch in hardware) that "i" may get some non-zero value ( assuming
that computers are made up of real world matter and those effects can
effect the behaviour C program ). Would then the behaviour of the
statement int i=0 be implementation defined??
The implementation would be non-conformant.
Thats what I am saying. Standard does want machine to behave as it
expects (and hence deterministic) and if implementation doesn't behave
in deterministic way (way predefined by standard) all the time then it
would become non-conformant.
No. An implementations is free to become non-deterministic once it
has undefined behaviour. If your code contains:
int i = 0, j = 0; j = j++; fprintf( "i = %d, j = %d\n", i, j );
the value of `j` and the subsequent behaviour can be as non-deterministic
as the implementation can manage. The value printed for `j` is
arbitrary, the value printed for `i` likewise, and indeed nothing
need be printed, or Fermat's missing proof, whatever, without
the implementation thereby being non-conforming.
Usually this is a Bad Thing, but I offer it as a tip to desperate
mathematical historians. You never know your luck.
--
Chris "electric hedgehog" Dollin
"We did not have time to find out everything we wanted to know."
- James Blish, /A Clash of Cymbals/
"yeti" <ro********@gmail.comwrote:
Richard Bos wrote:
"yeti" <ro********@gmail.comwrote:
The whole argument started with people (correctly) saying that
behaviour was left "undefined" in the C standard and I asked a simple
question "should we leave it at that?".
Yes.
Does saying that "C standard doesn't have an answer" answer the question ??
Yes.
Some code is behaving in a particular way and there has to be an
explination why it is doing so.
No. There doesn't even have to be an expl_a_nation.
Yes there has to be, maybe not required by C standard but required by
common sense.
What is called common sense is frequently neither.
2. I am arguing that there has to be a rational explanation for all
kinds of behaviour shown by a computer. It doesn't matter if C standard
covers it or not.
No, you're arguing something stronger: that there's a consistent,
rational, computable method behind all computerised behaviour. This is
simply untrue. Often, the rational explanation for the way a computer
behaves on erroneous input or code is "that's so broken that it could
depend on keyboard micro timings; you can't expect consistent behaviour
from it". If you cannot accept that, you're living in a Platonic dream
world rather than in the real one.
Richard
"yeti" <ro********@gmail.comwrote:
Chris Dollin wrote:
take the statement
int i =0;
I guess standard doesn't cast any doubt over the fact that "i" will be
assigned zero as a value. But it may happen in practise (probably due a
glitch in hardware) that "i" may get some non-zero value ( assuming
that computers are made up of real world matter and those effects can
effect the behaviour C program ). Would then the behaviour of the
statement int i=0 be implementation defined??
The implementation would be non-conformant.
Thats what I am saying. Standard does want machine to behave as it
expects (and hence deterministic)
And this is the whole crux of your error. _On erroneous code_ the
Standard does _not_ have any expectation of how the machine behaves, and
this means that it does _not_ require the result to be deterministic.
Of course _defined_ behaviour must be deterministic, excepting obvious
cases such as code which explicitly depends on, say, the time it takes
to enter a line of input. But the whole point of _undefined_ behaviour
is that the Standard explicitly says: "such code is beyond this
Standard's purview, and we don't care what happens".
and if implementation doesn't behave in deterministic way (way
predefined by standard) all the time then it would become non-conformant.
Completely wrong. Have you even _read_ the Standard?
Richard
Chris Dollin wrote:
yeti wrote:
Keith Thompson wrote:
"yeti" <ro********@gmail.comwrites:
[...]
1. I do accept that C standard leaves the behaviour (refer to first
post) undefined.
2. I am arguing that there has to be a rational explanation for all
kinds of behaviour shown by a computer. It doesn't matter if C standard
covers it or not.
Nothing stops an implementation having access to genuine non-deterministic
behaviour [1] (or even physically impossible behaviour [2]), so long
as that doesn't leak through into the defined behaviours.
I would've thought that non-deterministic behaviour, by it's very
nature, can affect the system's defined behaviour too. In fact, I would
say, it invariably does.
As far as I can see, the C standard doesn't take into account genuinely
random, non-deterministic behaviour. Every behaviour of the abstract
machine falls under one of the three categories of defined,
implementation defined, or undefined.
<snip>
[1] Assuming it exists (via QM, for example).
[2] The C standard doesn't require implementations to conform to
what we "know" about physics, so an imaginary implementation
can be conformant /and/ have demons fly out of the user's
nose [3].
[3] And what evidence do you have that /you're/ not imaginary,
perhaps a simulation running on an advanced-by-our-puny-
standards machine?
Richard Bos wrote:
"yeti" <ro********@gmail.comwrote:
Chris Dollin wrote:
take the statement
int i =0;
I guess standard doesn't cast any doubt over the fact that "i" will be
assigned zero as a value. But it may happen in practise (probably due a
glitch in hardware) that "i" may get some non-zero value ( assuming
that computers are made up of real world matter and those effects can
effect the behaviour C program ). Would then the behaviour of the
statement int i=0 be implementation defined??
>
The implementation would be non-conformant.
Thats what I am saying. Standard does want machine to behave as it
expects (and hence deterministic)
And this is the whole crux of your error. _On erroneous code_ the
Standard does _not_ have any expectation of how the machine behaves, and
this means that it does _not_ require the result to be deterministic.
Of course _defined_ behaviour must be deterministic, excepting obvious
cases such as code which explicitly depends on, say, the time it takes
to enter a line of input. But the whole point of _undefined_ behaviour
is that the Standard explicitly says: "such code is beyond this
Standard's purview, and we don't care what happens".
and if implementation doesn't behave in deterministic way (way
predefined by standard) all the time then it would become non-conformant.
Completely wrong. Have you even _read_ the Standard?
Richard
Ok just for the heck of it "Does C standard require the implementation
to show deterministic behaviour??"
santosh wrote:
Chris Dollin wrote:
>Nothing stops an implementation having access to genuine non-deterministic
behaviour [1] (or even physically impossible behaviour [2]), so long
as that doesn't leak through into the defined behaviours.
I would've thought that non-deterministic behaviour, by it's very
nature, can affect the system's defined behaviour too. In fact, I would
say, it invariably does.
Suppose the function `int flip();` returns 0 or 1 non-deterministically.
Then
flip();
doesn't affect the system's defined behaviour. Neither does
int flop = flip();
[That's the C-visible behaviour, of course.]
But
printf( "flip() returned %d\n", flip() );
/does/ affect the system's defined behaviour -- but no more so than
any other function that returns 0-or-1.
What's more, in:
int j = flip(); j += j;
the non-determinism of `flip` is lost in the undefined behaviour
of the assignment.
As far as I can see, the C standard doesn't take into account genuinely
random, non-deterministic behaviour. Every behaviour of the abstract
machine falls under one of the three categories of defined,
implementation defined, or undefined.
`undefined` covers it. Anything can happen [A]. Yes?
[A] ... in the next half-hour ...
--
Chris "Stingray hedgehog" Dollin
"No-one here is exactly what he appears." G'kar, /Babylon 5/ This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Yodai |
last post by:
Hi all....
I have a little problem that's driving me nuts. I can't seem to make any
sense of it. I have this small webserver that substitutes some data from a
page when finds a substitution...
|
by: huey_jiang |
last post by:
Hi All,
I am trying to figure out a right syntax to convert an integer array
into hex array. sprintf worked for me on doing single integer:
int i, Iarray, n=15;
char buf;
sprintf(buf,...
|
by: jt |
last post by:
I need to produce 1 character array from 3 others. I tried sprintf and it
terminates on the first 0, null, 0x00 it sees in tmp data.
All 3 args print out nice by themselves.
By trying to make...
|
by: jimjim |
last post by:
Hello,
I was wondering about the implications of giving as an argument to sprintf a
different data type from the one specified in the format argument. This type
of question along with some...
|
by: aap |
last post by:
I have the following code
#define MAX 32
struct A
{
char carr;
int iarr;
int i;
};
void main()
{
|
by: Neal Barney |
last post by:
I have a C program which runs on a device using a Zilog Z180
microprocessor. While it can address 1MB of RAM, it can only address
64KB at any given time. And of that only 16KB can be used for...
|
by: Henryk |
last post by:
Hey there,
I have some problems with the following code snippet on a Virtex-4
PowerPC with a GCC based compiler
char chData;
sprintf(&chData, "%+05.0f", -0.038f); --I get "-000" ???...
|
by: krister |
last post by:
Hello,
I'm working in a quite large system that has some limitations. One of
those is that I can't use printf() to get an output on a screen. I'm
forced to use a special function, let's call it...
|
by: Dave |
last post by:
Hi,
In awk I can do this:
var1="x";
temp = sprintf("Variable 1: %s Variable 2: %%s", var1);
# now the value of temp is "Variable 1: x Variable 2: %s"
var2="y";
printf(temp,var2);
|
by: google |
last post by:
Consider the following code:
char str;
char str2;
strcpy(str, "%alfa% %beta% d%100%d %gamma% %delta%");
printf("printf: ");
printf("1%s2", str);
printf("\nsprintf: ");
sprintf(str2, "1%s2",...
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing,...
|
by: conductexam |
last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and...
|
by: TSSRALBI |
last post by:
Hello
I'm a network technician in training and I need your help.
I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs.
The...
|
by: 6302768590 |
last post by:
Hai team
i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated ...
| |
