• adsasasdasddasdasd (unregistered) in reply to Kill yourself, Please.
    Anonymous:
    Anonymous:
    Anonymous:
    Anonymous:

    Oh, it's just personal preference.  He didn't like the syntax, so he changed it.  Big deal.

     

     

    Well, it's obvious you don't maintain code in the real world, or else you'd understand why this sort of thing is one of the ultimate WTF's. Let's assume that the original code was around for 22 years, and ALL of the original programmers have moved on and/or died. And there's no documentation of the system. Now, one day, you inherit this code. And your boss asks to make some significant changes, and they need to be done yesterday. Not only do you have to learn all the programming idiosyncracies of all the programmers who came before you and modified this code, but you have to LEARN A NEW LANGUAGE!


    Don't be so melodramtic. I program in Python, Ruby, Java, C# and ObjC. Those are the languages I say I "know". However, I could sit down, right now, and fix a bug in a VB application if you gave me a couple of minutes to get comfortable.

    That being said, if someone who claims to know C sits down at this system, these syntax changes are nothing more than a nuisance. If you can't get beyond this, you don't deserve to be called a programmer.

    Sure, he didn't have to, but this is not a WTF...or at least not a major one.


    I am going to guess that you are a student or a hobbiest. 

    The statement about being able to sit down in an unknown language (and I assume unknown application) and fix a bug in a "couple of minutes" is a telling sign.  I believe the average for the program I am currently working on is somewhere around 20 hours to fix a bug.  The fastest is probably 20-30 minutes and the longest is close to 3 months (and at least 5 different developers).

    As a maintainer, I have seen plently of jackasses do stupid things like this.  If you are too stupid/lazy to learn the language you are using, kill yourself, please.

    There is no excuse for shit like this and it should be allowed as a defense for murder.


    Maybe not a hobbyist.  Just someone who has never worked on an enterprise-level app, or someone who thinks he has and actually hasn't.
     
    I've worked with lots of poseurs like that in the past.  They think they're so cool, what with their 10K line apps.
  • Sander (unregistered) in reply to The Bears
    Anonymous:

    The original Bourne shell takes this approach even further.

    Look at mac.h. Then look at args.c. Then go wash your brain out with vodka.

    That's just a weak hearted attempt to write bash in it's own scripting language.

    IF

    // Huergh!

    FI

    Bit like the chicken and the egg :P

  • (cs) in reply to BiggBru
    BiggBru:

    Dan:
    Skinnable programming languages - it's the future. Don't like your current language? Don't want to go to the hassle of writing your own language and compiler? Just pick a language that's close enough and skin it.

    <FONT face=Georgia>The horror, oh the horror!</FONT>

    <FONT face=Georgia>*Shudders*</FONT>

    I think Perl might already support something like this. Which shouldn't be too surprising, really...

  • (cs) in reply to Maurits
    Maurits:
    Anonymous:
    Okay, it's mostly annoying, but there's a minor case to be made for the EQ operator -- namely, that it's easy to leave off an '=' by mistake.

    Of course, a better solution to this is, whenever possible, to put one's variables on the *right* side of the == operator, but still, I can almost forgive that one.


    ... which works until you're trying to compare two variables.

    C# will save you by requiring if (...) to have a boolean inside it... which works until you have to test boolean variables.


    in the case of comparing boolean variables I prefer to use 'and',  'xor' and the likes.  But that's personal preference I suppose.  It's funnier when ppl start comparing boolean variables with booleans...
    reminds me of some great code I once found in some project:

    x = a < b;
    if(x == true)
        doStuff;
    elseif(x == false)
        doOtherStuff;
    else
        throw UnexpectedValueError


  • BAReFOOt (unregistered) in reply to Jeff S

    Surely you never used Haskell or another language with redefinable syntax, do you?

    In Haskell you not only can redefine basic operators and funtions, but define new operators like #, [, .<. or whatever you want.

    After a time you just get used to it and work on a higher level of thinking.

    So a big narrow-minded WTF? ;)

  • Anonymous Coward (unregistered) in reply to challahc

    challahc:
    The secret to Better Better C.

    #define #define //

    You do know that won't work don't you?

    I had a colleague who's code was sprinkled with lines like this :

    DEBUG printf("whatever");

    When he was done debugging he changed the "#define DEBUG" at the top of the file to "#define DEBUG //". Nothing changed, the preprocessor processed comments before #defines [8-|]

  • (cs) in reply to Angstrom

    Angstrom:
    Reminds me of Bournegol.

    http://www.goof.com/pcg/marc/bournegol.html

    WHILE (parent=fork()) == -1
    DO sigchk(); alarm(10); pause() OD /* crack overdose */

  • (cs) in reply to habedak

    habedak:

    else
        throw UnexpectedValueError

    This code is correct.

  • Dan (unregistered) in reply to marvin_rabbit
    ...
    #define wEn enable
    #define wGv give
    #define wGy guys
    #define wI is
    #define wImprov improvements
    #define wjt just
    #define wkd kind
    #define wM me
    ...

    This looks like some kind of really naïve localization technique.
    (This editor is a WTF BTW)

  • gribble (unregistered) in reply to blasterz

    blasterz, thanks for this URL:

    http://www.conman.org/software/amc/docs/html/amc_usersguide.html

    This is absolutely the most plausible and normal-looking I have ever seen a net kook be, while still being a kook.

    His autobiographical story about how he wanted polymorphism in C and it gradually grew into his life's work -- all the while aware of C++, but never quite understanding why it does what it does -- is absolutely priceless.

  • Tragomaskhalos (unregistered) in reply to RiX0R

    <FONT color=#0000ff><FONT size=+0>#define finally(code) catch(...) { code; throw; } code;</FONT> </FONT>

    <FONT color=#0000ff>Resource r = allocateResource();
    try {
      do_stuff(r);
    }
    finally(freeResource(r));</FONT>

    Please don't do this. Google for RAII (Resource Acquisition Is Initialisation).

     

  • Luis Figueiredo (unregistered)

    I did liked the usefull:

    #define do_nothing

    lol



  • Fuz (unregistered) in reply to Snagglepuss
    Snagglepuss:

    Anonymous:
    Well Visual Studio has a standard header called iso646.h

    #include <iso646.h>

    #pragma once
    #ifndef _ISO646
    #define _ISO646

    #if !defined(__cplusplus) || defined(_MSC_EXTENSIONS)
     #define and    &&
     #define and_eq    &=
     #define bitand    &
     #define bitor    |
     #define compl    ~
     #define not    !
     #define not_eq    !=
     #define or        ||
     #define or_eq    |=
     #define xor    ^
     #define xor_eq    ^=
    #endif /* !__cplusplus || _MSC_EXTENSIONS */

    #endif /* _ISO646 */
    <snip>
    </snip></iso646.h>

    This is an internationalization thing. A lot of keyboards don't have & on them, and there is a significant percentage out there lacking |, ~, ^ and !, as well. I would have thought they'd also define eq for consistency...



    Also, 'and', 'and_eq' etc. are actually standard C++ keywords.  If your compiler doesn't support them, it's not a C++ compiler.  Not that I've ever used them myself.

    Microsoft define this header to reintroduce these names as macros, as enabling language extensions disables the keywords.  Why?  I don't know.  It all seems a bit backwards to me.
  • (cs) in reply to MrEricSir
    MrEricSir:
    So how many #defines would it take to achieve true natural language programming with C?
    F:\>grep #define h:\python-trunk -r | wc -l 10068
    [image]
  • anonymous (unregistered) in reply to Poultine

    ...or, the maintainer could just run it through cpp. Lighten up, Francis.

  • (cs)

    Over 20 years ago, when I used to code 68k assembly language for a living, I wrote a suite of macros that made my asm look a whole lot more like the pascal I was being taught at university. But that didn't make me laugh like this did.

  • . (unregistered) in reply to Manni

    I have no doubt that you don't care. You'll start pulling your hair out when you inherit some code like this though.

    Why pull your hair out?  Just write a quick perl script that fixes it.  Or (if this is how they do things at company X) learn the new language.  It is not like you don't have access to the key.

  • Pyromancer (unregistered) in reply to davesag

    heck, "Better C" rocks,it probably can compile both c and pascal code in same file [;)]

  • (cs) in reply to Cyresse
    Cyresse:

    ...when I'm working with the Win32 API I prefer to use C for simplicity's sake. What do you use?


    I don't work with Windows :D, nor any other OS API.




    Anyway, my post was just a little joke Geeked [8-|]
  • Urkki (unregistered) in reply to sammybaby
    sammybaby:

    But dude, seriously. He needed to reserve "forever"... AND <font style="background-color: rgb(255, 255, 255);" color="#000000">untilbreak, AND untilreturn?</font>



    These could actually make sense in C, if enforced by the compiler.  Ie "forever"-loop mustn't contain break or return, it would essentially generate "no-return" function implicitly.  Similarily, "untilbreak" would have to contain (reachable) break etc, and any code after "untilreturn" would be known to be unreachable, etc.  And then there also should be warnings about having break or return from within a standard while loop.  But without compiler enforcing these, they're pretty much pointless and just using plain comments would be better.

  • Zos (unregistered) in reply to Pyromancer
    Anonymous:
    heck, "Better C" rocks,it probably can compile both c and pascal code in same file [;)]
    That's what I was thinking! This seriously looks like a cross of Pascal.. or COBOL with possibly some JCL syntax thrown in. Perhaps this guy is more used to the world of OS/390?
  • . (unregistered) in reply to Dan
    Skinnable programming languages - it's the future.

    Don't like your current language? Don't want to go to the hassle of writing your own language and compiler? Just pick a language that's close enough and skin it.

    C (crappy macros), Common Lisp (true macros), Perl (
    Filter::Simple) all allow you to do this.  In some cases it even makes sense (ESQL/C, domain specific languages, etc.).
  • (cs) in reply to Sander
    Anonymous:
    Anonymous:

    The original Bourne shell takes this approach even further.

    Look at mac.h. Then look at args.c. Then go wash your brain out with vodka.

    That's just a weak hearted attempt to write bash in it's own scripting language.

    IF

    // Huergh!

    FI

    Bit like the chicken and the egg :P



    #define FI if
    #define huergh! FI

    huergh! (foo) {
    //hello
    }
  • Tim (unregistered) in reply to bramster

    Better yet, as a TA I once saw this at the top of a program that a student was having issues with.

    #define BEGIN {
    #define END }

  • (cs) in reply to jspenguin
    jspenguin:
    ZeoS:
    #define COMMENT // #define macro define #macro . ; COMMENT every statement should finish with .

    Sorry ... The C preprocessor strips out comments before dealing with macros. So, the definition of COMMENT is in fact blank. Although you can use macros in place of C keywords, you can't use them for preprocessor directives.

    So while you could do #define if while it would only affect if (something) { do_stuff(); } and not #if some_macro void do_stuff(void); #endif



    preprocess this:
    /
    Sorry ... The C preprocessor strips out comments before dealing with macros. So, the definition of COMMENT is in fact blank. Although you can use macros in place of C keywords, you can't use them for preprocessor directives. So while you could do #define if while it would only affect if (something) { do_stuff(); } and not #if some_macro void do_stuff(void); #endif
    /

  • meadandale (unregistered) in reply to Arancaytar
    Arancaytar:
    > # define do_nothing
    Priceless.


    This one must have been recommended by Paula.
  • (cs) in reply to Jeff S
    Jeff S:
    Congratulations, Sam, that is actually one of the biggest "WTF" comments we've seen here in a while.   yeah, all he did was CHANGE THE SYNTAX of the language ... no biggie.


    Actually, many languages (primarily Lisp, though another poster also pointed out Haskell) provide formal ways to extend the syntax of a language, thus allowing the programmer to make his code clearer. Mostly by bringing the language closer to the problem domain (that is, implementing domain-specific embedded languages) but convenience syntax extensions are very common as well. It is not a bad thing as code using properly designed syntax extensions can be easier to read than code which spells out its meaning explicitly in the built-in syntax.

    While such extensions may not be a very good idea in C, due to the rather crude design of the C-preprocessor, this days WTF isn't that bad (though it would still make me go WTF to begin with). I have a hard time believing that anyone with enough programming knowledge to find this site interesting, would have a hard time figuring out what this code means:

    repeat {
    do_stuff();
    } until (stuff_no_longer_needs_doing())
  • Willie (unregistered)

    The only wtf here are the useless translation of logical/comparison operators, bitwise operators, and the aritmetic operators.

    The constrol constructs document themselves and are obvious in their function.

  • Patrick Anderson (unregistered)

    I feel violated please stop.

  • Kinko (unregistered) in reply to Chris

    Oh yeah the old, write once, blue screen everywhere chessnut.

    Perhaps this guy works for Microsoft, they seem to skilled in defining different Syntaxs that do the same thing (a BIG WTF).

  • O'Leeper (unregistered)

    What a bunch of big whiny babies.  Now I know this term came into vogue after C, but there's this newfangled process called "refactoring" that came into wide use recently, and it's capable of undoing these modifications or even changing these macros to more annoying ones.  Sadly, for those droves of you still tied down to punchcard operated machines, this will be a difficult process, but for those of you with *any text editor at all* and a high school education, you should be kicked to the curb faster than the original author if you're a C programmer and don't konw how to fix it.

    The reaction I'm seeing here makes it sound like this guy made a binary mod to the compiler that can only be undone by going back in time and changing the past.  Where's the DeLorean and that pesky mad scientist when you need him?

  • Fizzl (unregistered) in reply to ChiefEngineer
    Anonymous:

    ZeoS:
    #define COMMENT //

    Great!

    Should be added:

    #define COMMENT_START     /*

    #define COMMENT _END        */


    Even better:

    #define I /*
    #define go */

    I think we should implement this sturcture thus:

    a = number kjasdfkasdf
    b = foofaa
    So let's go
    struct m00
    {
     int a;
     int b;
     I am not sure. Perhaps the next one is unnecessary.
     int c;
    }

    struct f00
    {
     int c;
     int d;
     We really should let this one go
     int e;
    }

  • miguev (unregistered)

    Wow, this combine the power and great syntax of both Pascal and Fortran! :D

    --
    The keyboard is a sword of freedom. Coding is an act of rebellion.

  • (cs) in reply to Anonymous Coward
    Anonymous:

    challahc:
    The secret to Better Better C.

    #define #define //

    You do know that won't work don't you?

    I had a colleague who's code was sprinkled with lines like this :

    DEBUG printf("whatever");

    When he was done debugging he changed the "#define DEBUG" at the top of the file to "#define DEBUG //". Nothing changed, the preprocessor processed comments before #defines [8-|]



    This would have worked, though, assuming that his DEBUG lines only contained one statement:

    #define DEBUG if (0)
  • (cs) in reply to Jeff S
    Jeff S:
    Anonymous:

    Oh, it's just personal preference.  He didn't like the syntax, so he changed it.  Big deal.



    Congratulations, Sam, that is actually one of the biggest "WTF" comments we've seen here in a while.   yeah, all he did was CHANGE THE SYNTAX of the language ... no biggie.

    So what?  Syntax is just syntax.  Learning syntax is the easy bit [that anyone can do]

     

  • Some Dude (unregistered) in reply to Maurits
    Maurits:

    excerpt of cruise_missile_guidance_system.c...

    pos p = starting_position(), p_old, target = acquire_target();

    do {
        p_old = p;
        p = gps_query();
        trajectory t = vector(p_old, p);
        correction c = calculate_course(target, p, t);
        adjust_course(c);
    } forever;


    Genius! Looks like you don't even know what's the return value of the comma-operator.
  • JB (unregistered) in reply to ChiefCrazyTalk

    Is it possible to...

    #define IM IDIOT PLEASE REPLACE THE FIRST WORD BY THE SECOND #define

    [6]

  • JB (unregistered) in reply to JB
    Anonymous:

    Is it possible to...

    #define IM IDIOT PLEASE REPLACE THE FIRST WORD BY THE SECOND #define

    [6]

    well i forgot the underscores but you understand :P

  • (cs) in reply to mrsticks1982
    mrsticks1982:
    while we're at it why don't we create BETTER_JAVA and oh, oh BETTER_VISUAL_BASIC, changing it all, talk about job security!!


    Yep! Obviously, Java will stagnate horribly when it doesn't have a preprocessor! If it had a preprocessor, everyone could easily build BETTER_JAVA! We must add preprocessor to every language to avoid this horrible language stagnation, and let people come up with their own fun!

    But no might in the world can create a BETTER_VISUAL_BASIC. :)

  • (cs) in reply to Some Dude
    Anonymous:
    Genius! Looks like you don't even know what's the return value of the comma-operator.


    Reaaaaaaally... enlighten me, if you would.
  • Jim Howard (unregistered)

    "Awww, I saw the GT, GE, and LTs and thought FORTRAN. "

    FORTRAN always had >, >= and <, but it allowed GT, GE and LT because a lot of keypunch machines didn't have many special characters.

  • plainsane (unregistered)

    imagine my suprise when i found this code at my old job. it does compile in g++ 4.0.2.

    anybody have a good reason for this? cause g++ guys think its cool.

    int i = 0; ... if (i>=1 or i<=-1) //print some shit to console.

  • Jim Howard (unregistered) in reply to Jim Howard
    Anonymous:
    "Awww, I saw the GT, GE, and LTs and thought FORTRAN. "


    FORTRAN always had the characters for greater than, equal or greater, and less than, but it allowed GT, GE and LT because a lot of keypunch machines didn't have many special characters.


    I think the fact that WTF doesn't have a post preview is a WTF.

  • stupid (unregistered) in reply to O'Leeper
    Anonymous:

    What a bunch of big whiny babies.  Now I know this term came into vogue after C, but there's this newfangled process called "refactoring" that came into wide use recently, and it's capable of undoing these modifications or even changing these macros to more annoying ones.  Sadly, for those droves of you still tied down to punchcard operated machines, this will be a difficult process, but for those of you with *any text editor at all* and a high school education, you should be kicked to the curb faster than the original author if you're a C programmer and don't konw how to fix it.

    The reaction I'm seeing here makes it sound like this guy made a binary mod to the compiler that can only be undone by going back in time and changing the past.  Where's the DeLorean and that pesky mad scientist when you need him?



    Knowing how to fix a WTF and being given the time/money to do it are two completely different things.  What if this WTF is spread throughout out a 10 million line code base?  Do you know what the cost would be of refactoring it?  Can you even imagine the cost of testing everything you would touch by converting all the code?  (Oh yeah, simple script it won't break anything...) Because after all if one moron did this there could of been some one else that preferred Ada or COBOL or what ever other language.


    Just because it maybe simple change in the project you are used to doesn't mean it would be easy in all cases.

  • bramster (unregistered) in reply to headhigh
    headhigh:
    Just write a quick script that reads the stupid header file, creates a look-up table and then goes through the source tree replacing the macro tokens.  Then delete the header file and pretend "better C" never existed.  Should take you less than 2 hours.  Plus maybe another 4 hours of heavy drinking to wipe "better C" from your memory.

    Or pull your hair out.



    Easy.   Create a translation table as follows

    a'NE' '!='
    a'EQ' '=='
    a'GT' '>'
    a'LT' '<'
    a'GE' '>='
    a'LE' '<='
    a'AND' '&&'
    a'OR' '||'
    a'NOT' '!'
    a'bNOT' '~'
    a'bAND' '&'
    a'bOR' '|'
    a'bXOR' '^'

    a'MOD' ' %'

    a'repeat' 'do'
    a'until(p)' 'while(NOT (p))'
    a'forever' 'while(1)'
    a'untilbreak' 'forever'
    a'untilreturn' 'forever'
    a'unless(p)' 'if(NOT (p))'
    a'ifnot(p)' 'if(NOT (p))'
    a'do_nothing' a''



    call it wtf.trf

    use your handy-dandy translation program (written in un-improved C)

    bmtran improved.c old_shitty.c wtf.trf

    out comes old_shitty.c, but readable.








  • bramster (unregistered) in reply to bramster
    Anonymous:
    headhigh:
    Just write a quick script that reads the stupid header file, creates a look-up table and then goes through the source tree replacing the macro tokens.  Then delete the header file and pretend "better C" never existed.  Should take you less than 2 hours.  Plus maybe another 4 hours of heavy drinking to wipe "better C" from your memory.

    Or pull your hair out.



    Easy.   Create a translation table as follows

    a'NE' '!='
    a'EQ' '=='
    a'GT' '>'
    a'LT' '<'
    a'GE' '>='
    a'LE' '<='
    a'AND' '&&'
    a'OR' '||'
    a'NOT' '!'
    a'bNOT' '~'
    a'bAND' '&'
    a'bOR' '|'
    a'bXOR' '^'

    a'MOD' ' %'

    a'repeat' 'do'
    a'until(p)' 'while(NOT (p))'
    a'forever' 'while(1)'
    a'untilbreak' 'forever'
    a'untilreturn' 'forever'
    a'unless(p)' 'if(NOT (p))'
    a'ifnot(p)' 'if(NOT (p))'
    a'do_nothing' a''



    call it wtf.trf

    use your handy-dandy translation program (written in un-improved C)

    bmtran improved.c old_shitty.c wtf.trf

    out comes old_shitty.c, but readable









    oops, should have been:


    a'NE' a'!='
    a'EQ' a'=='
    a'GT' a'>'
    a'LT' a'<'
    a'GE' a'>='
    a'LE' a'<='
    a'AND' a'&&'
    a'OR' a'||'
    a'NOT' a'!'
    a'bNOT' a'~'
    a'bAND' a'&'
    a'bOR' a'|'
    a'bXOR' a'^'

    a'MOD' a' %'

    a'repeat' a'do'
    a'until(p)' a'while(NOT (p))'
    a'forever' a'while(1)'
    a'untilbreak' a'forever'
    a'untilreturn' a'forever'
    a'unless(p)' a'if(NOT (p))'
    a'ifnot(p)' a'if(NOT (p))'
    a'do_nothing' a''




  • diaphanein (unregistered) in reply to Jim Howard

    That some people don't think this is that big of a deal frightens me.  As a developer that is solely responsible for approximately 500k lines of C++ code, most of which I am not the original author, allow me to state that encountering something like this would bring out murderous tendencies.

    Consider the following:

    #include <IOSTREAM>
    #include <VECTOR>

    #define begin {
    #define end }

    static const int numbers[] = { 1, 3, 5, 7, 9 };
    const size_t n_numbers = sizeof(numbers) / sizeof(*numbers);

    int main(int argc, const char** argv)
    begin
       std::vector<INT> nums(numbers, numbers + n_numbers);
       for (std::vector<INT>::const_iterator iter = nums.begin(); iter != nums.end(); ++iter)
       begin
          std::cout << *iter << std::endl;
       end
    end

    This now won't compile.  Weeeeee.  This is just one example for the infinite many about why using macros to change language syntax is a bad idea.  Macros have their purpose, this isn't one of them.

  • (cs) in reply to Jim Howard

    Anonymous:
    Anonymous:
    "Awww, I saw the GT, GE, and LTs and thought FORTRAN. "


    FORTRAN always had the characters for greater than, equal or greater, and less than, but it allowed GT, GE and LT because a lot of keypunch machines didn't have many special characters.


    I think the fact that WTF doesn't have a post preview is a WTF.

     

    Umm...official standard for Fortran66 indicates that the official Fortran Character Set inclused alphanumerics, space, and =. +, -, *, /, (, ), ,, ., and $.  Maybe a later version has em or maybe some companies had different flavors, but <'s, >'s, and ='s weren't in the 66 standard.

  • (cs) in reply to stephen

    Anonymous:
    Seriously I don't see the WTF.  You read some C code, see a strange header file, take a look and see that it is just a bunch of defines to change the syntax.  No prob, you write a short perl script that changes everything back to normal (does exactly what the c preprocessor does) and charge at least a days work for it.

    And then the next guy gets to go back and fix all the now-busted comments, string literals, etc., that get changed as collateral damage.  I was that next guy.  I had to grovel through thousands of lines of comments and string literals changing all occurrences of "&&" back to "and", "||" back to "or", etc.  We had defects come back for months because a prompt read "Press Return to {" or some such nonsense.  All because someone thought that making C look more like Pascal would make it behave more like Pascal. 

    Preprocessor abuse is a capital crime. 

  • (cs) in reply to Derek

    Anonymous:
    Anonymous:

    Actually this is encouraged in the great book Code Complete by Steve McConnell.

    if (someTestPasses())
    {
        // do some stuff
    }
    else
    {
        do_nothing(); // this is cleaner than the alternative ";"
    }

    Steve encourages this style of code because it implies that the programmer knows that nothing is to be done if the test failes.

    I really don't think this post is a WTF. A little extreme, but definitely not a WTF.


    This:

    else
    {
        // do nothing
    }

    is just as clear, without adding an unnecessary function call (and definition).

    This is even better:

    if (someTestPasses())

    {

        /* do stuff */

    }

     

    Corollary: if you're going to put in an else branch, have it do something useful (if nothing else, log that the test failed).  Otherwise it's just visual noise.

Leave a comment on “The Secret to Better C”

Log In or post as a guest

Replying to comment #60448:

« Return to Article