>> Glib just cannot require 64bit integer type and be C89 standard compliant
> Right. And as far as I know, nobody has claimed it is.
Actually, thinking a bit more, isn't it perfectly OK for a fully C89
compliant compiler to provide whatever non-standard stuff it likes as
long as the identifiers
> Glib just cannot require 64bit integer
> type and be C89 standard compliant
Right. And as far as I know, nobody has claimed it is.
--tml
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-de
Glib itself wouldn't even compile if I removed that before compilation
as it wouldn't find 64bit integer type. Glib just cannot require 64bit
integer type and be C89 standard compliant at the same time when C89
doesn't require existence of 64bit integer type.
Ok, I won't troll anymore.
On 02/
> - doesn't compile on x86-32 linux with glibc when I remove all typedefes and
> occurences of long long in header files
Equally interesting, it doesn't compile if you replace all instances
of the letter 'a' in your header files with the letter 'b'. Or, if you
feel really adventurous, with the let
Le 19/02/2011 15:06, Jaroslav Šmíd a écrit :
> #include
>
> int main(int argc, char **argv)
> {
> gint64 a;
> return 0;
> }
>
> - doesn't compile on x86-32 linux with glibc when I remove all typedefes
> and occurences of long long in header files (long long is not part of
> C89 standard and
#include
int main(int argc, char **argv)
{
gint64 a;
return 0;
}
- doesn't compile on x86-32 linux with glibc when I remove all typedefes
and occurences of long long in header files (long long is not part of
C89 standard and it would be unfair to leave it there even if it is some
compile
> that means glib and any app
> using glib is indirectly dependent on compiler with C99 support.
Interesting. I guess nobody told those who continue to manage to build
GLib and the GTK+ stack in general with Microsoft's compiler, which
does not claim C99 compliance.
--tml
On Sat, Feb 19, 2011 at 02:42:14PM +0100, Jaroslav Šmíd wrote:
> Hmm, resending, got identified as spam ...
I would not expect such intelligence from the spam filter but there you
have it...
Yeti
___
gtk-app-devel-list mailing list
gtk-app-devel-list@g
On Sat, Feb 19, 2011 at 02:37:51PM +0100, Jaroslav Šmíd wrote:
>
> Maybe. Doesn't meen you didn't tell which one.
I did not have to because everyone except you understood the context.
Since you did not ask the question and evidently know better your
failure to understand is of little concern.
> *
Hmm, resending, got identified as spam ...
On 02/19/2011 02:37 PM, Jaroslav Šmíd wrote:
On 02/19/2011 10:19 AM, David Nečas wrote:
On Sat, Feb 19, 2011 at 01:21:37AM +0100, Jaroslav Šmíd wrote:
C99 has no implicit int ., so don't ignore compiler's warning and
fix it.
David Nečas: "All accordi
On 02/19/2011 10:19 AM, David Nečas wrote:
On Sat, Feb 19, 2011 at 01:21:37AM +0100, Jaroslav Šmíd wrote:
C99 has no implicit int shits, so don't ignore compiler's warning and
fix it.
David Nečas: "All according to the C standard". Right, you didn't tell
us which one, one could think you mean "
On Sat, Feb 19, 2011 at 01:21:37AM +0100, Jaroslav Šmíd wrote:
> C99 has no implicit int shits, so don't ignore compiler's warning and
> fix it.
>
> David Nečas: "All according to the C standard". Right, you didn't tell
> us which one, one could think you mean "every C standard out there".
My
C99 has no implicit int shits, so don't ignore compiler's warning and
fix it.
David Nečas: "All according to the C standard". Right, you didn't tell
us which one, one could think you mean "every C standard out there". C99
is old enough to be supported by decent compilers, older standards
aren
Le 17/02/2011 20:46, Costin Chirvasuta a écrit :
> On Thu, Feb 17, 2011 at 9:11 PM, Craig Bakalian
> wrote:
>> Hi David and KC,
>>
>> The did the trick. But it is odd behavior.
>>
>> #include was already in my includes.
>
> Then g_remove must be a
On Thu, Feb 17, 2011 at 09:46:14PM +0200, Costin Chirvasuta wrote:
> On Thu, Feb 17, 2011 at 9:11 PM, Craig Bakalian
> wrote:
> > Hi David and KC,
> >
> > The did the trick. But it is odd behavior.
> >
> > #include was already in my includes.
>
> Th
On Thu, Feb 17, 2011 at 9:11 PM, Craig Bakalian
wrote:
> Hi David and KC,
>
> The did the trick. But it is odd behavior.
>
> #include was already in my includes.
Then g_remove must be a macro for a function in glib/gstdio.h, not stdio.h.
Craig Bakalian wrote:
The did the trick. But it is odd behavior.
It is not odd. Read David's e-mail for a full explanation. If it is
still not clear, you should read the gcc man pages for warning options.
___
gtk-app-devel-list mailing list
gtk-ap
9 +, James Morris wrote:
> >> On 17 February 2011 12:27, Craig Bakalian
> >> wrote:
> >> > Hi,
> >> >
> >> > I am using g_remove to remove some temporary files from the /tmp folder.
> >> > It is working as expec
On Thu, Feb 17, 2011 at 12:45:36PM -0500, Craig Bakalian wrote:
> I have gtk and glib as includes? Am I missing something?
Yes, on Unix the g_-wrappers are often just macros resolving to the
underlying system function. So you need to
#include
to get the real declarations (dunno why it's not d
kalian wrote:
> > Hi,
> >
> > I am using g_remove to remove some temporary files from the /tmp folder.
> > It is working as expected. Yet, gcc is complaining that I am making an
> > implicit declaration. What is up with this?
>
On 17 February 2011 12:27, Craig Bakalian wrote:
> Hi,
>
> I am using g_remove to remove some temporary files from the /tmp folder.
> It is working as expected. Yet, gcc is complaining that I am making an
> implicit declaration. What is up with this?
You've not #include-ed
Hi,
I am using g_remove to remove some temporary files from the /tmp folder.
It is working as expected. Yet, gcc is complaining that I am making an
implicit declaration. What is up with this?
Craig Bakalian
___
gtk-app-devel-list mailing list
gtk
22 matches
Mail list logo
