The C99 standard states:
"In the abstract machine, all expressions are evaluated as specified
by the semantics. An actual implementation need not evaluate part
of an expression if it can deduce that its value is not used and
that no needed side effects are produced (including any caused by
calling a function or accessing a volatile object)."
Does that mean that in the following code, *p does not have to
be evaluated since its side effects are not truly needed?:
extern volatile int *p;
int main(void)
{
*p;
return 0;
}
17  2313  di*************@aol.com wrote On 10/10/05 15:26,: The C99 standard states:
"In the abstract machine, all expressions are evaluated as specified
by the semantics. An actual implementation need not evaluate part
of an expression if it can deduce that its value is not used and
that no needed side effects are produced (including any caused by
calling a function or accessing a volatile object)."
Does that mean that in the following code, *p does not have to
be evaluated since its side effects are not truly needed?:
extern volatile int *p;
int main(void)
{
*p;
return 0;
}
Just the opposite: Since `p' points to an `int' that
is volatile, and since accessing a volatile object is a
side-effect, `*p' must be evaluated -- or at any rate,
the access it implies must be performed. This code might,
for example, be part of a program named IgnoreStatus, whose
entire purpose is to un-wedge a device that's refusing to
do anything until it's been tickled by somebody reading
its memory-mapped status register.
-- Er*********@sun.com
Eric Sosman <er*********@sun.com> writes: di*************@aol.com wrote On 10/10/05 15:26,: The C99 standard states:
"In the abstract machine, all expressions are evaluated as specified
by the semantics. An actual implementation need not evaluate part
of an expression if it can deduce that its value is not used and
that no needed side effects are produced (including any caused by
calling a function or accessing a volatile object)."
Does that mean that in the following code, *p does not have to
be evaluated since its side effects are not truly needed?:
extern volatile int *p;
int main(void)
{
*p;
return 0;
}
Just the opposite: Since `p' points to an `int' that
is volatile, and since accessing a volatile object is a
side-effect, `*p' must be evaluated -- or at any rate,
the access it implies must be performed. This code might,
for example, be part of a program named IgnoreStatus, whose
entire purpose is to un-wedge a device that's refusing to
do anything until it's been tickled by somebody reading
its memory-mapped status register.
Right -- unless the compiler knows somehow that accessing *p doesn't
actually have a "needed side effect". But since the user went out of
his way to declare it volatile, it's unlikely that a compiler would go
to the effort to prove this, especially since it might be wrong.
--
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 On 10/10/05 16:31,: Eric Sosman <er*********@sun.com> writes:
di*************@aol.com wrote On 10/10/05 15:26,:
The C99 standard states:
"In the abstract machine, all expressions are evaluated as specified
by the semantics. An actual implementation need not evaluate part
of an expression if it can deduce that its value is not used and
that no needed side effects are produced (including any caused by
calling a function or accessing a volatile object)."
Does that mean that in the following code, *p does not have to
be evaluated since its side effects are not truly needed?:
extern volatile int *p;
int main(void)
{
*p;
return 0;
}
Just the opposite: Since `p' points to an `int' that
is volatile, and since accessing a volatile object is a
side-effect, `*p' must be evaluated -- or at any rate,
the access it implies must be performed. This code might,
for example, be part of a program named IgnoreStatus, whose
entire purpose is to un-wedge a device that's refusing to
do anything until it's been tickled by somebody reading
its memory-mapped status register.
Right -- unless the compiler knows somehow that accessing *p doesn't
actually have a "needed side effect". But since the user went out of
his way to declare it volatile, it's unlikely that a compiler would go
to the effort to prove this, especially since it might be wrong.
Right (back at'cha). It is, however, rather difficult to
reason about volatile in a portable way. The Standard requires
that all the accesses the abstract machine would make must
actually be made, but since the implementation gets to define
what "access" means ...
-- Er*********@sun.com
"Eric Sosman" <er*********@sun.com> wrote in message
news:di**********@news1brm.Central.Sun.COM...
Keith Thompson wrote On 10/10/05 16:31,: Eric Sosman <er*********@sun.com> writes:
di*************@aol.com wrote On 10/10/05 15:26,:
The C99 standard states:
"In the abstract machine, all expressions are evaluated as specified
by the semantics. An actual implementation need not evaluate part
of an expression if it can deduce that its value is not used and
that no needed side effects are produced (including any caused by
calling a function or accessing a volatile object)."
Does that mean that in the following code, *p does not have to
be evaluated since its side effects are not truly needed?:
extern volatile int *p;
int main(void)
{
*p;
return 0;
}
Just the opposite: Since `p' points to an `int' that
is volatile, and since accessing a volatile object is a
side-effect, `*p' must be evaluated -- or at any rate,
the access it implies must be performed. This code might,
for example, be part of a program named IgnoreStatus, whose
entire purpose is to un-wedge a device that's refusing to
do anything until it's been tickled by somebody reading
its memory-mapped status register.
Right -- unless the compiler knows somehow that accessing *p doesn't
actually have a "needed side effect". But since the user went out of
his way to declare it volatile, it's unlikely that a compiler would go
to the effort to prove this, especially since it might be wrong.
Right (back at'cha). It is, however, rather difficult to
reason about volatile in a portable way. The Standard requires
that all the accesses the abstract machine would make must
actually be made, but since the implementation gets to define
what "access" means ...
We do a lot of embedded C code so we test compiliers on how they handle
volatile data types. Some of the test code we use is so abreviated as to
have no real functionality other than to test the code generator.
One compiler we tested claims to conform with ISO C but has a somewhat
nonconformist way of working with volatile data types.
Specifically:
int volatile a;
void test1(void)
{
a = a + 0;
}
void test2(void)
{
a += 0;
}
The code produced by function test1 was correct.
The variable 'a' was read then written.
The code produced by function test2 was incorrect.
The variable 'a' was read but not written.
When we suggested that the code for test2 did not conform we were told the
expression has only one sequence point and that the generated code was
correct.
We did not use that compiler.
Not because there was not a way to work around this particular issue but
because there was now way to know how many more of these kinds of things may
be lurking within their code generator.
Keyser Soze wrote:
<snip>
We do a lot of embedded C code so we test compiliers on how they handle
volatile data types. Some of the test code we use is so abreviated as to
have no real functionality other than to test the code generator.
One compiler we tested claims to conform with ISO C but has a somewhat
nonconformist way of working with volatile data types.
Specifically:
int volatile a;
void test1(void)
{
a = a + 0;
}
void test2(void)
{
a += 0;
}
The code produced by function test1 was correct.
The variable 'a' was read then written.
The code produced by function test2 was incorrect.
The variable 'a' was read but not written.
When we suggested that the code for test2 did not conform we were told the
expression has only one sequence point and that the generated code was
correct.
Using compound assignment operators when dealing with
volatile-qualified objects that are "sensitive" to the difference
(usually hardware registers) is a classic no-no. Here's my best
explanation:
C99: 5.1.2.3 Program execution
[#6] The least requirements on a conforming implementation are:
-- At sequence points, volatile objects are stable in the
sense that previous accesses are complete and
subsequent accesses have not yet occurred.
GCC 4.02 Manual:
4 C Implementation-defined behavior
4.10 Qualifiers - When is a Volatile Object Accessed?
[...]
The minimum either standard specifies is that at a
sequence point all previous accesses to volatile objects
have stabilized and no subsequent accesses have occurred.
Thus an implementation is free to reorder and combine
volatile accesses which occur between sequence points,
but cannot do so for accesses across a sequence point.
6.7.3 Type qualifiers
[#6] An object that has volatile-qualified type may be
modified in ways unknown to the implementation or have other
unknown side effects. Therefore any expression referring to
such an object shall be evaluated strictly according to the
rules of the abstract machine [...]
6.5.16.2 Compound assignment
[#3] A compound assignment of the form E1 op= E2 differs
from the simple assignment expression E1 = E1 op (E2) only
in that the lvalue E1 is evaluated only once.
"E1" is evaluated "only once", and implementations are (at least
according to the GCC group's interpretation) "free to reorder and
combine volatile accesses which occur between sequence points". I
believe the compiler's behavior in this case is conforming.
At least that's my interpretation. Dissent or confirmation is welcome.
Personally speaking, I have never used compound assignment to
volatile-qualified types in any device drivers I've ever written.
<snip>
Mark F. Haigh mf*****@sbcglobal.net
"Mark F. Haigh" <mf*****@sbcglobal.net> wrote in message
news:11**********************@g49g2000cwa.googlegr oups.com... Keyser Soze wrote:
<snip>
We do a lot of embedded C code so we test compiliers on how they handle
volatile data types. Some of the test code we use is so abreviated as to
have no real functionality other than to test the code generator.
One compiler we tested claims to conform with ISO C but has a somewhat
nonconformist way of working with volatile data types.
Specifically:
int volatile a;
void test1(void)
{
a = a + 0;
}
void test2(void)
{
a += 0;
}
The code produced by function test1 was correct.
The variable 'a' was read then written.
The code produced by function test2 was incorrect.
The variable 'a' was read but not written.
When we suggested that the code for test2 did not conform we were told
the
expression has only one sequence point and that the generated code was
correct.
Using compound assignment operators when dealing with
volatile-qualified objects that are "sensitive" to the difference
(usually hardware registers) is a classic no-no. Here's my best
explanation:
C99: 5.1.2.3 Program execution
[#6] The least requirements on a conforming implementation are:
-- At sequence points, volatile objects are stable in the
sense that previous accesses are complete and
subsequent accesses have not yet occurred.
GCC 4.02 Manual:
4 C Implementation-defined behavior
4.10 Qualifiers - When is a Volatile Object Accessed?
[...]
The minimum either standard specifies is that at a
sequence point all previous accesses to volatile objects
have stabilized and no subsequent accesses have occurred.
Thus an implementation is free to reorder and combine
volatile accesses which occur between sequence points,
but cannot do so for accesses across a sequence point.
6.7.3 Type qualifiers
[#6] An object that has volatile-qualified type may be
modified in ways unknown to the implementation or have other
unknown side effects. Therefore any expression referring to
such an object shall be evaluated strictly according to the
rules of the abstract machine [...]
6.5.16.2 Compound assignment
[#3] A compound assignment of the form E1 op= E2 differs
from the simple assignment expression E1 = E1 op (E2) only
in that the lvalue E1 is evaluated only once.
"E1" is evaluated "only once", and implementations are (at least
according to the GCC group's interpretation) "free to reorder and
combine volatile accesses which occur between sequence points". I
believe the compiler's behavior in this case is conforming.
At least that's my interpretation. Dissent or confirmation is welcome.
Personally speaking, I have never used compound assignment to
volatile-qualified types in any device drivers I've ever written.
The standard and implementation guides are a little vague and hand wavy on
just exactly what is meant by "evaluated only once" when processing a
compound assignment involving a volatile data type.
--------------------
ansi_iso_iec_9899, Section 6.7.3, footnote:
114) A volatile declaration may be used to describe an object corresponding
to a memory-mapped input/output port or an object accessed by an
asynchronously interrupting function. Actions on objects so declared shall
not be "optimized out" by an implementation or reordered except as permitted
by the rules for evaluating expressions.
--------------------
The syntax of the statement would imply that one read and one write would
always be performed on the volatile lvalue of a compound assignment.
This would seem to require that compound assignments to volatile lvaues have
two sequence points. One at the "read" evaluation of E1 and one at the
"write" operation of E2.
The bottom line here seems to be if you need to use volatile data types to
access hardware you had better take a good look at an example of the
generated code for side affects.
Keyser Soze wrote: "Mark F. Haigh" <mf*****@sbcglobal.net> wrote in message
news:11**********************@g49g2000cwa.googlegr oups.com... Keyser Soze wrote:
<snip>
"E1" is evaluated "only once", and implementations are (at least
according to the GCC group's interpretation) "free to reorder and
combine volatile accesses which occur between sequence points". I
believe the compiler's behavior in this case is conforming.
At least that's my interpretation. Dissent or confirmation is welcome.
Personally speaking, I have never used compound assignment to
volatile-qualified types in any device drivers I've ever written.
The standard and implementation guides are a little vague and hand wavy on
just exactly what is meant by "evaluated only once" when processing a
compound assignment involving a volatile data type.
--------------------
ansi_iso_iec_9899, Section 6.7.3, footnote:
114) A volatile declaration may be used to describe an object corresponding
to a memory-mapped input/output port or an object accessed by an
asynchronously interrupting function. Actions on objects so declared shall
not be "optimized out" by an implementation or reordered except as permitted
by the rules for evaluating expressions.
--------------------
The syntax of the statement would imply that one read and one write would
always be performed on the volatile lvalue of a compound assignment.
This would seem to require that compound assignments to volatile lvaues have
two sequence points. One at the "read" evaluation of E1 and one at the
"write" operation of E2.
Footnotes are not normative: See the C99 Forward:
[#6] [...] In accordance with the
ISO/IEC Directives, Part 3, this foreword, the introduction,
notes, footnotes, and examples are for information only.
The bottom line here seems to be if you need to use volatile data types to
access hardware you had better take a good look at an example of the
generated code for side affects.
Agreed, but using compound assignments to write hardware registers is
never a good idea.
Mark F. Haigh mf*****@sbcglobal.net
Mark F. Haigh wrote On 10/11/05 16:01,:
Footnotes are not normative: See the C99 Forward:
[#6] [...] In accordance with the
ISO/IEC Directives, Part 3, this foreword, the introduction,
notes, footnotes, and examples are for information only.
But the Foreword (not "Forward") is also non-normative!
Why should we believe anything it says? In particular, why
should we believe what it says about footnotes?
(And the reference to ISO/IED directives is within the
non-normative Foreword, so it can't be taken seriously ;-)
-- Er*********@sun.com
Eric Sosman wrote: Mark F. Haigh wrote On 10/11/05 16:01,:
Footnotes are not normative: See the C99 Forward:
[#6] [...] In accordance with the
ISO/IEC Directives, Part 3, this foreword, the introduction,
notes, footnotes, and examples are for information only.
But the Foreword (not "Forward") is also non-normative!
Why should we believe anything it says? In particular, why
should we believe what it says about footnotes?
(And the reference to ISO/IED directives is within the
non-normative Foreword, so it can't be taken seriously ;-)
Nice! How about :
The ISO/IEC Directives, Part 3, section 6.5, classify footnotes to text
as "other informative elements", and as such are not considered to be
normative.
Mark F. Haigh mf*****@sbcglobal.net
Eric Sosman <er*********@sun.com> writes: Mark F. Haigh wrote On 10/11/05 16:01,:
Footnotes are not normative: See the C99 Forward:
[#6] [...] In accordance with the
ISO/IEC Directives, Part 3, this foreword, the introduction,
notes, footnotes, and examples are for information only.
But the Foreword (not "Forward") is also non-normative!
Why should we believe anything it says? In particular, why
should we believe what it says about footnotes?
How do you know that the Foreword is non-normative? You seem to
believe that it is so only on the basis of what the Foreword
says, but that's not a valid source because it is non-normative.
--
Are we recursing yet?
Ben Pfaff wrote: Eric Sosman <er*********@sun.com> writes:
Mark F. Haigh wrote On 10/11/05 16:01,:
Footnotes are not normative: See the C99 Forward:
[#6] [...] In accordance with the
ISO/IEC Directives, Part 3, this foreword, the introduction,
notes, footnotes, and examples are for information only.
But the Foreword (not "Forward") is also non-normative!
Why should we believe anything it says? In particular, why
should we believe what it says about footnotes?
How do you know that the Foreword is non-normative? You seem to
believe that it is so only on the basis of what the Foreword
says, but that's not a valid source because it is non-normative.
Assume the Foreword is normative. Then what the Foreward
says is true, and since the Foreword says the Forward is non-
normative we have a contradiction. Therefore, the Foreword
cannot be normative and must be normative. QED, and you may
stay after class to clean the erasers.
(The Foreword's statement that it itself is non-normative
is not a perfect replica of Eubulides' Paradox; unlike E.P. it
is decidable.)
--
Eric Sosman es*****@acm-dot-org.invalid
Keith Thompson <ks***@mib.org> writes: Eric Sosman <er*********@sun.com> writes: di*************@aol.com wrote On 10/10/05 15:26,: The C99 standard states:
"In the abstract machine, all expressions are evaluated as specified
by the semantics. An actual implementation need not evaluate part
of an expression if it can deduce that its value is not used and
that no needed side effects are produced (including any caused by
calling a function or accessing a volatile object)."
Does that mean that in the following code, *p does not have to
be evaluated since its side effects are not truly needed?:
extern volatile int *p;
int main(void)
{
*p;
return 0;
}
Just the opposite: Since `p' points to an `int' that
is volatile, and since accessing a volatile object is a
side-effect, `*p' must be evaluated -- or at any rate,
the access it implies must be performed. This code might,
for example, be part of a program named IgnoreStatus, whose
entire purpose is to un-wedge a device that's refusing to
do anything until it's been tickled by somebody reading
its memory-mapped status register.
Right -- unless the compiler knows somehow that accessing *p doesn't
actually have a "needed side effect". [snip]
The meaning of volatile implies that no compiler can know. The
expression '*p' must be evaluated by a conforming implementation.
Section 6.7.3 p6.
"Mark F. Haigh" <mf*****@sbcglobal.net> writes: Keyser Soze wrote:
<snip>
We do a lot of embedded C code so we test compiliers on how they handle
volatile data types. Some of the test code we use is so abreviated as to
have no real functionality other than to test the code generator.
One compiler we tested claims to conform with ISO C but has a somewhat
nonconformist way of working with volatile data types.
Specifically:
int volatile a;
void test1(void)
{
a = a + 0;
}
void test2(void)
{
a += 0;
}
The code produced by function test1 was correct.
The variable 'a' was read then written.
The code produced by function test2 was incorrect.
The variable 'a' was read but not written.
When we suggested that the code for test2 did not conform we were told the
expression has only one sequence point and that the generated code was
correct.
Using compound assignment operators when dealing with
volatile-qualified objects that are "sensitive" to the difference
(usually hardware registers) is a classic no-no. Here's my best
explanation:
C99: 5.1.2.3 Program execution
[#6] The least requirements on a conforming implementation are:
-- At sequence points, volatile objects are stable in the
sense that previous accesses are complete and
subsequent accesses have not yet occurred.
GCC 4.02 Manual:
4 C Implementation-defined behavior
4.10 Qualifiers - When is a Volatile Object Accessed?
[...]
The minimum either standard specifies is that at a
sequence point all previous accesses to volatile objects
have stabilized and no subsequent accesses have occurred.
Thus an implementation is free to reorder and combine
volatile accesses which occur between sequence points,
but cannot do so for accesses across a sequence point.
6.7.3 Type qualifiers
[#6] An object that has volatile-qualified type may be
modified in ways unknown to the implementation or have other
unknown side effects. Therefore any expression referring to
such an object shall be evaluated strictly according to the
rules of the abstract machine [...]
6.5.16.2 Compound assignment
[#3] A compound assignment of the form E1 op= E2 differs
from the simple assignment expression E1 = E1 op (E2) only
in that the lvalue E1 is evaluated only once.
"E1" is evaluated "only once", and implementations are (at least
according to the GCC group's interpretation) "free to reorder and
combine volatile accesses which occur between sequence points". I
believe the compiler's behavior in this case is conforming.
At least that's my interpretation. Dissent or confirmation is welcome.
I would read it differently. In particular, when the cited sentence
in 6.5.16.2 p3 says "the lvalue E1 is evaluated only once", that seems
better understood as saying
If E1 is of type T1, then the compound assignment E1 op= E2
means the same as if pE1 = &(E1), *pE1 = *pE1 op (E2)
where pE1 is of type T1*, and not counting that the comma
operator implies an ordering between evaluating &(E1) and
evaluating (E2) that isn't there for (E1) op (E2).
Alternatively,
If E1 is of type T1, then the compound assignment E1 op= E2
means the same as (tE1 = *(pE1 = &(E1)) op (E2), *pE1 = tE1)
where pE1 is of type T1* and tE1 is of type T1 with any type
qualifiers removed.
These interpretations make more sense to me. If they're right, that
means gcc's interpretation is non-conforming. I would guess that
6.5.16.2 p3 is worded as it is because alternative formulations
(such as given above) come out sounding so clumsy.
Ben Pfaff <bl*@cs.stanford.edu> writes: Eric Sosman <er*********@sun.com> writes:
Mark F. Haigh wrote On 10/11/05 16:01,:
Footnotes are not normative: See the C99 Forward:
[#6] [...] In accordance with the
ISO/IEC Directives, Part 3, this foreword, the introduction,
notes, footnotes, and examples are for information only.
But the Foreword (not "Forward") is also non-normative!
Why should we believe anything it says? In particular, why
should we believe what it says about footnotes?
How do you know that the Foreword is non-normative? You seem to
believe that it is so only on the basis of what the Foreword
says, but that's not a valid source because it is non-normative.
It might be illuminating to look at the ISO/IEC Directives, Part 3.
Elements can be non-normative but still a valid source of information,
because 'normative' doesn't mean what one might think it means.
In article <11**********************@g49g2000cwa.googlegroups .com>
Mark F. Haigh <mf*****@sbcglobal.net> wrote: Using compound assignment operators when dealing with
volatile-qualified objects that are "sensitive" to the difference
(usually hardware registers) is a classic no-no. ...
On the other hand, when using hardware that supports read-modify-write
transactions (as on the Unibus for instance), I would *want*:
volatile unsigned short *p;
...
*p = (*p) & ~3;
...
*p &= ~3;
to generate the VAX instructions:
bicw3 (r7),$3,(r7)
and:
bicw2 $3,(r7)
respectively -- they do different things in the hardware.
The C standard cannot require this, and on a load/store architecture
like the SPARC or MIPS, it would be unreasonable even to ask.
There is no such thing as an R/M/W bus cycle on these processors.
One may not always get what one wants; there are always alternative
solutions (such as assembly language functions, callable from C,
or gcc's __asm__ construct in some cases) for situations in which
neither the Standard nor the compiler itself is particularly helpful.
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.
Eric Sosman wrote On 10/11/05 21:19,: [...] Therefore, the Foreword
cannot be normative and must be normative. [...]
^
non-
(I hate when I do that ...)
-- Er*********@sun.com
Chris Torek <no****@torek.net> writes: In article <11**********************@g49g2000cwa.googlegroups .com>
Mark F. Haigh <mf*****@sbcglobal.net> wrote:Using compound assignment operators when dealing with
volatile-qualified objects that are "sensitive" to the difference
(usually hardware registers) is a classic no-no. ...
On the other hand, when using hardware that supports read-modify-write
transactions (as on the Unibus for instance), I would *want*:
volatile unsigned short *p;
...
*p = (*p) & ~3;
...
*p &= ~3;
to generate the VAX instructions:
bicw3 (r7),$3,(r7)
and:
bicw2 $3,(r7)
respectively -- they do different things in the hardware.
Having the generated code do different things for the two cases seems
inconsistent with the semantics stated in 6.5.16.2 p3. Even though
wanting the two cases to have different results is understandable, the
Semantics of compound assignment apparently doesn't allow it. As long
as either form may generate either instruction sequence that's ok;
it's distinguishing the two cases that causes a problem. This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics | |
by: Krhis |
last post by:
A friend of mine gave me a link to these two sites, he wanted to know
the scripts that are used here... but it seems that not even I can
help him. So I am hoping some one else could help us by...
|
by: Miles Davenport |
last post by:
I would like some advice on what Java server-side alternatives their are to
an applet which is a shopping cart application which allows the user to
drag-and-drop individual items into "an order"...
|
by: Tobiah |
last post by:
Ok,
I miss the idiom that my other languages use,
something like:
while( foo = getmore()){
process(foo);
}
|
by: Ramki |
last post by:
Hi,
I want to call a PERL program from MS-DOS batch file.
Following is just an example, the string may inturn have double quote
or single quote.
I can't call with arg1, arg2 etc, as the input...
|
by: Sean McKaharay |
last post by:
I am using the code below and I am getting this error:
"Insufficient state to deserialize the object. More information is needed."
Has anyone seen this? It is working with other dll's but not on a...
| | |
by: R.Z. |
last post by:
i'm using a class from some api that is said to automatically call its
destructor when its out of scope and deallocate memory. i create instances
of this class using "new" operator. do i have to...
|
by: Lauren Wilson |
last post by:
A2K app:
Question: is the flagged line (<<<) below necessary. If that line is
needed, what effect does it have (if any) on the fact that the very
same database is the linked back end db?
...
|
by: Vincent Delporte |
last post by:
Hi
I'm a Python newbie, and would like to rewrite this Perl scrip
to be run with the Asterisk PBX:
http://www.voip-info.org/wiki/view/Asterisk+NetCID
Anyone knows if those lines are...
|
by: 2Barter.net |
last post by:
newsmail@reuters.uk.ed10.net Fwd: Money for New Orleans, AL & GA
Inbox
Reply
Reply to all
Forward
Print
Add 2Barter.net to Contacts list
Delete this message
Report phishing
Show original
|
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: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
| | |
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: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome a new...
|
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: adsilva |
last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
| | |
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 ...
| |
