Baby X

[Edward A. Falk]

On Sat, 2013-08-03, Malcolm McLean wrote:

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

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]

Or a SourceForge project or equivalent. They're not *that* much work to
set up, and they're worth it in the long run.

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.

Screenshot: http://imgur.com/EiqIDEb

It needs work, of course.

 

[Malcolm McLean]

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.


Screenshot: http://imgur.com/EiqIDEb



It needs work, of course.

I've just put the latest version on my website.
It's been walled, so it now compiles cleanly with all warnings set, which
was the main comment people made. I've also put a wrapper round the memory
allocation, so it now exits on out-of-memory conditions instead of
segfaulting.

I'll roll it out to sourceforge shortly.

I'd certainly like to look at your project. As you said, it's not obvious
what to put in and what to leave out of an X toolkit. There's not much point
just providing a thin layer to wrap X calls. On the other hand, a fully-
fledged high level toolkit is hard to get right.

 

[Philip Lantz]

You *could* require all possible execution paths for a non-void
function to lead to a return statement. C doesn't currently require
that kind of compile-time analysis, but it's not all that difficult
to do, and I think I've seen at least one language that requires it.

So this:

int func(void) {
if (cond) {
return 1;
}
}

would be a constraint violation, but this:

int func(void) {
if (cond) {
return 1;
}
else {
return 0;
}
}

would be valid, since the compiler can prove that the closing } is never
reached. The compiler wouldn't be required to analyze the evaluation of
"cond"; even if it's a constant expression, it would still check for
returns on all paths.

It's already entirely possible for a compiler to warn about such things.

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.

 

[James Kuyper]

On 08/18/2013 01:31 AM, Philip Lantz wrote:
....

unless you also add a noreturn attribute.

Too late - _Noreturn was added in C2011. You can use noreturn as an
equivalent, so long as you #include <stdnoreturn.h> first.

 

[Ike Naar]

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.

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

 

[James Kuyper]

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

That's not what I thought Philip was suggesting. It would, of course, be
inappropriate for the reasons you give below.

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

Yes, and applying _Noreturn to the declaration of cleanup_and_exit()
should enable that.

 

[Ike Naar]

Yes, and applying _Noreturn to the declaration of cleanup_and_exit()
should enable that.

Ah yes. Okay.

 

[Ian Collins]

You *could* require all possible execution paths for a non-void function
to lead to a return statement. C doesn't currently require that kind of
compile-time analysis, but it's not all that difficult to do, and I
think I've seen at least one language that requires it.

I recently stumbled upon an interesting blog entry from one of the X.Org
developers regarding the work such changes can entail:

https://blogs.oracle.com/alanc/entry/solaris_11_1_changes_handling

 

[Phil Carmody]

I recently stumbled upon an interesting blog entry from one of the
X.Org developers regarding the work such changes can entail:

https://blogs.oracle.com/alanc/entry/solaris_11_1_changes_handling

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

 

[Ben Bacarisse]

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.

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.

<snip>

 

[Keith Thompson]

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.

C11 7.22.4.4:

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

[...]

 

[Ian Collins]

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.

Unless you are one of the maintainers of those files...

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.

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

 

[Phil Carmody]

C11 7.22.4.4:

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

We are in firm agreement on all points. (Modulo Ian's "unless you're the
the implementor" rider.)

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.

5 weeks and counting... :-\

Phil