Q: FICS code and 64-bit (va_list)

[Daniel White]

"As these functions invoke the va_arg macro, the value of ap after the return is unspecified."

Maybe you are calling two or more of these functions without calling va_start again.

This was exacly the problem. Thanks for pointing me in the right direction!

I removed the first call to vsnprintf, and just set the size n+1 to 8000. Now the ICS starts without errors, and I could logon to it.

Could of course be that similar problems exist elsewhere in the code; I will meticulously go through it for uses of va_lists to make sure they are only used once.

Something like this should work (and avoid the '8000' hack):

Code: Select all

/* a vasprintf wrapper */ 
int m_vasprintf(char **strp, const char *fmt, va_list ap) 
{ 
  int n; 
  
  (*strp) = NULL; 
  va_list ap2;
  va_copy(ap2, ap);
  
  n = vsnprintf(NULL, 0, fmt, ap2);
  va_end(ap2);
  if (n == 0) return 0;
  
  (*strp) = m_malloc(n+1); 
  n = vsnprintf(*strp, n+1, fmt, ap);
   
  return n; 
}

[Evert]

Problem is that I normally get thousands of compiler warnings, when doing "make".

I sympathise.
Perhaps put it on a longer-term todo list if you've solved the problem for now. Many of those warnings could be bugs just waiting to bite a little down the line...

[syzygy]

This CentOS is a bit fishy anyway: make install did crash on it not being case sensitive in file names, so that the command "cp [a-z]* ..." also tried to copy the directory CVS, which produced a fatal error.

What filesystem is being used there? FAT?

[UncombedCoconut]

Problem is that I normally get thousands of compiler warnings, when doing "make". I will try to see if the -m32 helps, though.

This CentOS is a bit fishy anyway: make install did crash on it not being case sensitive in file names, so that the command "cp [a-z]* ..." also tried to copy the directory CVS, which produced a fatal error.

Something is broken. Unix has always been case-sensitive. the regular expression "[a-z]*" should NEVER match a file name that does not start with a lowercase alphabetic character, and doesn't on my fedora systems. We did run centos on our lab machines that use unix and I never noticed that being broken, so something is definitely wrong.

Not true. The behavior is locale-dependent.

Code: Select all

[justinb@coconut ~]$ LANG=C sh -c 'ls -d [a-c]*'
barndiagonal.mov  caz  chess  code  convert.sh
[justinb@coconut ~]$ LANG=en_US.utf-8 sh -c 'ls -d [a-c]*'
barndiagonal.mov  BlocksThatMatterUserDatas  BlocksThatMatterUserDatas.7z  BlocksThatMatterUserDatas-justin  BotaniculaSaves  caz  chess  code	convert.sh

(Note that the changes are in how sorting and character ranges work. For instance, "ls C*" will never turn up chess, and more importantly the filenames "chess" and "Chess" are still different.)

[bob]

Problem is that I normally get thousands of compiler warnings, when doing "make". I will try to see if the -m32 helps, though.

This CentOS is a bit fishy anyway: make install did crash on it not being case sensitive in file names, so that the command "cp [a-z]* ..." also tried to copy the directory CVS, which produced a fatal error.

Something is broken. Unix has always been case-sensitive. the regular expression "[a-z]*" should NEVER match a file name that does not start with a lowercase alphabetic character, and doesn't on my fedora systems. We did run centos on our lab machines that use unix and I never noticed that being broken, so something is definitely wrong.

Not true. The behavior is locale-dependent.

Code: Select all

[justinb@coconut ~]$ LANG=C sh -c 'ls -d [a-c]*'
barndiagonal.mov  caz  chess  code  convert.sh
[justinb@coconut ~]$ LANG=en_US.utf-8 sh -c 'ls -d [a-c]*'
barndiagonal.mov  BlocksThatMatterUserDatas  BlocksThatMatterUserDatas.7z  BlocksThatMatterUserDatas-justin  BotaniculaSaves  caz  chess  code	convert.sh

(Note that the changes are in how sorting and character ranges work. For instance, "ls C*" will never turn up chess, and more importantly the filenames "chess" and "Chess" are still different.)

Doesn't explain how his copy [a-z]* would copy ANY file that started with C. Obviously that RE matches any file that starts with lowercase a-z, but I am not aware of any locale changes that would make it case insensitive, as Unix has always been completely case sensitive.

