Baby X

Discussion in 'C Programming' started by Malcolm McLean, Aug 4, 2013.

  1. Or a SourceForge project or equivalent. They're not *that* much work to
    set up, and they're worth it in the long run.
    Edward A. Falk, Aug 15, 2013
    1. Advertisements

  2. That said, let me warn you that X toolkits are a nightmare to write.
    Once you start dealing with fonts, keyboard traversal, other input
    issues, and so forth, you find yourself being sucked into a whirlpool.

    There's a reason why all the X toolkits basically suck -- they're really
    really hard to get right.

    But it's also a lot of fun to do. Enjoy.

    Any chance of a screenshot of yours?

    Let me know if you want a copy of the one I wrote in 1996 to steal
    code from.


    It needs work, of course.
    Edward A. Falk, Aug 15, 2013
    1. Advertisements

    Malcolm McLean, Aug 15, 2013
  4. Malcolm McLean

    Philip Lantz Guest

    Unfortunately, this would require a diagnostic for the following:

    int func(void) {
    if (cond) {
    cleanup_and_exit(); // unconditionally calls exit()
    else {
    return 0;

    unless you also add a noreturn attribute.
    Philip Lantz, Aug 18, 2013
  5. Malcolm McLean

    James Kuyper Guest

    On 08/18/2013 01:31 AM, Philip Lantz wrote:
    Too late - _Noreturn was added in C2011. You can use noreturn as an
    equivalent, so long as you #include <stdnoreturn.h> first.
    James Kuyper, Aug 18, 2013
  6. Malcolm McLean

    Ike Naar Guest

    But with different semantics.

    _Noreturn in C2011 applies to an entire function and indicates
    that the function shall never return to its caller.
    If the _Noreturn specifier were used with func as given above, the
    behaviour would be undefined if the flow would reach the 'else'
    branch, returning 0. Also, the standard recommends that the
    implementation produce a diagnostic message for the function
    since it appears to be capable to return to its caller.

    Philip was apparently looking for a noreturn attribute that would
    prevent a diagnostic for not returning a value in the 'if (cond)'
    Ike Naar, Aug 18, 2013
  7. Malcolm McLean

    James Kuyper Guest

    That's not what I thought Philip was suggesting. It would, of course, be
    inappropriate for the reasons you give below.
    Yes, and applying _Noreturn to the declaration of cleanup_and_exit()
    should enable that.
    James Kuyper, Aug 18, 2013
  8. Malcolm McLean

    Ike Naar Guest

    Ah yes. Okay.
    Ike Naar, Aug 18, 2013
  9. Malcolm McLean

    Ian Collins Guest

    I recently stumbled upon an interesting blog entry from one of the X.Org
    developers regarding the work such changes can entail:
    Ian Collins, Aug 20, 2013
  10. Malcolm McLean

    Phil Carmody Guest

    There's so much fail in that article.

    You should never have to go in and annotate standard library functions.
    The compiler should know their return semantics.

    I also reinforces my view that you should never mindlessly tweak code
    just to get a compiler/linter to shut up about things you know are not
    an error. Some time later, the tools will become less dumb, and stop
    warning about the non-error, and then possible start outputting noise
    because of your tweak. And your tweak may possibly permanently stop
    more intelligent (versions of the) tools from detecting real problems.

    Certainly aim to minimise warnings, but what's more important than
    the list of warning is the *change* in the list of warnings caused
    by a change in the code.

    Phil Carmody, Aug 20, 2013
  11. Agreed. I'd like same way to kill diagnostics without altering the
    source. Once you've checked that a message does not indicate an error,
    you should be able to mark it to be hidden in future . That way you can
    concentrate on any new messages from the build.

    I've done this, over the years, with tools like grep to filter the
    messages, but that's always rather fragile. It might be better to
    supply the compiler with a kill file, or to write a tool specifically to
    filter the output. If you include a code for the warning, the file and
    line number that provoked it, along with a trivial hash of that line,
    the tool (or compiler) can suppress warnings provided the line is not
    edited. It's probably not too many lines in some good scripting
    language, but I should have done it when I had a real need. There's no
    motivation now.

    Ben Bacarisse, Aug 20, 2013
  12. C11

    _Noreturn void exit(int status);

    The *implementation* should know the return semantics of the functions
    it defines, including both ISO standard functions and others. It makes
    sense to encode that information in the declarations of those functions.

    If you mean that the programmer shouldn't have to add those annotations,
    I agree.

    But then again, if we programmers never had to do anything that we
    "shouldn't" have to do, we might be out of a job.

    Keith Thompson, Aug 20, 2013
  13. Malcolm McLean

    Ian Collins Guest

    Unless you are one of the maintainers of those files...
    They weren't mindlessly tweaking code, they were simply leveling the
    playing field for the two compilers commonly used on Solaris. The file
    that was updated "contains definitions designed to enable different
    compilers to be used harmoniously".
    Ian Collins, Aug 20, 2013
  14. Malcolm McLean

    Phil Carmody Guest

    We are in firm agreement on all points. (Modulo Ian's "unless you're the
    the implementor" rider.)
    5 weeks and counting... :-\

    Phil Carmody, Aug 23, 2013
    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.