all errors and warnings in C

Discussion in 'C Programming' started by prasanna, Jul 18, 2004.

  1. prasanna

    prasanna Guest

    i will be very thankful if you sent all the errors and warnings regarding
    to the language C

    thank you
     
    prasanna, Jul 18, 2004
    #1
    1. Advertisements

  2. Warnings and errors depend on the compiler used. The C standard only
    dictates what is correct C, it doesn't care what the actual error
    messages are what a compiler produces.


    Igmar
     
    Igmar Palsenberg, Jul 18, 2004
    #2
    1. Advertisements

  3. prasanna

    Mike Wahler Guest

    The language standard requires an implementation to issue
    a diagnostic message for certain language rule violations.
    The actual text of such messages is not specified. I.e.
    every message could be simply e.g. "ERROR!". "Warnings" are
    not required at all. Most implementations do provide somewhat
    meaninful warnings and errors, and each will have their own.
    Consult your documentation.


    -Mike
     
    Mike Wahler, Jul 18, 2004
    #3
  4. I'm afraid your question doesn't make much sense.

    A particular compiler might have a list of all the error and warning
    messages it can produce, but it's going to be different from the
    messages another compiler can produce. Compiler vendors don't
    typically provide such lists, since they're not likely to be useful.
    In any case, questions about specific compilers are off-topic here.

    (The number of mistakes you can make while programming in C is, of
    course, unlimited.)
     
    Keith Thompson, Jul 19, 2004
    #4
  5. prasanna

    Dan Pop Guest

    The C standard contains the complete list of instances requiring a
    compiler diagnostic. It doesn't divide compiler diagnostics into
    errors and warnings and it doesn't provide any requirements WRT the
    proper phrasing of these diagnostics. It also explicitly allows
    implementations to produce other diagnostics than the required ones, as
    long as the required ones are produced.

    Furthermore, only *one* diagnostic is required for a "faulty" translation
    unit, no matter how many standard violations requiring a diagnostic it
    contains.

    So, the minimal requirements imposed by the language are trivially met
    by a compiler displaying a copyright message for each and every
    translation unit processed, whether it is perfectly correct or not.

    Real implementations usually do better than that, but each decides how
    much better.

    Dan
     
    Dan Pop, Jul 19, 2004
    #5
  6. Can a compiler "make up" its own warnings? Could a conforming compiler
    issue a warning if the definition of main() didn't start on an odd-numbered
    line, or if you used the "wrong" method of placing braces?

    $ yuckycc -c foo.c
    foo.c:8 Warning! Definition of main() should be on an odd-numbered line.
    foo.c:10 Warning! I don't like variables named "j".
    foo.c:12 Warning! Braces belong indented below the if() line.
    foo.c:297 Warning! Length of source file exceeds the day of the year.
     
    Kenneth Brody, Jul 19, 2004
    #6
  7. This is entirely allowed, as long as the compiler actually compiles the
    code according to the ISO C standard. The warnings don't even have to
    have anything to do with the source code. This is allowed too:

    $ yuckycc -c foo.c
    foo.c:1 Warning! You are too ugly to be writing C code!
    foo.c:2 Warning! Your feet smell! When did you last take a bath?
     
    Joona I Palaste, Jul 19, 2004
    #7
  8. prasanna

    Eric Sosman Guest

    Yes, of course.

    foo.c:1 Warning! Using "foo" as a file name is deprecated.
    foo.c:42 Warning! This really isn't The Answer.
    foo.c:56 Accolade! malloc() used without a cast.

    However, if the program is correct the implementation must
    accept and attempt to execute it, no matter how many warnings
    or other diagnostics it has issued.

    There's no straightforward technical criterion by which
    one can determine whether a particular warning is superfluous
    or essential: it's matter of the expected "error styles" of the
    users. When the compiler draws attention to perfectly correct
    C code, it may just be making useless noise -- but on the other
    hand, it may be saving your butt.

    switch (what) {
    case 1:
    x = f();
    break;
    case 2:
    x = g();
    break;
    case3:
    x = h();
    break;
    }

    .... is perfectly good C, yet I for one would be glad to be warned
    that `x = h();' is not reachable, or that the label `case3' is
    not used.

    It's a QoI ("Quality of Implementation") issue -- and "Q"
    is neither one-dimensional nor even measured the same way by
    all users of the compiler.
     
    Eric Sosman, Jul 19, 2004
    #8
  9. i will be very thankful if you sent all the errors and warnings regarding
    Yes. Since warnings are not required at all, ALL warnings are "made
    up". I consider this true even in spite of a "common warnings"
    chapter in the (C90) standard, which does not pretend to contain actual
    wordings of warning messages.
    Yes, and this is acceptable per the standard even if the warning
    is a lie (e.g. main() DOES begin on an odd-numbered line). It's a
    quality-of-implementation issue.

    However, I believe it is not acceptable to have an infinite number
    of warnings for a standards-correct program, as that amounts to
    failure to compile it. I don't believe that anything in the standard
    prohibits the compiler from issuing a warning *AND* deleting the source
    code if it generates a correct program.

    Gordon L. Burditt
     
    Gordon Burditt, Jul 19, 2004
    #9
  10. Just so long as it doesn't prevent compilation of a valid programme.
    foo.c:11 warning: I never could get the hang of thursdays.
    foo.c:22 information: the Liberator is under attack.
     
    Mark McIntyre, Jul 19, 2004
    #10
  11. prasanna

    S.Tobias Guest

    I don't see it. Footnote 8 to chapter 5.1.1.3 (Diagnostics)
    says: "The intent is that an implementation should identify the
    nature of, and where possible localize, each violation. [...]".
    Copyright message definitely doesn't satisfy above intent.

    I think even if a compiler spat out all possible diagnostic messages
    on each run, it still shouldn't count as diagnostic.
     
    S.Tobias, Jul 20, 2004
    #11
  12. prasanna

    Richard Bos Guest

    Footnotes are not normative. An implementation that behaved as Dan
    suggests would certainly be a bad implementation, but not a
    non-conforming one.

    Richard
     
    Richard Bos, Jul 20, 2004
    #12
  13. prasanna

    Dan Pop Guest

    ^^^^^^^^^^^^^^^^^^^^^^^^^
    Can I have a chapter and verse for that?

    It is trivial to generate a correct C program that exceeds the translating
    capabilities of any given implementation, while still staying within the
    translation limits imposed by the standard.

    Dan
     
    Dan Pop, Jul 20, 2004
    #13
  14. prasanna

    Dan Pop Guest

    Footnotes are not normative. What the normative text of the standard
    actually says is:

    1 diagnostic message
    message belonging to an implementation-defined subset of the
    implementation's message output
    and

    1 A conforming implementation shall produce at least one diagnostic
    ^^^^^^^^^^^^
    message (identified in an implementation-defined manner)
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    if a preprocessing translation unit or translation unit
    contains a violation of any syntax rule or constraint, even
    if the behavior is also explicitly specified as undefined or
    implementation-defined. Diagnostic messages need not be produced
    in other circumstances.

    So, if the implementation documents that all its diagnostics have the
    format:

    (c) 2004 Foo & Bar Corp

    it is explicitly meeting the requirements imposed by the *normative*
    text of the standard.

    Dan
     
    Dan Pop, Jul 20, 2004
    #14
  15. prasanna

    S.Tobias Guest

    I intended to argue here that a mere copyright message is not
    diagnostical; it is even not a message, because it does not convey
    any information (if it appears on every compilation).

    The problem for me is that 3.10 actually defines "diagnostic
    message" as a term, and I have to follow its definition rather
    than attach usual meaning to it; which means that I must agree to
    your interpretation.
    So could printing an empty string, ie. printf(""), count as
    diagnostic message?
     
    S.Tobias, Jul 20, 2004
    #15
  16. prasanna

    S.Tobias Guest

    This is nonsense. Please drop it.
     
    S.Tobias, Jul 20, 2004
    #16
  17. prasanna

    Dan Pop Guest

    Printing an empty string means not doing anything at all.

    1 A conforming implementation shall produce at least one diagnostic
    message (identified in an implementation-defined manner)
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    How do you identify the fact that the implementation has printed an empty
    string?

    I think that the diagnostic message has to consist from at least one
    printable character, so that the user can identify it.

    Otherwise, I agree that an empty string contains as much useful
    information as an unconditionally issued copyright message, when
    interpreted as a diagnostic.

    Dan
     
    Dan Pop, Jul 21, 2004
    #17
  18. prasanna

    S.Tobias Guest

    AFAICT the Standard doesn't say anywhere that translation environment
    messages have to be printed.

    I'd welcome your comment on my new take on the issue.



    The Standard defines "diagnostic message" as a "subset of implementations
    message output". It does not define "message" or "output" (for the
    translation environment), so we're allowed to use English dictionary
    definitions, so www.m-w.com tells us:

    message:
    1 : a communication in writing, in speech, or by signals

    output:
    e : the information produced by a computer

    Therefore, compiler need not print anything as a diagnostic message, it
    may read the message aloud (through the loudspeakers), flash a light, or
    ring a bell (the compiler might actually be a wooden construction, powered
    by the force of your muscles, witout any electric equipment attached).

    Further, the light need not be in the visible spectrum, neither the
    sound of the bell need be heard (if I close my eyes, it doesn't render
    my compiler non-conforming).

    Up to now we have learned, that in order for the compiler to produce a
    diagnostic message, it need not do anything that is necessarily perceived
    by human senses, but it must do "something" which the documentation
    defines as diagnostic message.

    So, when the diagnostic is required, that something might be executing
    a special piece of code (presented as pseudo-code here):
    [...]
    if do_diagnostic
    nop ; executing this line constitutes a diagnostic message
    [...]
    (It doesn't matter you can't normally see it; you might see this line
    executed in your debugger, if you really wanted.)

    Since the compiler is allowed to produce more diagnostics that necessary,
    we might simplify the above to:
    ; start of the compiler code
    nop ; executing this line constitutes a diagnostic message
    [...] ; rest of the compiler code
    Or let's go to the extreme:
    ; start of the compiler code
    ; executing any line of this code constitutes a diagnostic message
    [...] ; rest of the compiler code

    Thus we have proved, that in order to produce a diagnostic the Standard
    does not actually require the compiler to do anything special, if the
    compiler does something (runs a portion of code) and the docs identify
    it as a diagnostic message.

    Final note: The documentation cannot claim that mere running (starting)
    the compiler program is a diagnostic, because the Standard requires some
    activity on the part of the compiler ("implementation shall produce");
    starting the compiler is performed by the user (or OS on the low level).
    For the same reason the sun-rise cannot constitute a diagnostic, unless
    you find a philosopher that can prove that sun-rise is caused by running
    the compiler program (both are in near time-space distance, so it might
    be not impossible; another possibility could be to officially include
    all sun-rises as part of a translation).
     
    S.Tobias, Jul 22, 2004
    #18
  19. The compiler could wait until the next local sunrise to produce its
    output if it wants to issue a diagnostic, or produce output
    immediately if it doesn't; then the sunrise could be considered a
    diagnostic. (This is ambiguous if you happen to run the compiler at
    sunrise, but the implementation is allowed to produce extraneous
    diagnostics.)

    <OT>I think you mean sed 's/[A-Z]//g'.</OT>
     
    Keith Thompson, Jul 22, 2004
    #19
  20. prasanna

    S.Tobias Guest

    I'm not sure what you mean. My intention has been that the sunrise
    *is* the diagnostic message. To be quite clear (I hope this is
    Standard conforming):


    ReallyBig(t) C compiler documentation

    [...]
    The ReallyBig(t) compiler is composed of two parts: the electronic
    part, which runs on your computer and does the proper source
    translation; and a small part of the Solar System, namely the planet
    Earth and the star Sun, which is responsible for the diagnostic
    messages. The full source translation comprises two major phases:
    the source processing, and the processing and output of the
    diagnostic messages (you have to wait for the both to complete;
    the compiler might issue additional diagnostics during a long
    compilation phase). The diagnostic message is identified as the
    sunrise at the location where the compiler performed or finished
    the source processing. Note: User might have to wait up to 24h
    for the processing of the diagnostic to complete. (User might skip
    the output of the diagnostics and start another source processing
    phase; then the next diagnostic messages shall apply only to the
    last started translation; it has to be noted though, that this is
    a serious deviation from the Standard conformance, and is available
    at User's option only.)
    Disclaimer: The ReallyBig(t) C compiler might not be Standard
    conforming above the polar circles in certain seasons of the year,
    or at high altitudes above the surface of the Earth.
    [...]

    Of course, thanks! I thought I had fixed it long ago.
     
    S.Tobias, Jul 22, 2004
    #20
    1. Advertisements

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.