«

On 2012-01-18, Joachim Schmitz <> wrote:
> io_x wrote:
>> afther say that, i kill file you and Ian Collins

> They will be deeply impressed.

Man. Now I want to know what I have to say to get io_x to kill file me.

-s
--
Copyright 2011, all wrongs reversed. Peter Seebach / usenet-
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

On 2012-01-18, Kaz Kylheku <> wrote:
> On 2012-01-18, Seebs <usenet-> wrote:
>> It's more subtle than that, apparently, and was most recently fixed in January
>> of 2007. Looking at it, it appears that all the standard stuff in bash's
>> configure uses a value bash_cv_job_control_missing, which would normally be
>> set to either "present" or "missing". We had a build file which was setting it
>> to "no", but was not setting it in the right way; it looks to me as though
>> the intent had been the logical equivalent of:
>> bash_cv_job_control_missing=no configure <args>
>> but it ended up working as though it were:
>> bash_cv_job_control_missing=no
>> configure <args>

> Ah, let me guess, missing backslash?

Nothing so obvious! In the original it was Makefile variables, then we moved
to an SRPM package, and the SRPM package had
bash_cv_job_control_missing=no \
%configure [...]

and apparently this doesn't work, but changing it to "export" does. I don't
know the definition of %configure, but I'm guessing it was the underlying
mechanic.

.... I know none of this is really relevant to C, but it *is* somewhat relevant
to the question of why cross-compilation can be hard, and why I hate autoconf.
Stuff like this requires you to ensure that certain values are stashed in
environment variables or cache files, and that can be a nightmare to maintain.

I think experience with portability stuff like this is a great thing for any C
programmer. People who haven't had to deal with this are often quite quick to
carefully write multiple versions of something that each make unportable
assumptions; experience with this teaches the value of figuring out how to write
something that is portable in that it works everywhere, rather than in that it
works in three specific places.

I occasionally see people making things "portable" by doing things like:

#ifdef BIG_ENDIAN
#ifdef INT_32_BITS
if (((char *) x)[3] == 23) {
/* ... */
}
#else
if (((char *) x)[7] == 23) {
/* ... */
}
#endif
#else
if (((char *) x)[0] == 23) {
/* ... */
}
#endif

I would rather see:
if ((x & 0xff) == 23) {
/* ... */
}

-s
--
Copyright 2011, all wrongs reversed. Peter Seebach / usenet-
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

On 01/22/12 10:32 AM, Seebs wrote:
> On 2012-01-18, Joachim Schmitz<> wrote:
>> io_x wrote:
>>> afther say that, i kill file you and Ian Collins
>
>> They will be deeply impressed.
>
> Man. Now I want to know what I have to say to get io_x to kill file me.

The truth!

--
Ian Collins