Atomic statements execute more than once inside a thread

[juanpolotto]

Hi.
I'm write a "passthru" application which is reading from one socket
and writing to a pool of outcoming sockets. From time to time I have
date duplicated in the socket and when I debug the function below,
using step by step, I find that printf("LINE 1\n"); executes more than
once every time I hit F10 (Visual C++). I never saw something like
that.
Very weird!!!!!!!!!!!

unsigned __stdcall inWriteIncomingSocket(void* data) {
cMySocket *IncomingSocket;
cMySocket *OneSocket;
unsigned char chTCPBuffer[1024];
unsigned int uiTCPBufferSize;
int inResult;
int i, j;

inWriteToLog("inWriteIncomingSocket", FOREGROUND_RED +
FOREGROUND_BLUE);

IncomingSocket = (cMySocket *)data;


while(1) {
Sleep(SLEEP_TIME2);

inResult = IncomingSocket->hGetSocketHandler();
if(inResult<=0) continue;

//printf("ESCRIBIENDO A INCOMING SOCKET\n");

for(i=0; i<inSocketsPoolSize; i++) {
Sleep(SLEEP_TIME1);
OneSocket = SocketsPool;
if(!OneSocket) continue;

if(OneSocket-

uiCurrentState==SOCKET_STATE_DATA_FOR_CLIENT_AVAILABLE) {

if(OneSocket->bGetTCPBuffer(chTCPBuffer, &uiTCPBufferSize)) {
//printf("PTVC->NAC (SIZE=
%d)--------------------------------------------------\n",
uiTCPBufferSize);
printf("LINE 1\n");
printf("LINE 2\n");
for(j=0; j<uiTCPBufferSize; j++) {
printf("%02X ", chTCPBuffer[j]);
}
printf("\n\n");

if(!IncomingSocket->bSend(chTCPBuffer, uiTCPBufferSize)) {
OneSocket->vdForceDisconnect();
}



}

OneSocket->uiCurrentState = SOCKET_STATE_SENDING_RECEIVING;

//IncomingSocket->bSend();
}

}


}

}

 

[Walter Roberson]

I'm write a "passthru" application which is reading from one socket
and writing to a pool of outcoming sockets. From time to time I have
date duplicated in the socket and when I debug the function below,
using step by step, I find that printf("LINE 1\n"); executes more than
once every time I hit F10 (Visual C++). I never saw something like

Visual C++ doesn't immediately sound like a C compiler. Are you
sure you have the right newsgroup? This is the C language newsgroup.

that.
Very weird!!!!!!!!!!!

unsigned __stdcall inWriteIncomingSocket(void* data) {

You have not given us a definition for the macro or type
named "__stdcall" so we cannot tell what that line means.

cMySocket *IncomingSocket;
cMySocket *OneSocket;

You have not defined cMySocket for us.

unsigned char chTCPBuffer[1024];
unsigned int uiTCPBufferSize;
int inResult;
int i, j;

inWriteToLog("inWriteIncomingSocket", FOREGROUND_RED +
FOREGROUND_BLUE);

What is inWriteToLog, and what are FOREGROUND_RED and
FOREGROUND_BLUE ?

IncomingSocket = (cMySocket *)data;

while(1) {
Sleep(SLEEP_TIME2);

What is Sleep, and what is SLEEP_TIME2?

inResult = IncomingSocket->hGetSocketHandler();

We have no idea what IncomingSocket->hGetSocketHandler does.

if(inResult<=0) continue;

//printf("ESCRIBIENDO A INCOMING SOCKET\n");

Ah, // comments. That's C99, not allowed in C90. I don't have any
personal experience with Microsoft C compilers myself, but a fair
number of people have posted here that Microsoft does not have
a functional C99 compiler (or much of one at all), so if your compiler
isn't blowing up on that // comment, then we have a hard time
predicting what it is going to do with any of your code. Non-compliant
compilers have non-compliant behaviour.

for(i=0; i<inSocketsPoolSize; i++) {

What's inSocketsPoolSize?

Sleep(SLEEP_TIME1);

What's SLEEP_TIME1?

OneSocket = SocketsPool;

What's SocketsPool?

if(!OneSocket) continue;

if(OneSocket->uiCurrentState==SOCKET_STATE_DATA_FOR_CLIENT_AVAILABLE) {

No idea what SOCKET_STATE_DATA_FOR_CLIENT_AVAILABLE is either, or
uiCurrentState

//printf("PTVC->NAC (SIZE=%d)--------------------------------------------------\n", uiTCPBufferSize);
printf("LINE 1\n");

Not surprising you have problems with that line: printf() is defined
by the standard C library as being a varadic function, but you have not
defined any prototype for it (by #include <stdio.h>), so the compiler
can misinterpret the arguments, point the the wrong place; printing
the same line twice is well within the bounds of allowed behaviour
when you call upon a varadic function without having a proper prototype.

printf("LINE 2\n");
for(j=0; j<uiTCPBufferSize; j++) {

What's uiTCPBufferSize?

printf("%02X ", chTCPBuffer[j]);
}
printf("\n\n");

if(!IncomingSocket->bSend(chTCPBuffer, uiTCPBufferSize)) {

We don't know anything about bSend() either.

OneSocket->vdForceDisconnect();
}



}

OneSocket->uiCurrentState = SOCKET_STATE_SENDING_RECEIVING;

SOCKET_STATE_SENDING_RECEIVING is undefined as well.

//IncomingSocket->bSend();
}

}


}

}

