On Thu, 2006-01-05 at 22:23, Hans Breuer wrote:
> There is no benefit in it with regard to C99 features.
[...]
> Tell me what you need, and I'll tell you how to
> get along without it.-- Dilbert
I see :)
___
gtk-devel-list mailing list
On Jan 5, 2006, at 9:52 PM, Owen Taylor wrote:
The main reason requiring C99 might be that most or all of
the developers are now using C99 compilers and aren't able to catch
slip-ups. It's hard to support something that we don't test with.
Add "--std=c89" to your CFLAGS. It catches lots of s
On Thu, 5 Jan 2006, Tor Lillqvist wrote:
Roger Leigh writes:
> Why not just make proper C99 support the minimum requirement?
BTW, are we discussing compilers used for building GTK+/GLib/etc here,
or compilers used for building software that *uses* GTK+/GLib/etc?
both, depending on C99 for
Hi everybody,
in GLib 2.9.2, in gobject.c,
lines 499 to 525 :
static void
g_object_do_set_property (GObject *object,
guint property_id,
const GValue *value,
GParamSpec *pspec)
{
switch (property_id)
On Fri, 2006-01-06 at 13:10 +0100, Benoit Carpentier wrote:
> Hi everybody,
>
> in GLib 2.9.2, in gobject.c,
>
> lines 499 to 525 :
>
> (snip)
>
> is there here a clear difference between these two
> function ?
> (g_object_do_set_property has const GValue argument
> whereas g_object_do_set_prope
On Wed, 4 Jan 2006, Federico Mena Quintero wrote:
On Wed, 2006-01-04 at 12:33 +0100, Tim Janik wrote:
1. "The main motivation for providing floating references is C convenience"
http://developer.gnome.org/doc/API/2.0/gobject/gobject-The-Base-Object-Type.html#floating-ref
That's ina
On 06.01.2006 09:24, muppet wrote:
On Jan 5, 2006, at 9:52 PM, Owen Taylor wrote:
The main reason requiring C99 might be that most or all of
the developers are now using C99 compilers and aren't able to catch
slip-ups. It's hard to support something that we don't test with.
Add "--std=c89"
(federico)
API freeze for GNOME 2.14 is approaching quickly. Can we please back
out GObject floating references soon?
(timj)
no, there really is no point in that. even if we were to do that, we
couldn't hold off floating references for non-GtkObjects but GObjects
anyway. the results
>within compound statements. As an extension, GCC also allows this in
>C89 mode. For example, you could do:
IMO, this is a GCC bug... from the man page:
(-std=)
c89
iso9899:1990
ISO C90 (same as -ansi).
gnu89
Default, ISO C90 plus GNU extens
> I would expect that to only be enabled if using gnu89, but indeed mixed
> declarations and code do compile with -ansi or -std=c89. The only way to cause
> this to generate warnings AFAIK is -pedantic:
You can also use:
-Wdeclaration-after-statement (C only)
Warn when a declarat
>You can also use:
>
> -Wdeclaration-after-statement (C only)
> Warn when a declaration is found after a statement in a block.
> This construct, known from C++, was introduced with ISO C99 and is
> by default allowed in GCC. It is not supported by ISO C90 and was
ANDREW PAPROCKI, BLOOMBERG/ 731 LEXIN wrote:
>> within compound statements. As an extension, GCC also allows this in
>> C89 mode. For example, you could do:
>
> IMO, this is a GCC bug... from the man page:
>
> (-std=)
> c89
> iso9899:1990
> ISO C90 (same as -ansi)
On Fri, 6 Jan 2006, Bill Haneman wrote:
(federico)
API freeze for GNOME 2.14 is approaching quickly. Can we please back
out GObject floating references soon?
(timj)
no, there really is no point in that. even if we were to do that, we
couldn't hold off floating references for non-GtkObject
Hi!
I am getting compile warnings on Linux AMD64 in places where BEAST needs
to format gint64 strings, and with what glib-2.0 currently provides, I
see no way of solving it within BEAST. Here is some example code:
--
/*
* cc -Wall $(pkg-config --libs --cflags glib-2.0) gint64print.c -o
On 1/6/06, Stefan Westerfeld <[EMAIL PROTECTED]> wrote:
>
> (1) Take no care that gint64 is defined by glib-2.0 as long long on
> 32-bit platforms and as long on 64-bit platforms. This generates
> compiler warnings on 64bit machines like Linux on AMD64.
>
> (2) Use glib's macros for formatting thin
On 1/3/06, Torsten Schoenfeld <[EMAIL PROTECTED]> wrote:
> On Tue, 2006-01-03 at 14:32 +0100, Tim Janik wrote:
>
> > >>GtkObject derives from GUnowned
> > >
> > > This breaks the Perl bindings of GTK+.
> > >
> > > Our GTK+ bindings register GtkObject with our GLib bindings at start up.
> > > Th
16 matches
Mail list logo
