Chris Shoemaker schrieb:
On Mon, Dec 05, 2005 at 03:39:35PM -0500, Christian Stimming wrote:
#if VFAT_DOESNT_SUCK /* chown always fails on vfat fs */
-g_free(tmp_name);
-return FALSE;
+/* g_free(tmp_name);
+ return FALSE; */
#endi
Christian Stimming <[EMAIL PROTECTED]> writes:
> Chris Shoemaker schrieb:
>> On Mon, Dec 05, 2005 at 03:39:35PM -0500, Christian Stimming wrote:
>>
>>> #if VFAT_DOESNT_SUCK /* chown always fails on vfat fs */
>>>-g_free(tmp_name);
>>>-return FALSE;
>>>+
Tim Wunder <[EMAIL PROTECTED]> writes:
> OK. But does it try to chown the new file? This still seems to be a
> function for the O/S, and the permissions on the directory. It seems
> to me that an app shouldn't be concerned with file ownership when
> creating a file.
Yes and no. Yes it runs chown
FTR, below is the (slightly edited) IRC discussion of this issue.
warlord: re errno: If there were an ENOENT, then the chmod()
before would have signalled an error already.
Ahh, I see. If the save() failed it then checks.. it only
falls into the chown/chmod if the save fails and the stat()
On Mon, 2005-12-05 at 18:28 -0500, Chris Shoemaker wrote:
> The C-language rule is "always cast NULL when used as a sentinel to a
> variadic function, otherwise you're accidentally passing integer
> zero, which is wrong."
I think that's bogus. NULL should always be a pointer (void *)0, and if
it'
On Mon, 2005-12-05 at 21:25 -0500, Chris Shoemaker wrote:
> If NULL is ((void*)0) you won't have any problem using NULL as a
> sentinel, but using that definition of NULL opens up the possibility
> of writing code that works with one implementation and not with
> another. Specifically, you couldn'
On Tue, 2005-12-06 at 00:55 -0500, Chris Shoemaker wrote:
> In the gcc ML thread where the -Wstrict-null-sentinel warning was
> added, it was claimed that at least some versions of HPUX and Solaris
> 2.8 on 64-bit machines #define NULL 0.
Then those system headers are wrong, not the code that uses
Derek Atkins <[EMAIL PROTECTED]> writes:
> Quoting Chris Shoemaker <[EMAIL PROTECTED]>:
>
>> Meta-comment for list maintainer:
>>
>> Can we please set ReplyTo on -patches mail to be gnucash-devel?
>
> Done.
Er.. I missed a radio-button. It should /really/ be fixed now.
Sorry.
-derek
--
On Tue, 2005-12-06 at 08:43 -0800, Karl Hegbloom wrote:
> On Mon, 2005-12-05 at 21:25 -0500, Chris Shoemaker wrote:
> > If NULL is ((void*)0) you won't have any problem using NULL as a
> > sentinel, but using that definition of NULL opens up the possibility
> > of writing code that works with one i
I was taught to maintain ChangeLog as I edit. In Emacs, you type:
C-x 4 a
... to add a ChangeLog entry. (Will a vim user please explain the
process used? Does it automatically insert a ChangeLog entry template
with the ISO-8601 date, file name, and function?) So for each change
you make, yo
On Tue, Dec 06, 2005 at 08:46:00AM -0800, Karl Hegbloom wrote:
> On Tue, 2005-12-06 at 00:55 -0500, Chris Shoemaker wrote:
> > In the gcc ML thread where the -Wstrict-null-sentinel warning was
> > added, it was claimed that at least some versions of HPUX and Solaris
> > 2.8 on 64-bit machines #defi
On Tue, Dec 06, 2005 at 08:43:21AM -0800, Karl Hegbloom wrote:
> On Mon, 2005-12-05 at 21:25 -0500, Chris Shoemaker wrote:
> > If NULL is ((void*)0) you won't have any problem using NULL as a
> > sentinel, but using that definition of NULL opens up the possibility
> > of writing code that works wit
On Tue, 6 Dec 2005, Chris Shoemaker wrote:
> > A pointer to a char is the same size as a pointer to an int and is the
> > same size as a pointer to void.
>
> This is not generally true for typed null pointers. Implementations
> are free to use different representations for null pointers of
> d
[Testing Reply-to from -patches. Looks good Derek.]
On Tue, Dec 06, 2005 at 05:06:24PM -0500, Joshua Sled wrote:
> Author: jsled
> Date: 2005-12-06 17:06:22 -0500 (Tue, 06 Dec 2005)
> New Revision: 12139
> Trac: http://svn.gnucash.org/trac/changeset/12139
>
> Modified:
>gnucash/trunk/lib/gof
Quoting Chris Shoemaker <[EMAIL PROTECTED]>:
Josh,
I'm curious. How are you catching these? I have to use
"-Wno-uninitialized" because of some gw_engine.c crap, so I'd never
see this.
It was mentioned on IRC. Tim Wunder saw it on his machine with
gcc-4.0.2. Why do you have to use -
On Tue, Dec 06, 2005 at 05:31:47PM -0500, Derek Atkins wrote:
> Quoting Chris Shoemaker <[EMAIL PROTECTED]>:
>
> >Josh,
> > I'm curious. How are you catching these? I have to use
> >"-Wno-uninitialized" because of some gw_engine.c crap, so I'd never
> >see this.
>
> It was mentioned on IR
Quoting Chris Shoemaker <[EMAIL PROTECTED]>:
On Tue, Dec 06, 2005 at 05:31:47PM -0500, Derek Atkins wrote:
Quoting Chris Shoemaker <[EMAIL PROTECTED]>:
>Josh,
> I'm curious. How are you catching these? I have to use
>"-Wno-uninitialized" because of some gw_engine.c crap, so I'd never
>
On Tue, 2005-12-06 at 16:07 -0500, Chris Shoemaker wrote:
> Yes, this *works*! IFF NULL expands to "0". But, it's not portable
> because NULL *may* expand to (void*)0. This is *exactly* why using
> "NULL" (or even "0") as a sentinel is not portable. Portable code
> *must* explicitly cast sentin
On Tue, 6 Dec 2005, Karl Hegbloom wrote:
> After reading what Stuart D. Gathman wrote in this thread, I'm thinking
> that it's not Ritchie's fault either. It's a matter of mapping the C
> language to the hardware and it's assembly language.
Ritchie could have made nil/null an actual language key
On Sun, 2005-12-04 at 23:19 -0800, Karl Hegbloom wrote:
> On Sat, 2005-12-03 at 11:55 -0500, Josh Sled wrote:
> > Thanks to the efforts of Neil and Derek, the goffice-update branch is
> > pretty robust at this point, except for issues on 64-bit platforms.
> > However, since I understand those issue
I never published my notes about moving the CVS repository to SVN...
The basics are covered in all the applicable documentation, though
there's are some things I distilled out, primarily around cvs2svn.
cvs2svn is seperately available from http://cvs2svn.tigris.org/ but has
not-quite-direct docs
On Sat, 2005-12-03 at 01:21 -0500, Volker Englisch wrote:
> Testing continues with the File --> Open menu option:
> - I'm not sure if this is intended but just in case it is not I
>wanted to mention it:
>When I have the main Accounts window open I see the following
>sub menus listed
>
22 matches
Mail list logo