The code you have have shown us cannot pass compilation in any
conforming compiler without extensions -- it violates too many constraints.

Your Subject: line refers to threads, which are not defined by
standard C, so we cannot give you much assistance if something in
your code is invoking thread behaviour. Which we cannot tell, as
you call upon a number of undefined functions, any one of which
could be invoking magic thread behaviour for all we know.

If you can reproduce the behaviour in standard C, sticking to the
facilities provided by standard C, then we could try to debug the
problem. If you cannot reproduce the behaviour without using
extensions that are outside of C, then that indicates the problem
fundamentally involves interaction with those extensions, and you
should then be asking the provider of those extensions. A microsoft
programming newsgroup perhaps.

 

[jaysome]

Visual C++ doesn't immediately sound like a C compiler. Are you
sure you have the right newsgroup? This is the C language newsgroup.

And gcc doesn't immediately sound like a C compiler (it sounds to me
on first impression that it compiles .cc files, which are generally
considered to be C++ files). From your reasoning, I guess we should
respond unequivocally to those who are using the gcc compiler,
regardless of the context of their question, with:

"gcc doesn't immediately sound like a C compiler. Are you sure you
have the right newsgroup? This is the C language newsgroup."

That sounds pretty abrasive to me.

[snip]

Ah, // comments. That's C99, not allowed in C90. I don't have any
personal experience with Microsoft C compilers myself, but a fair
number of people have posted here that Microsoft does not have
a functional C99 compiler (or much of one at all), so if your compiler
isn't blowing up on that // comment, then we have a hard time
predicting what it is going to do with any of your code. Non-compliant
compilers have non-compliant behaviour.

// foo.c
int main(void)
{
// return success status
return 0;
}

When compiled with VC++ 6.0 SP5, I get:

foo.c(1) : warning C4001: nonstandard extension 'single line comment'
was used
foo.c(4) : warning C4001: nonstandard extension 'single line comment'
was used

When compiled with gcc:

gcc foo.c -o foo

I get:

// no warnings

By your definition, Microsoft VC++ 6.0 has compliant behavior and gcc
does not, assuming of course that "blowing up" equates to issuing a
diagnostic.

Best regards

 

[Keith Thompson]

And gcc doesn't immediately sound like a C compiler (it sounds to me
on first impression that it compiles .cc files, which are generally
considered to be C++ files). From your reasoning, I guess we should
respond unequivocally to those who are using the gcc compiler,
regardless of the context of their question, with:

"gcc doesn't immediately sound like a C compiler. Are you sure you
have the right newsgroup? This is the C language newsgroup."

That sounds pretty abrasive to me.

[...]

There's a big difference. The name "Visual C++" makes it sound
*exactly* like a C++ compiler, not a C compiler. If it also acts as a
C compiler, it's misnamed. There's nothing "abrasive" about assuming
that something with "C++" in its name is a C++ compiler; it's a
mistake, but one that the vendor encourages you to make.

If I'd never heard of "gcc", the name wouldn't lead me to assume that
it's a C++ compiler. If I'd heard of "cc", I'd probably assume that
"gcc" is a C compiler.

 

[Richard Heathfield]

Walter Roberson said:

Visual C++ doesn't immediately sound like a C compiler. Are you
sure you have the right newsgroup? This is the C language newsgroup.

There's pedantry, and then there's pedantry. For the benefit of anyone
who doesn't already know that "Visual C++" includes a C compiler, I
have some earth-shattering news for you. "Visual C++" includes a C
compiler. Yes, the OP was way off-topic, but his use of "Visual C++"
was not the reason why.

<snip>

 

[Walter Roberson]

Walter Roberson said:

There's pedantry, and then there's pedantry. For the benefit of anyone
who doesn't already know that "Visual C++" includes a C compiler, I
have some earth-shattering news for you. "Visual C++" includes a C
compiler.

