Mail #11284

Back to main page of archive

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

From: jan.ruzicka@comcast.net
Subject: compiling-update
Date: 27 Jan 2005, 00:10:39

if we move the locale test completely to the C test file why don't we 
return result (pass/fail) in the exit code?
-------------
#include <ctype.h>
#include <locale.h>
/* test for a correctly working locale.
  * for reference see:
  * http://czyborra.com/charsets/iso8859.html */
int main()
{ int rv = 0;
   setlocale (LC_ALL, "");
   rv = rv || (toupper ((unsigned char) 'ä') == (unsigned char) 'Ä'); /* 
text &auml; to &Auml; */
   rv = rv || (toupper ((unsigned char) 0xe4) == (unsigned char)  0xc4); 
/* codes for Latin[1-9] */
   return ( ! rv ); /* revert to the shell meaning of the logic 0 == 
true;  0 != false   */
}
-------------
This way the test can be just a return value:
  ./"${A_OUT}" > /dev/null 2>&1

Jan

On Jan 26, 2005, at 11:56, Frank Heckenbach wrote:

> jan.ruzicka@comcast.net wrote:
>>
>> 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.)
You have a valid point.

Should it be then:
------------
gcc dummy.c > /dev/null 2>&1 ||\
echo "SKIPPED: can not compile the test C code" && exit 1
------------

>> 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
>
> -- 
> Frank Heckenbach, frank@g-n-u.de, http://fjf.gnu.de/, 7977168E
> GPC To-Do list, latest features, fixed bugs:
> http://www.gnu-pascal.de/todo.html
> GPC download signing key: ACB3 79B2 7EB2 B7A7 EFDE  D101 CD02 4C9D 
> 0FE0 E5E8
>

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