Mail #11279

Back to main page of archive

Previous mail   Next mail   Unformatted/full headers
Overview  10 days   Subject   Date   Thread   Author  

From: Frank Heckenbach
Subject: compiling-update
Date: 26 Jan 2005, 17:56:06

jan.ruzicka@comcast.net wrote:

> Lets split it into blocks:
> 1)   gcc dummy.c > /dev/null 2>&1
> compiles dummy.c and redirects output (stdout,stderr) to /dev/null (bit 
> bucket)

Yes, because failure doesn't necessarily mean a problem with GPC,
but perhaps just that the German locale is not installed, and the
test should be skipped.

> 2)  [ -r "$A_OUT" ]
> test if $A_OUT exists and is readable.

Yes, perhaps superfluous since the next step would fail as well, but
shouldn't hurt.

> 3)   x"`./"$A_OUT" 2> /dev/null`" = x"ƒ"
> test if $A_OUT outputs ƒ
> 3.a) `./"$A_OUT" 2> /dev/null`
> execute $A_OUT and redirect stderr to /dev/null
> 3.b) compare outputs
> 
> I would suggest rewrite the conditions to a multiple lines/blocks.
> something like :
> -------------------------------------------------------
> gcc dummy.c > /dev/null 2>&1
> if [ ! $? ]; then
>       echo "failed: can not compile the test C code"
>       exit(1)
> fi

Generally, I wouldn't object, but I find `||' easier to read (and
more common, in shell scripts) than `[ ! $? ]'. (I'm generally a bit
wary of `$?' because it adds an inter-statement dependency; adding
something between the lines can cause non-obvious problems. So I
rather don't use `$?' unless really necessary.)

> if [ ! -r $A_OUT ]; then
>       echo "failed: can not read the test C code"

The compiled program, BTW.

>       exit(1)

Shouldn't it be `exit 1'?

Also, I'd generally quote all variables in shell scripts unless
explicitly meant not to. Though $A_OUT is probably harmless,
anything that might contain a directory might also contain spaces
nowadays, e.g. ...

> printf "\x80" > ./${A_OUT}2.dat
> 
> comparison can be also
> ./$A_OUT 2> /dev/null | hexdump >./$A_OUT.dat
> # ... file tests as previous
> diff./$A_OUT.dat <<EOF
> 0000000 8000
> 0000001
> EOF

Now, this is the actually tricky part. Apart from the fact that I'm
not sure if we should require hexdump as a dependency, 80 is at
least not the most common character code for A-umlaut.

> Question is what exactly are we testing?
> 
> Are we testing that the compiler, shell and function toupper can work 
> with non ASCII characters [in this case A umlaut]?
>    printf ("%c\n", toupper ((unsigned char) '‰'));
> or

We shouldn't really test the shell.

> Are we testing the ability of toupper converting a non ASCII character ?
>    printf ("%c\n", toupper ((unsigned char) 0x80));
>
> Is there any standard and portable way to obtain a selected localized
> letter?
> Example get platform representation of A-umlaut or u-circle.
> 
> The issue here is that different platforms can have different encoding 
> of the character.
> Unicode vs. Latin-1, Windows etc.

Exactly.

Well, we can surely remove the shell non-ASCII dependency. E.g., we
can check the result within the C program and output 1 if it
matches:

  printf ("%i\n", toupper ((unsigned char) 'ä') == (unsigned char) 'Ä');

[...]

if gcc dummy.c > /dev/null 2>&1 && [ -r "$A_OUT" ] && [ x"`./"$A_OUT" 2> /dev/null`" = x"1" ]; then

If we then move the C program to a separate file, the shell won't
have to deal with those characters. E.g., put it in fjf165a.c and
put this in the script:

#!/bin/sh

# Try setting German locale (locally ;-)
#
# Which variables do we really need to set? (Probably not all of
# these, but better be safe than sorry. ;-)
#
# The complicated redirecting is necessary on Solaris' shell which
# otherwise would give messages "couldn't set locale correctly"
# in the variable assignments that can't seem to be redirected
# normally.

exec 3>&2 2> /dev/null
LC_ALL=de_DE; export LC_ALL
LC_CTYPE=de_DE; export LC_CTYPE
LANG=de_DE; export LANG
exec 2>&3

# Test if German locale actually works (i.e., whether the locale
# database is installed on the system)
if gcc "`dirname "$2"`"/fjf165a.c > /dev/null 2>&1 && [ -r "$A_OUT" ] &&
   [ x"`./"$A_OUT" 2> /dev/null`" = x"1" ]; then
  rm -f "$A_OUT"
  $1 $2
  if [ -r "$A_OUT" ] ; then
    ./"$A_OUT"
  else
    echo "failed"
  fi
else
  echo "SKIPPED: German locale not installed"
fi

Then we've restricted those characters to the compilers which should
at least read them. If they don't treat them as expected
(Latin[129]/Unicode), the test will be skipped which is acceptable.
If someone would like to add support for other charsets in
fjf165a.{c,pas}, go ahead, but note that the main problem might be
to find a suitable test for the current charset (a system
conditional probably won't suffice).

Frank

Previous mail   Next mail   Unformatted/full headers
Overview  10 days   Subject   Date   Thread   Author  

Replies

In reply to

Back to main page of archive

Note: This page contains information that does not originate from the owner of this web site, but from the authors of the mails archived. The owner of this web site is not responsible for the content of such information. Any use of that infomation requires the consent of the respective author.

Where WWW addresses (URLs) in the mails archived are marked as hyperlinks, this is only for the comfort of the reader. The content of the web pages linked to like this does not necessarily reflect the opinion of the owner of this web site or of the authors of the mails archived. The owner of this web site is not responsible for the content of such web pages. Those pages are explicitly not to be considered as part of the content of this page, but merely as references.

This page was created by Crystal 0.999 (Linux 2.4.27/i686).