[bob]

This CentOS is a bit fishy anyway: make install did crash on it not being case sensitive in file names, so that the command "cp [a-z]* ..." also tried to copy the directory CVS, which produced a fatal error.

What filesystem is being used there? FAT?

Got to be one of the extN options. Ext3 as a first guess, perhaps ext4 if it is a recent centos distro.

Not sensitive to power failures / hard resets, finally.

[UncombedCoconut]

Problem is that I normally get thousands of compiler warnings, when doing "make". I will try to see if the -m32 helps, though.

This CentOS is a bit fishy anyway: make install did crash on it not being case sensitive in file names, so that the command "cp [a-z]* ..." also tried to copy the directory CVS, which produced a fatal error.

Something is broken. Unix has always been case-sensitive. the regular expression "[a-z]*" should NEVER match a file name that does not start with a lowercase alphabetic character, and doesn't on my fedora systems. We did run centos on our lab machines that use unix and I never noticed that being broken, so something is definitely wrong.

Not true. The behavior is locale-dependent.

Code: Select all

[justinb@coconut ~]$ LANG=C sh -c 'ls -d [a-c]*'
barndiagonal.mov  caz  chess  code  convert.sh
[justinb@coconut ~]$ LANG=en_US.utf-8 sh -c 'ls -d [a-c]*'
barndiagonal.mov  BlocksThatMatterUserDatas  BlocksThatMatterUserDatas.7z  BlocksThatMatterUserDatas-justin  BotaniculaSaves  caz  chess  code	convert.sh

(Note that the changes are in how sorting and character ranges work. For instance, "ls C*" will never turn up chess, and more importantly the filenames "chess" and "Chess" are still different.)

Doesn't explain how his copy [a-z]* would copy ANY file that started with C. Obviously that RE matches any file that starts with lowercase a-z, but I am not aware of any locale changes that would make it case insensitive, as Unix has always been completely case sensitive.

Sure it does. The shell is interpreting the pattern (just as it did on my box when deciding what args to pass to ls). Shell glob patterns aren't exactly REs; they are constructs interpreted according to the shell's documentation. Relevantly (for bash):

Code: Select all

              [...]  Matches any one of the enclosed characters.   A  pair  of
                     characters  separated by a hyphen denotes a range expres‐
                     sion; any character that sorts between those two  charac‐
                     ters,  inclusive,  using  the  current locale's collating
                     sequence and character set, is  matched.   If  the  first
                     character following the [ is a !  or a ^ then any charac‐
                     ter not enclosed is matched.  The sorting order of  char‐
                     acters  in range expressions is determined by the current
                     locale and the value of the LC_COLLATE shell variable, if
                     set.   A - may be matched by including it as the first or
                     last character in the set.  A ] may be matched by includ‐
                     ing it as the first character in the set.

So the ordering that says what the range [a-z] is doesn't have to be ASCII, and in common cases it isn't.

[hgm]

This CentOS is a bit fishy anyway: make install did crash on it not being case sensitive in file names, so that the command "cp [a-z]* ..." also tried to copy the directory CVS, which produced a fatal error.

What filesystem is being used there? FAT?

Well, I really don't know anything about CentOS or the system at all. It is a VPS that I heve been given the password for, and I access through ssh. I had never heard of CentOS, and don't even know it is a genuine Linux, or just a look-alike like Cygwin. In Cygwin I don't have case sensitivity.

Maybe it is indeed a FAT system. I understand that on a VPS you would be able to configure your own system. I have no idea why anyone would choose FAT for file system, but perhaps they did.

One thing is sure, though: I could not get the 'make install' for the ICS to complete without first deleting all the CVS directories from the source tree.

[UncombedCoconut]

This CentOS is a bit fishy anyway: make install did crash on it not being case sensitive in file names, so that the command "cp [a-z]* ..." also tried to copy the directory CVS, which produced a fatal error.

What filesystem is being used there? FAT?

Well, I really don't know anything about CentOS or the system at all. It is a VPS that I heve been given the password for, and I access through ssh. I had never heard of CentOS, and don't even know it is a genuine Linux, or just a look-alike like Cygwin. In Cygwin I don't have case sensitivity.

Maybe it is indeed a FAT system. I understand that on a VPS you would be able to configure your own system. I have no idea why anyone would choose FAT for file system, but perhaps they did.