This is comp.lang.c . I'm not supposed to have to keep track of
all of the compilers from minor C vendors, whose conformance varies
from week to week. The evidence from the code given was that
it was *not* a conforming C compiler that was in use. C with extensions
perhaps.

 

[Default User]

This is comp.lang.c . I'm not supposed to have to keep track of
all of the compilers from minor C vendors, whose conformance varies
from week to week.

So why did you feel moved to comment about a toolset you don't know?

There's no requirement that you reply.

The evidence from the code given was that
it was not a conforming C compiler that was in use. C with extensions
perhaps.

Nonsense. You could easily have mentioned that the topics raised were,
by their nature, off-topic. There was no need for you speculate about
the compiler.



Brian

 

[Tor Rustad]

jaysome wrote:

// foo.c
int main(void)
{
// return success status
return 0;
}

When compiled with VC++ 6.0 SP5, I get:

foo.c(1) : warning C4001: nonstandard extension 'single line comment'
was used
foo.c(4) : warning C4001: nonstandard extension 'single line comment'
was used

When compiled with gcc:

gcc foo.c -o foo

I get:

// no warnings

By your definition, Microsoft VC++ 6.0 has compliant behavior and gcc
does not, assuming of course that "blowing up" equates to issuing a
diagnostic.

Well, in ANSI mode at least my VC++ 6.0 installation do translate:

C:\temp>more test.c
// foo.c
int main(void)
{
// return success status
return 0;
}

C:\temp>cl /Za test.c
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 12.00.8168 for 80x86
Copyright (C) Microsoft Corp 1984-1998. All rights reserved.

test.c
Microsoft (R) Incremental Linker Version 6.00.8168
Copyright (C) Microsoft Corp 1992-1998. All rights reserved.

/out:test.exe
test.obj

while GNU cc don't need high warning level to reject:

