Thread: How do I disable these GCC warnings?

  1. #1
    and the hat of sweating
    Join Date
    Aug 2007
    Location
    Toronto, ON
    Posts
    3,545

    How do I disable these GCC warnings?

    Hi,
    I'm getting thousands of these warnings when compiling with -Wall:
    Code:
    warning: multi-line string literals are deprecated
    warning: unknown escape sequence '\#'
    I don't see anything in the GCC manual that talks about them.

    http://gcc.gnu.org/onlinedocs/gcc-3....ning%20Options

    I tried the -Wno-deprecated-declarations option, but that didn't help.
    Any ideas about turning them off?

  2. #2
    Code Goddess Prelude's Avatar
    Join Date
    Sep 2001
    Posts
    9,897
    >Any ideas about turning them off?
    Yea, don't. When you get warnings you should change your code so that they go away, not sweep them under the rug and hope they won't screw something up later.
    My best code is written with the delete key.

  3. #3
    Officially An Architect brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,396
    Just don't use multi-line string literals. Instead of this:

    Code:
    char *multi_line = "this is a 
    multi-line 
    string literal";
    Do this instead:

    Code:
    char *multi_line = "this is a "
    "multi-line "
    "string literal";
    When the preprocessor sees a sequence of strings like that, it combines them into a single string.

    You could also escape the newlines, but I think just using multiple string segments is better.

  4. #4
    and the hat of sweating
    Join Date
    Aug 2007
    Location
    Toronto, ON
    Posts
    3,545
    I didn't write this crappy code, I just have to port it to Linux.
    By the looks of it, I don't think they ever used (or paid attention to) any warnings at all...

    Since they want this done yesterday, I just want to compile cleanly and fix the more important warnings first. Then later I can try to fix the multiline thing.

  5. #5
    Algorithm Dissector iMalc's Avatar
    Join Date
    Dec 2005
    Location
    New Zealand
    Posts
    6,318
    Quote Originally Posted by cpjust View Post
    I didn't write this crappy code, I just have to port it to Linux.
    By the looks of it, I don't think they ever used (or paid attention to) any warnings at all...

    Since they want this done yesterday, I just want to compile cleanly and fix the more important warnings first. Then later I can try to fix the multiline thing.
    So what if they want it done yesterday. Would you rather give it to them late AND buggy, or just late? A few months from now they'll have forgotten it was late, but if it's buggy too, that can't simply be forgotten.

    Besides they wont likely find anyone else to port and fix it any quicker.
    My homepage
    Advice: Take only as directed - If symptoms persist, please see your debugger

    Linus Torvalds: "But it clearly is the only right way. The fact that everybody else does it some other way only means that they are wrong"

  6. #6
    and the hat of sweating
    Join Date
    Aug 2007
    Location
    Toronto, ON
    Posts
    3,545
    Quote Originally Posted by iMalc View Post
    So what if they want it done yesterday. Would you rather give it to them late AND buggy.
    Hey, that's my company's motto!
    If I was in charge, I wouldn't release anything with bugs in it, but if they want to sell crappy software they can go right ahead, just as long as I keep getting paid...

    Besides, it'll take the customer a while (maybe a long while) to integrate these libraries I'm porting into their code. So if they get the libraries while I continue to scrape the mold off this code, that'll give them time to figure out how to use the library. Once I'm done and have the libs tested, they can replace them with the final ones and keep going.

  7. #7
    Officially An Architect brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,396
    Quote Originally Posted by cpjust View Post
    Hey, that's my company's motto!
    If I was in charge, I wouldn't release anything with bugs in it, but if they want to sell crappy software they can go right ahead, just as long as I keep getting paid...

    Besides, it'll take the customer a while (maybe a long while) to integrate these libraries I'm porting into their code. So if they get the libraries while I continue to scrape the mold off this code, that'll give them time to figure out how to use the library. Once I'm done and have the libs tested, they can replace them with the final ones and keep going.
    Well, if you INSIST on just ignoring the warnings, you can just grep them out of the build so you don't have to see them...

  8. #8
    and the hat of int overfl Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    39,660
    > I didn't write this crappy code, I just have to port it to Linux.
    In other words, it was "dialect C" rather than ANSI-C.

    Dialect C being that language which the compiler lets you get away with rather than being correct to begin with. If any of this code began life in the days of DOS, there could be all sorts of horrors in there.

    Of course, having gotten it to compile, you then have to make it work and that's where the fun can really start to happen. Some of those minor bugs which previously went un-noticed will come to the fore.
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.

  9. #9
    and the hat of sweating
    Join Date
    Aug 2007
    Location
    Toronto, ON
    Posts
    3,545
    Quote Originally Posted by Salem View Post
    >In other words, it was "dialect C" rather than ANSI-C.

    Dialect C being that language which the compiler lets you get away with rather than being correct to begin with. If any of this code began life in the days of DOS, there could be all sorts of horrors in there.

    Of course, having gotten it to compile, you then have to make it work and that's where the fun can really start to happen. Some of those minor bugs which previously went un-noticed will come to the fore.
    From the dates in some of the comments, it was written in the 80's.
    What's the best approach to use when porting ancient code like that? Should I close my eyes and compile it with all warnings turned off, or should I use -Wall and fix the thousands of problems it finds?

    I'm assuming the code actually works, otherwise why would anyone have ever bought it in the past? So shouldn't it still work today, even though gcc is finding so many little things to complain about?

    So far most of the warnings have been unused variables, functions with no return type specified (which defaults to int, even though there are no return statements in the function), functions used without being defined (i.e. tons of missing #include statements), and using "%d" for unsigned ints instead of "%ld"...

    So far I've been fixing everything except the unused variables which is wasteful, but harmless, plus there's so many #ifdef's in there, I don't want to break anything by deleting variables which get used 300 lines down inside an #ifdef block...

  10. #10
    Just Lurking Dave_Sinkula's Avatar
    Join Date
    Oct 2002
    Posts
    5,005
    Workaround: -traditional?

    But fix the problems it finds.
    7. It is easier to write an incorrect program than understand a correct one.
    40. There are two ways to write error-free programs; only the third one works.*

  11. #11
    Registered User
    Join Date
    Apr 2006
    Posts
    2,149
    Multi-line string literals you can get away with. Those should still work like they did before.

    The "unknown escape sequence '\#'" presumably was supposed to do something. Possibly just represent #. Possibly something else. You'll need to figure out what it's supposed to do and change it to do just that with modern C.
    Last edited by King Mir; 10-20-2007 at 08:24 PM.
    It is too clear and so it is hard to see.
    A dunce once searched for fire with a lighted lantern.
    Had he known what fire was,
    He could have cooked his rice much sooner.

  12. #12
    and the hat of int overfl Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    39,660
    > I'm assuming the code actually works, otherwise why would anyone have ever bought it in the past?
    Code is shipped when it stops crashing (too often), not when it is bug free.
    When was the last time you saw some software that was still at version 1, with zero bug reports against it, and zero patches, service packs or whatever?

    > So shouldn't it still work today, even though gcc is finding so many little things to complain about?
    When you change compiler, you're going to change the way things are laid out in memory, the sizes of data types etc etc.

    - If you have a struct which is written to a file using fwrite, then trying to read that file when the code is compiled with a different compiler, it will eventually break.

    - If you have int *p = malloc ( 10 );, is that 5 integers assuming 2 bytes per int? Recompiling on a 4-byte int machine is instant trouble. Likewise if they've used magic numbers rather than sizeof in all the places where the size of types/variables matters.

    Code:
    void foo ( ) {
      int a;
      char b[10];
    }
    - If b is later written with 11 chars, that is a buffer overflow, but it does not immediately infer that the problem is detectable. Recompile on another compiler/machine and you might find that it bites.

    > What's the best approach to use when porting ancient code like that?
    Plan a series of steps and document as you go.
    For instance, 'grep' out all the "unused variable" warnings for a later time, and fix what remains as step 1.

    > plus there's so many #ifdef's in there
    How many of them do you actually need?

    Are you required to maintain your Linux port of the code base with the existing systems, like are you also adding in your own #ifdef LINUX conditions as well?
    Or are you abandoning all the old systems and essentially starting afresh with Linux?
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.

  13. #13
    and the hat of sweating
    Join Date
    Aug 2007
    Location
    Toronto, ON
    Posts
    3,545
    Code is shipped when it stops crashing (too often), not when it is bug free.
    Oh I'm sure there are plenty of bugs in the code. I just mean, the main functionality should be working correctly (assuming the functions in this library are being called correctly). I'm not here to fix pre-existing bugs in this code; they just gave me this code and told me to port it to Linux.

    When you change compiler, you're going to change the way things are laid out in memory, the sizes of data types etc etc.
    From what I've seen, they do seem to do things properly by using sizeof(int)..., and their porting documentation even takes things like Big Endian vs Little Endian into account, so I'm hoping there shouldn't be any problems there.

    Are you required to maintain your Linux port of the code base with the existing systems, like are you also adding in your own #ifdef LINUX conditions as well?
    Or are you abandoning all the old systems and essentially starting afresh with Linux?
    I'm pretty sure they want it to stay multiplatform compatible. Plus there's so many makefiles defining things, and #define statements all over the code (not just at the top), that I don't want to start pulling things out without understanding whether they're actually being used or not.

    The code also came with its own test harness code, so once I get it all compiled, I'll need to run all the tests to make sure the library is working correctly.

    The "unknown escape sequence '\#'" presumably was supposed to do something. Possibly just represent #. Possibly something else. You'll need to figure out what it's supposed to do and change it to do just that with modern C.
    I haven't got the slightest clue what that part of the code is for. Those warnings are coming from some .c files that are dynamically genarated by other parts of the code. i.e. it compiles a program that reads some input files and writes a .c file, which then gets compiled later in the makefile...

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Profiler Valgrind
    By afflictedd2 in forum C++ Programming
    Replies: 4
    Last Post: 07-18-2008, 09:38 AM
  2. Definitions for gcc errors and warnings?
    By cpjust in forum C Programming
    Replies: 12
    Last Post: 10-04-2007, 09:18 AM
  3. Replies: 4
    Last Post: 09-02-2007, 08:47 PM
  4. GCC Warnings
    By 00Sven in forum C Programming
    Replies: 12
    Last Post: 05-03-2006, 04:40 AM
  5. Warnings, warnings, warnings?
    By spentdome in forum C Programming
    Replies: 25
    Last Post: 05-27-2002, 06:49 PM