Baby X

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

  1. I proudly announce Baby X v0.0, the baby X windows toolkit. It's a prototype version, usable and with the central features present.

    The goal is to keep Baby X small, so that it's natural to distribute it with
    projects as C source. But it also needs to support everything that a
    writer of small windowing programs would want. I'm trialling it with the
    comp.lang.c community before putting it out to a wider public, on the basis
    that any design flaws can be addressed at this stage.
    Its currently available only for xlib. One issue is whether it's sensible to
    produce a Windows version.

    The project is available at

    click on the Baby X link.
    Malcolm McLean, Aug 4, 2013
    1. Advertisements

  2. Malcolm McLean

    Jorgen Grahn Guest

    A Git repository would have been nice. Or failing that, a tar.gz
    archive instead of a .zip.

    Also, the PDF seems broken. Neither Ghostscript nor evince can
    display it.

    (I'm not in the market for an X toolkit -- I gave up on GUI
    programming a long time ago -- but found this intriguing.)

    Jorgen Grahn, Aug 4, 2013
    1. Advertisements

  3. Malcolm McLean

    BartC Guest

    So is the ZIP file.
    BartC, Aug 4, 2013
  4. I accidentally transferred the to the server using text mode.
    Try now.
    I've also added a .tar.gz
    Malcolm McLean, Aug 4, 2013
  5. Also, the PDF seems broken. Neither Ghostscript nor evince can
    I could open all three (.pdf, .tar.gz, .zip,) without any problem.
    (Using 7-Zip & SumatraPDF)
    Roberto Waltman, Aug 4, 2013
  6. "compileme.txt" says to compile with

    gcc *.c -lX11

    which compiles with no warnings. But when I try:

    gcc -std=c99 -pedantic -Wall -Wextra -O3 *.c -lX11

    I get 552 lines of warnings. You might want to take a look at those.
    Keith Thompson, Aug 4, 2013
  7. Malcolm McLean

    Ian Collins Guest

    You might want to fix up all of the signed/unsigned mismatches with your
    depth parameter.
    Ian Collins, Aug 4, 2013
  8. A lot of those are caused by signed / unsigned mismatches. But putting in
    casts and unsigned types isn't really solving the problem, just replacing
    messy warnings with messy, more error-prone code. We need signed types
    for indices because -1 is often either used as a null value, or generated
    as a post value. Signed types are safer for size calculations because they
    can trap if the size overflows.
    But I'll certainly look and see what can be suppressed.
    Malcolm McLean, Aug 5, 2013
  9. Signed types *can* trap on overflow, but in most implementations
    they don't; they just quietly wrap around. I suggest just using
    size_t for all sizes. If you need a special invalid size value,
    you can use (size_t)-1.
    Keith Thompson, Aug 5, 2013
  10. Malcolm McLean

    Ian Collins Guest

    Nonsense. Most of the warnings are down to you passing an int* to a
    depth return parameter. Depth in X can't be negative.
    Depth isn't an index.
    Tell that to the designers of the standard library (and X).
    Just fix, there's no need to suppress valid warnings.
    Ian Collins, Aug 5, 2013
  11. Unfortunately, a reasonably intelligent programmer can think that "this
    quantity cannot be negative, therefore it ought to be unsigned". He's almost
    always wrong. For instance pixel indices can't be negative when drawing, so
    draw_pixel() can take unsigned x, y. But in fact most calling code is going to
    generate intermediate values which can be negative, so it's a nuisance. This
    example is too obvious for most people to fall into the trap. It's valid to
    subtract one depth from another to yield a depth difference, so depth should
    be signed. It's a little glitch on X, but we have to live with it. We can't
    change the interface now.
    size_t is a disaster for the C language, and I've spoken against it on many
    occasions. I won't rehash the arguments here.
    But gcc doesn't give a warning by default.
    Whilst the code compiles cleanly if compiled according to the instructions,
    I agree there's a case for supporting a clean compile under stricter warnings,
    so that people can choose to use them if they find them useful. The warnings
    aren't valid, however, and the code is correct. They're noise.
    Malcolm McLean, Aug 6, 2013
  12. Malcolm McLean

    Ian Collins Guest

    No, you can't. So pass the correct types.
    It's also irrelevant to this discussion.
    gcc isn't a conforming compiler by default.
    The warnings are valid and will be generated by any conforming compiler,
    which makes you code at best annoying and at worse useless to anyone
    using a decent compiler.
    Ian Collins, Aug 6, 2013
  13. If code has defined behaviour which is correct, then warnings are noise.
    If suppressing the warnings means putting in constructs which are likely
    to confuse, and to lead to incorrect behaviour (eg inappropriate use of
    unsigned types for values which might yield negative results intermediate
    calculations), then you've got a balanced judgement to make.

    The underlying problem can't be solved now, because it's too late.
    Fortunately gcc doesn't give these inappropriate warnings when invoked
    in default mode, which should be the mode you use except in special
    circumstances. These is a case for supporting people who don't want to
    compile Baby X according to the instructions, I agree, but "I didn't
    follow the instructions and it worked but gave funny messages" isn't
    an especially strong complaint.
    Malcolm McLean, Aug 6, 2013
  14. Malcolm McLean

    Ian Collins Guest

    In all the cases I've seen, you don't use the depth parameter.
    One of the first rules of open source code is if you want people to use
    your code, make sure it compiles cleanly.
    Ian Collins, Aug 6, 2013
  15. Malcolm McLean

    Ike Naar Guest

    In addition to signed/unsigned warnings, there are other issues as well,
    e.g. calling functions without a prototype in scope (strcmp,
    XDestroyImage, etc.) (due to missing #include's),
    missing return statements in the body of functions
    returning non-void, etc.
    Ike Naar, Aug 6, 2013
  16. Some of those need fixing, yes.
    Malcolm McLean, Aug 6, 2013
  17. Yes, it's a X nuisance function, which returns far too much information
    when usually you simply want the size. Then it doesn't check for null,
    so you have to pass dummy paramters for the unwanted values. I'm considering
    wrapping it in a bbx_getsize() and stripping all those calls out.
    Most open source people will be using gcc, so I made it compile cleanly
    under gcc in default mode. That's central to the idea behind Baby X. I want
    to strip away all the funny flags and dependencies and configurations and
    pre-build steps.
    Malcolm McLean, Aug 6, 2013
  18. If you fix the code to remove most, maybe all, the warnings it will
    still compile clean in gcc's default mode.

    As I understand it, your goal is for Baby X to be compiled along with
    the client code. If so, you should make some effort to accommodate as
    wide a variety of compile flags as you can. It's exactly when you do
    have a separate build step for the library that you can pick and choose
    exactly how it should be compiled (but I've not been following closely
    so I may not have picked up on what your main goals are).
    Ben Bacarisse, Aug 7, 2013
  19. Malcolm McLean

    Ian Collins Guest

    Why are you so obsessed with not passing the correct type? Is it a case
    of dogma vs correctness?
    Hardly anyone (who knows what they are doing) uses gcc in its default
    mode. The customer site I was working at this morning always uses
    -werreor for example. Event adding the slightest whiff of conformance
    spews the warnings.
    Ian Collins, Aug 7, 2013
  20. It's a case of keeping clutter out of the Baby X code. Which keeping the
    types as simple as possible. Unsigned integers aren't wanted, they're
    just a nuisance, a source of confusion and complexity and bugs. However
    Baby X does have to call X, which sometimes uses them.
    It's not a case of obsession, just pointing out that the warnings are
    noise, and the roots of the issue lie elsewhere.
    It's a baby toolkit, so it uses babytalk. Which is gcc in default mode. But
    supporting other modes which don't break default mode is largely harmless.
    The only danger is that someone might extend it by putting in some construct
    which relies on the non-default mode, which is unlikely.
    Most of the warnings can probably be suppressed without any real issues,
    so it's worth doing that. I don't see it as a serious matter, however.
    Malcolm McLean, Aug 7, 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.