Baby X

[Malcolm McLean]

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
http://www.malcolmmclean.site11.com/www

click on the Baby X link.

 

[Jorgen Grahn]

I proudly announce Baby X v0.0, the baby X windows toolkit. [...]
....
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
http://www.malcolmmclean.site11.com/www

click on the Baby X link.

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

 

[BartC]

I proudly announce Baby X v0.0, the baby X windows toolkit. [...]
http://www.malcolmmclean.site11.com/www

click on the Baby X link.

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.

So is the ZIP file.

 

[Malcolm McLean]

I proudly announce Baby X v0.0, the baby X windows toolkit. [...]

http://www.malcolmmclean.site11.com/www
click on the Baby X link.

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.

So is the ZIP file.

I accidentally transferred the to the server using text mode.
Try now.
I've also added a .tar.gz

 

[Roberto Waltman]

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

So is the ZIP file.

I could open all three (.pdf, .tar.gz, .zip,) without any problem.
(Using 7-Zip & SumatraPDF)

 

[Keith Thompson]

I proudly announce Baby X v0.0, the baby X windows toolkit. [...]

http://www.malcolmmclean.site11.com/www

click on the Baby X link.

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.

So is the ZIP file.

I accidentally transferred the to the server using text mode.
Try now.
I've also added a .tar.gz

"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.

 

[Ian Collins]

I proudly announce Baby X v0.0, the baby X windows toolkit. [...]

http://www.malcolmmclean.site11.com/www

click on the Baby X link.

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.

So is the ZIP file.

I accidentally transferred the to the server using text mode.
Try now.
I've also added a .tar.gz

You might want to fix up all of the signed/unsigned mismatches with your
depth parameter.

 

[Malcolm McLean]

"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.

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.

 

[Keith Thompson]

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.

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.

 

[Ian Collins]

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.

Nonsense. Most of the warnings are down to you passing an int* to a
depth return parameter. Depth in X can't be negative.

We need signed types
for indices because -1 is often either used as a null value, or generated
as a post value.

Depth isn't an index.

Signed types are safer for size calculations because they
can trap if the size overflows.

Tell that to the designers of the standard library (and X).

But I'll certainly look and see what can be suppressed.

Just fix, there's no need to suppress valid warnings.

 

[Malcolm McLean]

Tell that to the designers of the standard library (and X).

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.

Just fix, there's no need to suppress valid warnings.

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.

 

[Ian Collins]

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.

No, you can't. So pass the correct types.

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.

It's also irrelevant to this discussion.

But gcc doesn't give a warning by default.

gcc isn't a conforming compiler 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.

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.

 

[Malcolm McLean]

Malcolm McLean wrote:


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.

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.

 

[Ian Collins]

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.

In all the cases I've seen, you don't use the depth parameter.

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.

One of the first rules of open source code is if you want people to use
your code, make sure it compiles cleanly.

 

[Ike Naar]

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.

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.

 

[Malcolm McLean]

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.

Some of those need fixing, yes.

 

[Malcolm McLean]

Malcolm McLean wrote:


In all the cases I've seen, you don't use the depth parameter.

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.

One of the first rules of open source code is if you want people to use
your code, make sure it compiles cleanly.

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.

 

[Ben Bacarisse]

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.

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).

 

[Ian Collins]

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.

Why are you so obsessed with not passing the correct type? Is it a case
of dogma vs correctness?

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.

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.

 

[Malcolm McLean]

Malcolm McLean wrote:


Why are you so obsessed with not passing the correct type? Is it a case
of dogma vs correctness?

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.

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.

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.