Horrible Visual C Bug!

Discussion in 'C Programming' started by Oliver Brausch, Jul 20, 2003.

  1. Hello,

    have you ever heard about this MS-visual c compiler bug?
    look at the small prog:


    static int x=0;
    int bit32() {
    return ++x;
    }

    int bit64() {
    return bit32() + (bit32() << 1);
    }

    void main(int argc, char **argv) {
    int i;
    for (i = 0; i < 5; i++) printf("%d. %d\n", i, bit64());
    }


    Ok, the (correct) result is:

    0. 2
    1. 8
    2. 14
    3. 20
    4. 26

    This is what every compiled progam says. Inclusive MSVisualC Compiler
    with Debug options or /Ot fast-option.

    But do not dare to switch to the the /O2 option of MSVisualC Compiler.
    Then once your computer cannot calculate anymore:

    0. 1
    1. 7
    2. 13
    3. 19
    4. 25

    So, up to Microsoft, 0 + 2 = 1 ?????. That's why their OS is so stable....
    Try to increase the "<< 1". It even gets worse.

    Ever seen this? I costed me hours of debugging. Can I
    sue Microsoft for this?

    - Oliver Brausch

    http://home.arcor.de/dreamlike
     
    Oliver Brausch, Jul 20, 2003
    #1
    1. Advertising

  2. "Oliver Brausch" <> wrote in message
    news:...

    > have you ever heard about this MS-visual c compiler bug?
    > look at the small prog:


    It is not a compiler bug. It is a bug in your code.

    > static int x=0;
    > int bit32() {
    > return ++x;
    > }
    >
    > int bit64() {
    > return bit32() + (bit32() << 1);
    > }


    You try to change a variable twice, which is invalid, ie. undefined
    behaviour. Microsoft's compiler is absolutely right.

    > void main(int argc, char **argv) {


    'void main' is illegal. It is *always* 'int main'.

    > int i;
    > for (i = 0; i < 5; i++) printf("%d. %d\n", i, bit64());
    > }


    > This is what every compiled progam says. Inclusive MSVisualC Compiler
    > with Debug options or /Ot fast-option.


    So? Just because many compiled programs say this should be the result
    does not mean that they are right.

    > Ever seen this? I costed me hours of debugging. Can I
    > sue Microsoft for this?


    No, but your boss could fire you for such C code, since it is invalid.
    --
    jb

    (replace y with x if you want to reply by e-mail)
     
    Jakob Bieling, Jul 20, 2003
    #2
    1. Advertising

  3. Oliver Brausch <> scribbled the following
    on comp.lang.c:
    > Hello,


    > have you ever heard about this MS-visual c compiler bug?
    > look at the small prog:



    > static int x=0;
    > int bit32() {
    > return ++x;
    > }


    > int bit64() {
    > return bit32() + (bit32() << 1);


    These two bit32() calls can be evaluated in either order, and the
    implementation doesn't even have to be consistent about it.

    Assume x==0. The first way:
    bit32() + (bit32() << 1) ==
    1 + (bit32() << 1) ==
    1 + (2 << 1) ==
    1 + (4) ==
    5
    The second way:
    bit32() + (1 << 1) ==
    bit32() + (2) ==
    2 + (2) ==
    4

    > }


    > void main(int argc, char **argv) {


    You have induced undefined behaviour by using void main() and lost all
    right to expect any kind of specific behaviour at all.

    > int i;
    > for (i = 0; i < 5; i++) printf("%d. %d\n", i, bit64());
    > }



    > Ok, the (correct) result is:


    Anything. Any result is correct, because of the void main().

    > 0. 2
    > 1. 8
    > 2. 14
    > 3. 20
    > 4. 26


    > This is what every compiled progam says. Inclusive MSVisualC Compiler
    > with Debug options or /Ot fast-option.


    > But do not dare to switch to the the /O2 option of MSVisualC Compiler.
    > Then once your computer cannot calculate anymore:


    > 0. 1
    > 1. 7
    > 2. 13
    > 3. 19
    > 4. 25


    You'll have to read up on undefined behaviour (void main()) and
    unspecified behaviour (bit32() + (bit32() << 1)).

    > So, up to Microsoft, 0 + 2 = 1 ?????. That's why their OS is so stable....
    > Try to increase the "<< 1". It even gets worse.


    > Ever seen this? I costed me hours of debugging. Can I
    > sue Microsoft for this?


    No. It's neither their or C's fault. It's yours.

    --
    /-- Joona Palaste () ---------------------------\
    | Kingpriest of "The Flying Lemon Tree" G++ FR FW+ M- #108 D+ ADA N+++|
    | http://www.helsinki.fi/~palaste W++ B OP+ |
    \----------------------------------------- Finland rules! ------------/
    "There's no business like slow business."
    - Tailgunner
     
    Joona I Palaste, Jul 20, 2003
    #3
  4. Oliver Brausch

    Artie Gold Guest

    Oliver Brausch wrote:
    > Hello,
    >
    > have you ever heard about this MS-visual c compiler bug?


    Nope.

    > look at the small prog:
    >

    OK...
    >
    > static int x=0;
    > int bit32() {
    > return ++x;
    > }
    >
    > int bit64() {
    > return bit32() + (bit32() << 1);
    > }
    >
    > void main(int argc, char **argv) {

    int main(int argc, char **argv) {

    but since you're not making use of the command-line interface,

    int main(void)

    would do quite nicely...

    > int i;
    > for (i = 0; i < 5; i++) printf("%d. %d\n", i, bit64());
    > }
    >
    >
    > Ok, the (correct) result is:
    >
    > 0. 2
    > 1. 8
    > 2. 14
    > 3. 20
    > 4. 26


    Oh, really?

    What if I told you that the correct result could be just about anything,
    including demons flying out of your nose?

    >
    > This is what every compiled progam says. Inclusive MSVisualC Compiler
    > with Debug options or /Ot fast-option.
    >
    > But do not dare to switch to the the /O2 option of MSVisualC Compiler.
    > Then once your computer cannot calculate anymore:
    >
    > 0. 1
    > 1. 7
    > 2. 13
    > 3. 19
    > 4. 25
    >
    > So, up to Microsoft, 0 + 2 = 1 ?????. That's why their OS is so stable....
    > Try to increase the "<< 1". It even gets worse.


    Well, as it turns out, the bug is on the other side of the keyboard in
    this case.[1]

    Please see: http://www.eskimo.com/~scs/C-faq/s3.html for an explanation.

    >
    > Ever seen this? I costed me hours of debugging. Can I
    > sue Microsoft for this?


    Actually, even if it had been their bug (which it isn't) you couldn't --
    read the license.

    HTH,
    --ag

    [1] Not that I would mind a bit had it been _their_ fault.

    --
    Artie Gold -- Austin, Texas
     
    Artie Gold, Jul 20, 2003
    #4
  5. In article <bfej5d$727$01$-online.com>,
    Jakob Bieling <> wrote:
    >"Oliver Brausch" <> wrote in message
    >news:...
    >
    >> static int x=0;
    >> int bit32() {
    >> return ++x;
    >> }
    >>
    >> int bit64() {
    >> return bit32() + (bit32() << 1);
    >> }

    >
    > You try to change a variable twice, which is invalid, ie. undefined
    >behaviour.


    There is a sequence point between the two modifications of x, so
    there's no undefined behavior here. The C language doesn't specify
    which of the two bit32()'s will be invoked first, so there is
    unspecified behavior here. But the first two calls to bit32() are
    going to return 1 and 2 respectively, giving:
    1 + (2 << 1) which is 5, or
    2 + (1 << 1) which is 4
    for the first return of bit64(). (If this were undefined behavior, the
    compiler would be free to do whatever it wanted. That's not the case
    here -- he can reliably assume he'll get 4 or 5 ... he just can't
    assume which one he'll get.)

    (The two outputs he shows (1 and 2 for the first call to bit64())
    aren't possible from the code he posted ... but I assume his test code
    actually had "x++" instead of "++x".)

    -- Brett
     
    Brett Frankenberger, Jul 20, 2003
    #5
  6. Brett Frankenberger <> scribbled the following
    on comp.lang.c:
    > In article <bfej5d$727$01$-online.com>,
    > Jakob Bieling <> wrote:
    >>"Oliver Brausch" <> wrote in message
    >>news:...
    >>> static int x=0;
    >>> int bit32() {
    >>> return ++x;
    >>> }
    >>>
    >>> int bit64() {
    >>> return bit32() + (bit32() << 1);
    >>> }

    >>
    >> You try to change a variable twice, which is invalid, ie. undefined
    >>behaviour.


    > There is a sequence point between the two modifications of x, so
    > there's no undefined behavior here. The C language doesn't specify
    > which of the two bit32()'s will be invoked first, so there is
    > unspecified behavior here. But the first two calls to bit32() are
    > going to return 1 and 2 respectively, giving:
    > 1 + (2 << 1) which is 5, or
    > 2 + (1 << 1) which is 4
    > for the first return of bit64(). (If this were undefined behavior, the
    > compiler would be free to do whatever it wanted. That's not the case
    > here -- he can reliably assume he'll get 4 or 5 ... he just can't
    > assume which one he'll get.)


    > (The two outputs he shows (1 and 2 for the first call to bit64())
    > aren't possible from the code he posted ... but I assume his test code
    > actually had "x++" instead of "++x".)


    Actually, yes they are. He has undefined behaviour - void main(). 1 and
    2 are as legal outputs as 4 and 5, and so is "your mother was a hamster
    and your father smelt of elderberries".

    --
    /-- Joona Palaste () ---------------------------\
    | Kingpriest of "The Flying Lemon Tree" G++ FR FW+ M- #108 D+ ADA N+++|
    | http://www.helsinki.fi/~palaste W++ B OP+ |
    \----------------------------------------- Finland rules! ------------/
    "Life without ostriches is like coffee with milk."
    - Mika P. Nieminen
     
    Joona I Palaste, Jul 20, 2003
    #6
  7. In article <bfelbt$oeu$>,
    Joona I Palaste <> wrote:
    >Brett Frankenberger <> scribbled the following
    >on comp.lang.c:
    >> In article <bfej5d$727$01$-online.com>,
    >> Jakob Bieling <> wrote:
    >>>"Oliver Brausch" <> wrote in message
    >>>news:...
    >>>> static int x=0;
    >>>> int bit32() {
    >>>> return ++x;
    >>>> }
    >>>>
    >>>> int bit64() {
    >>>> return bit32() + (bit32() << 1);
    >>>> }
    >>>
    >>> You try to change a variable twice, which is invalid, ie. undefined
    >>>behaviour.

    >
    >> There is a sequence point between the two modifications of x, so
    >> there's no undefined behavior here.

    >
    >Actually, yes they are. He has undefined behaviour - void main(). 1 and
    >2 are as legal outputs as 4 and 5, and so is "your mother was a hamster
    >and your father smelt of elderberries".


    Yes, of course, but I wasn't responding to that. I was responding to
    the claim that calling bit32() twice, as shown above, was undefined
    behavior. And it's not. I specifically didn't show the void main()
    part of the code.

    As a practical matter, if he fixed the void main() thing, he's not
    going to get a different result -- he'll still get one of the two
    possible outcomes from bit64(). So he'll end up with a program that
    has unspecified (but not undefined) behavior.

    -- Brett
     
    Brett Frankenberger, Jul 20, 2003
    #7
  8. On Sun, 20 Jul 2003 18:29:35 GMT, "Falcon Kirtarania" <>
    wrote:

    >> 'void main' is illegal. It is *always* 'int main'.


    >No, it is not. However, int main has always been considered MUCH better
    >practice, because it allows for escapes and return codes.


    No, it's illegal. Read the standards.

    --
    Be seeing you.
     
    Thore B. Karlsen, Jul 20, 2003
    #8
  9. "Falcon Kirtarania" <> wrote in message
    news:jcBSa.496586$...
    >
    > "Jakob Bieling" <> wrote in message
    > news:bfej5d$727$01$-online.com...
    > > "Oliver Brausch" <> wrote in message
    > > news:...
    > >
    > > > have you ever heard about this MS-visual c compiler bug?
    > > > look at the small prog:

    > >
    > > It is not a compiler bug. It is a bug in your code.
    > >
    > > > static int x=0;
    > > > int bit32() {
    > > > return ++x;
    > > > }
    > > >
    > > > int bit64() {
    > > > return bit32() + (bit32() << 1);
    > > > }

    > >
    > > You try to change a variable twice, which is invalid, ie. undefined
    > > behaviour. Microsoft's compiler is absolutely right.
    > >
    > > > void main(int argc, char **argv) {

    > >
    > > 'void main' is illegal. It is *always* 'int main'.

    >
    > No, it is not. However, int main has always been considered MUCH better
    > practice, because it allows for escapes and return codes.


    You might want to do a search on Google about why you should write 'int
    main' instead of 'void main'. Do not want to start such a long discussion
    again. ;o)

    regards
    --
    jb

    (replace y with x if you want to reply by e-mail)
     
    Jakob Bieling, Jul 20, 2003
    #9
  10. In article <>,
    (Oliver Brausch) wrote:

    > Hello,
    >
    > have you ever heard about this MS-visual c compiler bug?
    > look at the small prog:
    >
    >
    > static int x=0;
    > int bit32() {
    > return ++x;
    > }
    >
    > int bit64() {
    > return bit32() + (bit32() << 1);
    > }
    >
    > void main(int argc, char **argv) {
    > int i;
    > for (i = 0; i < 5; i++) printf("%d. %d\n", i, bit64());
    > }
    >
    >
    > Ok, the (correct) result is:
    >
    > 0. 2
    > 1. 8
    > 2. 14
    > 3. 20
    > 4. 26
    >
    > This is what every compiled progam says. Inclusive MSVisualC Compiler
    > with Debug options or /Ot fast-option.
    >
    > But do not dare to switch to the the /O2 option of MSVisualC Compiler.
    > Then once your computer cannot calculate anymore:
    >
    > 0. 1
    > 1. 7
    > 2. 13
    > 3. 19
    > 4. 25
    >
    > So, up to Microsoft, 0 + 2 = 1 ?????. That's why their OS is so stable....
    > Try to increase the "<< 1". It even gets worse.
    >
    > Ever seen this? I costed me hours of debugging. Can I
    > sue Microsoft for this?


    Unspecified behaviour. It is absolutely to be expected that two
    compilers will give different results. And I would just guess that the
    code you posted is not the one that produced this output anyway; maybe
    bit32 () contained an x++ instead of a ++x? If you took a programming
    course with Microsoft, then maybe you can demand your money back.
     
    Christian Bau, Jul 20, 2003
    #10
  11. In 'comp.lang.c', (Oliver Brausch) wrote:

    > have you ever heard about this MS-visual c compiler bug?
    > look at the small prog:
    >
    > static int x=0;
    > int bit32() {
    > return ++x;


    I don't like that too much.

    > }


    Do you meant?

    int bit32()
    {
    static int x=0;

    x++;
    return x;
    }

    > int bit64() {
    > return bit32() + (bit32() << 1);
    > }


    Let's go by hand:

    [0] 1 + (2 * 2) = 5
    [1] 3 + (4 * 2) = 11
    [2] 5 + (6 * 2) = 17
    [3] 7 + (8 * 2) = 23
    [4] 9 + (10 * 2) = 29

    Dev-C++ (gcc) :

    0. 5
    1. 11
    2. 17
    3. 23
    4. 29

    > void main(int argc, char **argv) {
    > int i;
    > for (i = 0; i < 5; i++) printf("%d. %d\n", i, bit64());
    > }
    >
    >
    > Ok, the (correct) result is:
    >
    > 0. 2
    > 1. 8
    > 2. 14
    > 3. 20
    > 4. 26


    Why?

    > This is what every compiled progam says. Inclusive MSVisualC Compiler
    > with Debug options or /Ot fast-option.
    >
    > But do not dare to switch to the the /O2 option of MSVisualC Compiler.
    > Then once your computer cannot calculate anymore:
    >
    > 0. 1
    > 1. 7
    > 2. 13
    > 3. 19
    > 4. 25


    Wrong too. Sounds like a UB. I suspect a sequence point is missing in

    > return ++x;



    --
    -ed- [remove YOURBRA before answering me]
    The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html
    <blank line>
    FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/
     
    Emmanuel Delahaye, Jul 20, 2003
    #11
  12. Emmanuel Delahaye <> scribbled the following
    on comp.lang.c:
    > In 'comp.lang.c', (Oliver Brausch) wrote:


    >> have you ever heard about this MS-visual c compiler bug?
    >> look at the small prog:
    >>
    >> static int x=0;
    >> int bit32() {
    >> return ++x;


    > I don't like that too much.


    >> }


    > Do you meant?


    > int bit32()
    > {
    > static int x=0;


    > x++;
    > return x;
    > }


    >> int bit64() {
    >> return bit32() + (bit32() << 1);
    >> }


    > Let's go by hand:


    > [0] 1 + (2 * 2) = 5
    > [1] 3 + (4 * 2) = 11
    > [2] 5 + (6 * 2) = 17
    > [3] 7 + (8 * 2) = 23
    > [4] 9 + (10 * 2) = 29


    > Dev-C++ (gcc) :


    > 0. 5
    > 1. 11
    > 2. 17
    > 3. 23
    > 4. 29


    >> void main(int argc, char **argv) {
    >> int i;
    >> for (i = 0; i < 5; i++) printf("%d. %d\n", i, bit64());
    >> }
    >>
    >>
    >> Ok, the (correct) result is:
    >>
    >> 0. 2
    >> 1. 8
    >> 2. 14
    >> 3. 20
    >> 4. 26


    > Why?
    >
    >> This is what every compiled progam says. Inclusive MSVisualC Compiler
    >> with Debug options or /Ot fast-option.
    >>
    >> But do not dare to switch to the the /O2 option of MSVisualC Compiler.
    >> Then once your computer cannot calculate anymore:
    >>
    >> 0. 1
    >> 1. 7
    >> 2. 13
    >> 3. 19
    >> 4. 25


    > Wrong too. Sounds like a UB. I suspect a sequence point is missing in


    >> return ++x;


    No, there is nothing wrong with "return ++x;" by itself. Not a missing
    sequence point, anyway. Others have already explained the OP's problems
    to him: (1) He's using void main(), undefined behaviour. (2) He's
    calling bit32() twice without an intervening sequence point,
    unspecified behaviour.

    --
    /-- Joona Palaste () ---------------------------\
    | Kingpriest of "The Flying Lemon Tree" G++ FR FW+ M- #108 D+ ADA N+++|
    | http://www.helsinki.fi/~palaste W++ B OP+ |
    \----------------------------------------- Finland rules! ------------/
    "You can pick your friends, you can pick your nose, but you can't pick your
    relatives."
    - MAD Magazine
     
    Joona I Palaste, Jul 20, 2003
    #12
  13. Any compiler I've used never called it.

    "Thore B. Karlsen" <> wrote in message
    news:...
    > On Sun, 20 Jul 2003 18:29:35 GMT, "Falcon Kirtarania" <>
    > wrote:
    >
    > >> 'void main' is illegal. It is *always* 'int main'.

    >
    > >No, it is not. However, int main has always been considered MUCH better
    > >practice, because it allows for escapes and return codes.

    >
    > No, it's illegal. Read the standards.
    >
    > --
    > Be seeing you.
     
    Falcon Kirtarania, Jul 20, 2003
    #13
  14. Oliver Brausch

    Noah Roberts Guest

    Falcon Kirtarania wrote:
    > Yes, but it is still legal, in that it will compile. I am not saying void
    > main should be considered good practice, only that it is still compilable
    > and (for all intents and purposes) works, as long as you don't give a crap
    > about certain results.


    Lots of things compile that are not standard or "illegal" by standard.

    Still, I am stuck wondering why this is taking place in r.g.c.c

    NR
     
    Noah Roberts, Jul 20, 2003
    #14
  15. Falcon Kirtarania <> scribbled the following
    on comp.lang.c:
    > Any compiler I've used never called it.


    You haven't used every compiler there is. And even if you had, nothing
    would stop anyone from writing a new compiler where void main() was
    illegal.
    The moral of the story is: When the ISO C standard and your compiler
    are giving you different ideas, trust the ISO C standard.

    > "Thore B. Karlsen" <> wrote in message
    > news:...
    >> On Sun, 20 Jul 2003 18:29:35 GMT, "Falcon Kirtarania" <>
    >> wrote:
    >>
    >> >> 'void main' is illegal. It is *always* 'int main'.

    >>
    >> >No, it is not. However, int main has always been considered MUCH better
    >> >practice, because it allows for escapes and return codes.

    >>
    >> No, it's illegal. Read the standards.


    --
    /-- Joona Palaste () ---------------------------\
    | Kingpriest of "The Flying Lemon Tree" G++ FR FW+ M- #108 D+ ADA N+++|
    | http://www.helsinki.fi/~palaste W++ B OP+ |
    \----------------------------------------- Finland rules! ------------/
    "I will never display my bum in public again."
    - Homer Simpson
     
    Joona I Palaste, Jul 20, 2003
    #15
  16. On Sun, 20 Jul 2003 19:19:34 GMT, "Falcon Kirtarania" <>
    wrote:

    >Yes, but it is still legal, in that it will compile. I am not saying void
    >main should be considered good practice, only that it is still compilable
    >and (for all intents and purposes) works, as long as you don't give a crap
    >about certain results.


    The fact that one or several compilers accepts a piece of code does not
    mean it is legal code.

    --
    Be seeing you.
     
    Thore B. Karlsen, Jul 20, 2003
    #16
  17. Oliver Brausch

    jemma Guest

    On 20 Jul 2003 10:14:53 -0700, (Oliver Brausch) wrote:

    > <snip>
    >
    >Ever seen this? I costed me hours of debugging.
    >
    > <snip>


    Hours? If you've read all of the replies to your post and understand
    what you've been told, that's not too bad considering all the lessons
    you've (hopefully) learned -- and you'll be a better programmer (and
    USENET poster) for it.

    It's common for a novice programmer to blame the compiler, but
    resist the temptation. Remember:

    "...I don't think there is any question about it. It can only
    be attributable to human error. This sort of thing has cropped
    up before and it has always been due to human error."
    --HAL 9000
     
    jemma, Jul 20, 2003
    #17
  18. Perhaps not in ISO C, then. Whatever. As long as you don't need to port it
    between compilers, it really doesn't matter.

    "Joona I Palaste" <> wrote in message
    news:bfeqg4$qlb$...
    > Falcon Kirtarania <> scribbled the following
    > on comp.lang.c:
    > > Any compiler I've used never called it.

    >
    > You haven't used every compiler there is. And even if you had, nothing
    > would stop anyone from writing a new compiler where void main() was
    > illegal.
    > The moral of the story is: When the ISO C standard and your compiler
    > are giving you different ideas, trust the ISO C standard.
    >
    > > "Thore B. Karlsen" <> wrote in message
    > > news:...
    > >> On Sun, 20 Jul 2003 18:29:35 GMT, "Falcon Kirtarania" <>
    > >> wrote:
    > >>
    > >> >> 'void main' is illegal. It is *always* 'int main'.
    > >>
    > >> >No, it is not. However, int main has always been considered MUCH

    better
    > >> >practice, because it allows for escapes and return codes.
    > >>
    > >> No, it's illegal. Read the standards.

    >
    > --
    > /-- Joona Palaste () ---------------------------\
    > | Kingpriest of "The Flying Lemon Tree" G++ FR FW+ M- #108 D+ ADA N+++|
    > | http://www.helsinki.fi/~palaste W++ B OP+ |
    > \----------------------------------------- Finland rules! ------------/
    > "I will never display my bum in public again."
    > - Homer Simpson
     
    Falcon Kirtarania, Jul 20, 2003
    #18
  19. It does, as long as you are considering only the standards of those
    compilers.

    "Thore B. Karlsen" <> wrote in message
    news:...
    > On Sun, 20 Jul 2003 19:19:34 GMT, "Falcon Kirtarania" <>
    > wrote:
    >
    > >Yes, but it is still legal, in that it will compile. I am not saying

    void
    > >main should be considered good practice, only that it is still compilable
    > >and (for all intents and purposes) works, as long as you don't give a

    crap
    > >about certain results.

    >
    > The fact that one or several compilers accepts a piece of code does not
    > mean it is legal code.
    >
    > --
    > Be seeing you.
     
    Falcon Kirtarania, Jul 20, 2003
    #19
  20. "Falcon Kirtarania" <> wrote:

    > Yes, but it is still legal, in that it will compile.


    'it will compile' and 'it is legal C or C++' are two different shoes.

    > I am not saying void
    > main should be considered good practice, only that it is still compilable


    On the few compilers you have used, that might be true. It is also true
    for the compiler I use. So what, it is still illegal.
    --
    jb

    (replace y with x if you want to reply by e-mail)
     
    Jakob Bieling, Jul 20, 2003
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Matthew

    Is this horrible python code?

    Matthew, Nov 5, 2003, in forum: Python
    Replies:
    4
    Views:
    352
    MetalOne
    Nov 5, 2003
  2. Stephen Thorne

    That horrible regexp idiom

    Stephen Thorne, Feb 10, 2005, in forum: Python
    Replies:
    2
    Views:
    286
    Ville Vainio
    Feb 10, 2005
  3. Hakuin

    horrible thrashing with sql.log

    Hakuin, Oct 7, 2006, in forum: ASP .Net
    Replies:
    0
    Views:
    383
    Hakuin
    Oct 7, 2006
  4. Replies:
    2
    Views:
    305
    bruce barker \(sqlwork.com\)
    Nov 8, 2006
  5. ilikewine
    Replies:
    1
    Views:
    319
    Marc 'BlackJack' Rintsch
    Apr 10, 2007
Loading...

Share This Page