One thing is sure, though: I could not get the 'make install' for the ICS to complete without first deleting all the CVS directories from the source tree.

CentOS is a popular derivative of Red Hat Enterprise Linux. You technically could use a case-insensitive file system for /home on just about any Linux distribution, but it's a foolhardy decision and you'd have to go well out of your way to make it. On the other hand, modern systems will often set a UTF-8 locale by default, which is why I offered that explanation.

This is an aside for anyone who's really curious about this side issue. (I was.) Being in a case-insensitive file system doesn't even make a matches like "[a-z]*" case-insensitive! When the shell matches patterns, it doesn't really know the details of the underlying file system. Here's the experiment I ran:

Code: Select all

[root@coconut ~]# LANG=C
[root@coconut ~]# dd if=/dev/zero of=fs_image count=1024
1024+0 records in
1024+0 records out
524288 bytes (524 kB) copied, 0.0048851 s, 107 MB/s
[root@coconut ~]# mkfs.vfat fs_image 
mkfs.vfat 3.0.12 (29 Oct 2011)
[root@coconut ~]# mkdir mount_point
[root@coconut ~]# mount -o loop fs_image mount_point
[root@coconut ~]# cd mount_point/
[root@coconut mount_point]# touch a A b B
[root@coconut mount_point]# ls
a  b
[root@coconut mount_point]# ls [a-z]*
a  b
[root@coconut mount_point]# ls [A-Z]*
ls: cannot access [A-Z]*: No such file or directory

The "touch" command only created two files, since I was in a case-insensitive filesystem. But [A-Z]* didn't match anything, because the two files in there reported lower-case names. If a program tried to open "A", though, it would open "a".
Moral: Unix tools + case-insensitive file systems can lead to brain damage.

[syzygy]

Problem is that I normally get thousands of compiler warnings, when doing "make". I will try to see if the -m32 helps, though.

This CentOS is a bit fishy anyway: make install did crash on it not being case sensitive in file names, so that the command "cp [a-z]* ..." also tried to copy the directory CVS, which produced a fatal error.

Something is broken. Unix has always been case-sensitive. the regular expression "[a-z]*" should NEVER match a file name that does not start with a lowercase alphabetic character, and doesn't on my fedora systems. We did run centos on our lab machines that use unix and I never noticed that being broken, so something is definitely wrong.

Not true. The behavior is locale-dependent.

Code: Select all

[justinb@coconut ~]$ LANG=C sh -c 'ls -d [a-c]*'
barndiagonal.mov  caz  chess  code  convert.sh
[justinb@coconut ~]$ LANG=en_US.utf-8 sh -c 'ls -d [a-c]*'
barndiagonal.mov  BlocksThatMatterUserDatas  BlocksThatMatterUserDatas.7z  BlocksThatMatterUserDatas-justin  BotaniculaSaves  caz  chess  code	convert.sh

(Note that the changes are in how sorting and character ranges work. For instance, "ls C*" will never turn up chess, and more importantly the filenames "chess" and "Chess" are still different.)

Doesn't explain how his copy [a-z]* would copy ANY file that started with C. Obviously that RE matches any file that starts with lowercase a-z, but I am not aware of any locale changes that would make it case insensitive, as Unix has always been completely case sensitive.

Sure it does. The shell is interpreting the pattern (just as it did on my box when deciding what args to pass to ls). Shell glob patterns aren't exactly REs; they are constructs interpreted according to the shell's documentation. Relevantly (for bash):

Code: Select all

              [...]  Matches any one of the enclosed characters.   A  pair  of
                     characters  separated by a hyphen denotes a range expres‐
                     sion; any character that sorts between those two  charac‐
                     ters,  inclusive,  using  the  current locale's collating
                     sequence and character set, is  matched.   If  the  first
                     character following the [ is a !  or a ^ then any charac‐
                     ter not enclosed is matched.  The sorting order of  char‐
                     acters  in range expressions is determined by the current
                     locale and the value of the LC_COLLATE shell variable, if
                     set.   A - may be matched by including it as the first or
                     last character in the set.  A ] may be matched by includ‐
                     ing it as the first character in the set.

So the ordering that says what the range [a-z] is doesn't have to be ASCII, and in common cases it isn't.

Amazing, even on my computer [a-z]* matches CVS...
Indeed LANG is set to en_US.UTF-8.