$ cat test.c
// foo.c
int main(void)
{
// return success status
return 0;
}
$ gcc -ansi test.c
test.c:1: error: expected identifier or â(â before â/â token

 

[Tor Rustad]

Hi.
I'm write a "passthru" application which is reading from one socket
and writing to a pool of outcoming sockets. From time to time I have
date duplicated in the socket and when I debug the function below,
using step by step, I find that printf("LINE 1\n"); executes more than
once every time I hit F10 (Visual C++). I never saw something like
that.

Windows sockets and threads, are very much off-topic here, you should
post to a WIN32 news group.

unsigned char chTCPBuffer[1024];
unsigned int uiTCPBufferSize;
[...]

if(OneSocket->bGetTCPBuffer(chTCPBuffer, &uiTCPBufferSize)) {

Broken API design, unless the bGetTCPBuffer() function never can "write"
more than 1024 bytes, you have commited the cardinal sin: YABOB.


YABOB - Yet Another Buffer Overflow Bug

 

[Richard Heathfield]

Walter Roberson said:

This is comp.lang.c . I'm not supposed to have to keep track of
all of the compilers from minor C vendors, whose conformance varies
from week to week.

<cough type="splurfleglaargh">
Microsoft, a minor C vendor? I'm no MS cheerleader, as you probably
know, but my keyboard is thanking its guardian angel that I wasn't
drinking coffee when I read that.

The evidence from the code given was that
it was *not* a conforming C compiler that was in use. C with
extensions perhaps.

The code is an entity in its own right, and says nothing about the
conformance of the compiler. I can store the complete works of
Shakespeare in a .c file and hand it to gcc if I like. That doesn't
mean gcc isn't conforming.

 

[Walter Roberson]

Walter Roberson said:

The code is an entity in its own right, and says nothing about the
conformance of the compiler. I can store the complete works of
Shakespeare in a .c file and hand it to gcc if I like. That doesn't
mean gcc isn't conforming.

The OP described execution-time behaviour of the code, which
included __stdcall in a function declarator before the function name.
If that was compiled and linked to the point where the poster was
worried about execution time behaviour, then the compiler was
non-conformant (assuming that the given code was indeed complete;
it is -possible- that __stdcall is #define'd to nothingness in some
missing code... but it seems unlikely.)

The code also included // comments, which are post C89. There have
been quite a few posts indicating that Microsoft does not have
a conforming C99 compiler and is not interested in having one.
If those posts were accurate, then the compiler successfully
compiled code that was not C89 compliant. Compilers are allowed to
have extensions, but once one speculates about the possibility that
the OP compiled in some extension mode of unknown extent, then the
meaning of the program given becomes unanalyzable.

 

[Walter Roberson]

<cough type="splurfleglaargh">
Microsoft, a minor C vendor? I'm no MS cheerleader, as you probably
know, but my keyboard is thanking its guardian angel that I wasn't
drinking coffee when I read that.
</cough>

Microsoft is known as a C++ vendor, a C.Net vendor, a C# vendor,
but as a C vendor??

The "Visual C++ 2005 Features" sheet,
http://msdn2.microsoft.com/en-us/visualc/aa336448.aspx

mentions C exactly once:

Visual C++ 2005 includes the industry-standard Active Template Library
(ATL), the Microsoft Foundation Class (MFC) libraries, and standard
libraries such as the Standard C++ Library, and the C RunTime Library
(CRT), which has been extended to provide security enhanced
alternatives to functions known to pose security issues.

Every other reference on the page implies that the product is C++
not C.

How much of C99 has Microsoft implemented? Are they known to
be in the midst of a Great Leap Forward to get C99 in place?
Or are they indeed a merely a player in the field of standard C
compilers?

 

[Richard Heathfield]

Walter Roberson said:

The OP described execution-time behaviour of the code, which
included __stdcall in a function declarator before the function name.
If that was compiled and linked to the point where the poster was
worried about execution time behaviour, then the compiler was
non-conformant (assuming that the given code was indeed complete;
it is -possible- that __stdcall is #define'd to nothingness in some
missing code... but it seems unlikely.)

On the contrary. The code was incorrect (it contained at least one
syntax error), and the only obligation upon the implementation in such
circumstances is that it issues at least one diagnostic message. If the
implementation responds to the incorrect code by producing an
executable program, it is entirely within its rights so to do.

The code also included // comments, which are post C89.

Indeed. That's the "at least one syntax error" I was talking about.

There have
been quite a few posts indicating that Microsoft does not have
a conforming C99 compiler and is not interested in having one.

Neither does GNU have a conforming C99 compiler. Neither do several
other C implementors. Er... so?

If those posts were accurate, then the compiler successfully
compiled code that was not C89 compliant.

Yes, it's allowed to do that, as long as it produces a diagnostic
message for any syntax errors or constraint violations. I haven't
compiled the OP's code, but if I were to do so using my Visual C++
implementation (in C mode, of course), I know for sure that a
diagnostic message would be produced.

Compilers are allowed to
have extensions, but once one speculates about the possibility that
the OP compiled in some extension mode of unknown extent, then the
meaning of the program given becomes unanalyzable.

Sure. No question about that. But that's the program's problem, not the
implementation's.

 

[Richard Heathfield]

Walter Roberson said:

Microsoft is known as a C++ vendor, a C.Net vendor, a C# vendor,
but as a C vendor??

Yeah. I've used Microsoft C on so many client sites that I've lost
count. I would not like to have to defend the position that all these
clients bought their C compilers from Microsoft by accident, never
realising that "Visual C++" could compile C until they took off the
shrinkwrap.

The "Visual C++ 2005 Features" sheet,
http://msdn2.microsoft.com/en-us/visualc/aa336448.aspx

mentions C exactly once:

Visual C++ 2005 includes the industry-standard Active Template
Library (ATL), the Microsoft Foundation Class (MFC) libraries, and
standard libraries such as the Standard C++ Library, and the C
RunTime Library (CRT), which has been extended to provide security
enhanced alternatives to functions known to pose security issues.

Every other reference on the page implies that the product is C++
not C.

Yes, it's true that Microsoft think of C as low-priority. Nevertheless,
they continue to sell a program that compiles C programs using C rules.

How much of C99 has Microsoft implemented?

I have no idea. My own opinion is that C99 is a dead duck, and I'm not
about to criticise Microsoft for agreeing with me. Of course, that
doesn't stop me from criticising them for all kinds of other stuff.

Are they known to
be in the midst of a Great Leap Forward to get C99 in place?
Or are they indeed a merely a player in the field of standard C
compilers?

Merely a player? No, they're a player.

Whenever I need to compile C code under Windows, I always turn to my
trusty Visual Studio. It's the best Windows-based C compiler I have.
For C++, I wouldn't touch it with a bargepole unless I had absolutely
no other choice. From my perspective, Microsoft ships a badly-named but
otherwise excellent C compiler, and the fact that they bundle C++ with
it is of no consequence to me.

 

[Jack Klein]

This is comp.lang.c . I'm not supposed to have to keep track of
all of the compilers from minor C vendors, whose conformance varies
from week to week. The evidence from the code given was that
it was *not* a conforming C compiler that was in use. C with extensions
perhaps.

Just curious, do you know of any C compiler from any vendor that
functions in its most strictly conforming mode by default, that is
with no invocation options? I have never seen one that I recall.

This reminds me of the legal tussle between Microsoft and Sun a decade
and change ago. One of Sun's complaints about Microsoft violating its
Java IP was that Microsoft's compiler accepted Microsoft's extensions,
many of them Windows specific, by default.

But so did Microsoft's C and C++ compilers, and so did (and still do)
Borland's C and C++ compilers. And so did (and so) every version of
gcc I have ever used.

So the question stands, do you know of any C compiler from any source
that uses its most strictly conforming mode by default, and must
actually be invoked with options to allow extensions?

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html

 

[Keith Thompson]

So the question stands, do you know of any C compiler from any source
that uses its most strictly conforming mode by default, and must
actually be invoked with options to allow extensions?

I could construct such a compiler by writing a thin wrapper around,
say, gcc that invokes it with the required options. gcc plus my
wrapper would then constitute a "compiler".

But no, I don't know of any C compiler that works that way "out of the
box".

 

[CBFalconer]

.... snip ...

So the question stands, do you know of any C compiler from any
source that uses its most strictly conforming mode by default,
and must actually be invoked with options to allow extensions?

I don't. But, point of order: Twenty years ago my PascalP was, by
default, restricted to ISO standard Pascal. Extensions were
available. I maintain this is right and proper.

 

[jaysome]

jaysome wrote:



Well, in ANSI mode at least my VC++ 6.0 installation do translate:

C:\temp>more test.c
// foo.c
int main(void)
{
// return success status
return 0;
}

C:\temp>cl /Za test.c
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 12.00.8168 for 80x86
Copyright (C) Microsoft Corp 1984-1998. All rights reserved.

test.c
Microsoft (R) Incremental Linker Version 6.00.8168
Copyright (C) Microsoft Corp 1992-1998. All rights reserved.

/out:test.exe
test.obj

while GNU cc don't need high warning level to reject:

$ cat test.c
// foo.c
int main(void)
{
// return success status
return 0;
}
$ gcc -ansi test.c

gcc *does* require some "high warning level" option to reject the
code. You added the "-ansi" option to do so. Just like I checked the
box labeled "Disable language extensions" in Visual C++ to do so.

If you're going to use Microsoft Visual C++ to compile C code that you
submit to this newsgroup, consider checking the box labeled "Disable
language extensions" in the project settings. And if you're going to
use gcc to compile C code that you submit to this newsgroup, consider
using these options (at a minimum):

gcc -ansi -pedantic -W -Wall

Any warnings you get from either of these compilers should be
addressed before submitting your code. And if there is a warning that
you don't understand, then IMHO you have a right to ask "why" in this
newsgroup; the explanation for such warnings may well further your
knowledge of Standard C, and benefit others as well.

Regards

 

[Tor Rustad]

jaysome wrote:

[...]

gcc *does* require some "high warning level" option to reject the
code. You added the "-ansi" option to do so. Just like I checked the
box labeled "Disable language extensions" in Visual C++ to do so.

No so, in ANSI mode, gcc *rejected* your code at the *default* warning
level.

Furthermore, I showed that Microsoft VC++ 6.0 *translated* your code
without a *warning* when using the /Za switch (at the *default* warning
level):

What point did you make by comparing VC++ in ANSI mode, with gcc in GNU
mode?

If you're going to use Microsoft Visual C++ to compile C code that you
submit to this newsgroup, consider checking the box labeled "Disable
language extensions" in the project settings.

Apparently, you have never used this compiler without the GUI:

cl /help
[...]
/Za disable extensions (implies /Op)

And if you're going to
use gcc to compile C code that you submit to this newsgroup, consider
using these options (at a minimum):

gcc -ansi -pedantic -W -Wall

I prefer stronger checks than this, and usually write lint clean code.

 

[Tor Rustad]

Microsoft is known as a C++ vendor, a C.Net vendor, a C# vendor,
but as a C vendor??

Sure is.

I didn't like the Microsoft .NET IDE much, so I rapidly swapped back to
using the VC++ 6.0 IDE, but many of my co-workers use the .NET IDE
during their embedded C work.

Before testing the code on target, we simulate it under Windows.

Likewise, when writing C code for mainframes, I always try to test as
much as possible under Windows, before swapping to an editor without
syntax coloring, flat file-system and command-line debugger.

How much of C99 has Microsoft implemented? Are they known to
be in the midst of a Great Leap Forward to get C99 in place?

Could very well be. From watching the feedback the VC++ development team
received on their blog, when asking for future wishes, clearly support
for C++0X was requested a lot... and Dinkumware TR1 comes with a C99
library:

http://www.dinkumware.com/tr1.aspx