-
Same here.
Opening CHM files does nothing.
Same error in the Error console.
2009-02-19 20:29:10 UTC in CHM Reader
-
Changing the code to use stat64() instead of stat() appears to
fix the problem -- thought I still don't see why astyle needs
to be calling stat() for all the files in the current directory
when it was only give one file name to format.
2008-12-16 21:03:02 UTC in Artistic Style
-
While not testing the return value of stat() is, IMO, a bug, it's not causing the problem at hand. The problem is that
some of the files in the current directory have sizes too large to be handled by the stat() library call (files > 4GB).
I still don't understand why astyle doing a stat() on all those files.
2008-12-16 20:33:02 UTC in Artistic Style
-
$ astyle hello.c
stat errno message: Value too large for defined data type
Error getting file status in directory /home/grante
Looking at the code:
string entryFilepath = directory + g_fileSeparator + entry->d_name;
stat(entryFilepath.c_str(), &statbuf);
if (errno)
{
perror("stat errno message");
error("Error getting file status...
2008-12-16 20:23:42 UTC in Artistic Style
-
I'll try adding the perror()...
I did strace the execution, and it appears that when I do
"asytle hello.c", astyle does a stat64() on every file in the
current directory.
Why?
FWIW, It looks like all of the stat64 calls were successful,
though astyle bailed after 95 out of 147 files. Here's the
strace output:
execve("/usr/bin/astyle", ["astyle", "hello.c"], [/* 50 vars */]) = 0.
2008-12-16 20:10:19 UTC in Artistic Style
-
Running astyle 1.22 on a Gentoo IA32 system, I try to run
astyle on a trivial source file in my home directory and I get
this:
$ astyle hello.c
Error getting file status in directory /home/grante
$
$ ls -l hello.c
-rw-r--r-- 1 grante grante 70 Dec 15 14:16 hello.c
$ cat hello.c
#include
int main(void)
{
printf("Hello World!\n");
}
Running astyle in...
2008-12-15 20:29:19 UTC in Artistic Style
-
Fixed by patch 1722948.
http://sourceforge.net/tracker/index.php?func=detail&aid=1722948&group_id=17434&atid=317434.
2007-05-21 19:14:34 UTC in Gnuplot.py
-
Fix for [ 1703259 ] Failure on Win32 when CWD is a UNC path.
http://sourceforge.net/tracker/index.php?func=detail&aid=1703259&group_id=17434&atid=117434
Is there really no way to tie a patch to a bug?.
2007-05-21 19:11:32 UTC in Gnuplot.py
-
Gnuplot.Gnuplot() will fail to start a gnuplot process anytime
the current working directory (CWD) is a UNC path (e.g.
\\host\foo\bar) rather than a DOS path (e.g. V:\foo\bar). The
underlying cause is a "feature" of cmd.exe documented at
http://support.microsoft.com/kb/156276/EN-US/
The symptom of this is that when you try to execute gnuplot
commands, you get a traceback like this...
2007-04-18 21:28:48 UTC in Gnuplot.py
-
[sorry about the initial file add/delete confusion...]
fdata-sections.patch is a patch for the mspgcc 3.2.3 sources to add support for -fdata-sections
bss_dot_star-data_dot_star.patch is a patch for binutils 2.17 that modifies the MSP430 link script template to support -fdata-sections.
disable-ffunction-section_warning.patch is a patch for gcc-core-3.2.3 that disables the bogus warning...
2007-04-03 14:21:15 UTC in GCC toolchain for MSP430
