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 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, 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
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, 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, 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
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 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
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 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 Tue, 2005-12-06 at 00:55 -0500, Chris Shoemaker wrote:
> Well, that's exactly why this warning was recently added to gcc, and
> why the glib and gtk+ sources were tagged with attribute((sentinel)).
> (Although that also has the benefit of catching no sentinel at all
> which is more important tha
On Mon, Dec 05, 2005 at 10:37:49PM -0500, David Hampton wrote:
> On Mon, 2005-12-05 at 22:19 -0500, Chris Shoemaker wrote:
>
> > Fair enough. I'll grab the original patch, remove redundant portions
> > and apply it. I'm convinced it's correct. I figure it's easier to
> > follow the standard tha
On Mon, 2005-12-05 at 21:25 -0500, Chris Shoemaker wrote:
> The #define NULL 0 case is explicitly allowed by the ISO C standard,
> and it's easy to write portable code that works for that case, so why
> wouldn't we?
I don't know for sure, but I strongly suspect that our code is already
limited to
On Mon, 2005-12-05 at 22:19 -0500, Chris Shoemaker wrote:
> Fair enough. I'll grab the original patch, remove redundant portions
> and apply it. I'm convinced it's correct. I figure it's easier to
> follow the standard than to figure out what weird systems people
> compile GnuCash on. ( I don'
Quoting Chris Shoemaker <[EMAIL PROTECTED]>:
On Mon, Dec 05, 2005 at 10:09:10PM -0500, David Hampton wrote:
On Mon, 2005-12-05 at 21:25 -0500, Chris Shoemaker wrote:
> The #define NULL 0 case is explicitly allowed by the ISO C standard,
> and it's easy to write portable code that works for tha
On Mon, Dec 05, 2005 at 10:09:10PM -0500, David Hampton wrote:
> On Mon, 2005-12-05 at 21:25 -0500, Chris Shoemaker wrote:
>
> > The #define NULL 0 case is explicitly allowed by the ISO C standard,
> > and it's easy to write portable code that works for that case, so why
> > wouldn't we?
>
> I do
On Mon, Dec 05, 2005 at 08:39:15PM -0500, David Hampton wrote:
> On Mon, 2005-12-05 at 18:28 -0500, Chris Shoemaker wrote:
> > On Mon, Dec 05, 2005 at 05:26:34PM -0500, Derek Atkins wrote:
> > >
> > > ... we're still trying to analyze the issue and figure out what's really
> > > going on. I.e., t
On Mon, 2005-12-05 at 18:28 -0500, Chris Shoemaker wrote:
> On Mon, Dec 05, 2005 at 05:26:34PM -0500, Derek Atkins wrote:
> >
> > ... we're still trying to analyze the issue and figure out what's really
> > going on. I.e., there's no plan to make any changes until we understand
> > the problem.
On Mon, Dec 05, 2005 at 06:28:00PM -0500, Chris Shoemaker wrote:
> You misunderstand me. This *is* a problem, and we *should* fix it.
> Our code is just *wrong*. It's wrong on 32-bit machines and on 64-bit
> machines. (Although it happens to be a benign bug anywhere ((char *)
> NULL) is a 32-bit
On Mon, Dec 05, 2005 at 05:26:34PM -0500, Derek Atkins wrote:
> Quoting Chris Shoemaker <[EMAIL PROTECTED]>:
>
> >On Mon, Dec 05, 2005 at 04:38:40PM -0500, Derek Atkins wrote:
> >>If you were on IRC you'd have more information on this.
> >>
> >>Yes, it is 64-bit only. The problem is that on some
Quoting Chris Shoemaker <[EMAIL PROTECTED]>:
On Mon, Dec 05, 2005 at 04:38:40PM -0500, Derek Atkins wrote:
If you were on IRC you'd have more information on this.
Yes, it is 64-bit only. The problem is that on some versions of gcc4
stddef.h #defined NULL as (int)0 which causes a compiler warn
On Mon, Dec 05, 2005 at 04:38:40PM -0500, Derek Atkins wrote:
> If you were on IRC you'd have more information on this.
>
> Yes, it is 64-bit only. The problem is that on some versions of gcc4
> stddef.h #defined NULL as (int)0 which causes a compiler warning when
> passing that into a char*.
I'
If you were on IRC you'd have more information on this.
Yes, it is 64-bit only. The problem is that on some versions of gcc4
stddef.h #defined NULL as (int)0 which causes a compiler warning when
passing that into a char*.
The fix (which David is working on -- which you'd know if you were in
IRC
Quoting Chris Shoemaker <[EMAIL PROTECTED]>:
Meta-comment for list maintainer:
Can we please set ReplyTo on -patches mail to be gnucash-devel?
Done.
-derek
--
Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
Member, MIT Student Information Processing Board (SIPB)
On Sun, Dec 04, 2005 at 02:45:42PM +0100, Sjoerd Langkemper wrote:
> This patch fixes warnings like these:
> warning: missing sentinel in function call
>
> Look at this page to find at what this warning is about:
> http://www.linuxonly.nl/docs/sentinel/
>
> This patch basically replaces NULL with
On Sunday 04 December 2005 1:45 pm, Sjoerd Langkemper wrote:
> This patch fixes warnings like these:
> warning: missing sentinel in function call
What system are you using to build? Gcc4 has been in use by various developers
for some time without any of these warnings - they would have been notic
26 matches
Mail list logo
