Re: g_remove

[Jaroslav ÅmÃd <jardasmid gmail com>]

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 according to the C standard". Right, you didn't tell
> > > us which one, one could think you mean "every C standard out there".
> >
> > My English is not perfect but I think can distinguish between "a
> > standard", "the standard" and "all standards", thank you very much.
>
> Maybe. Doesn't meen you didn't tell which one.
>
> > So, no "the standard" means a single C standard. The only C standard
> > relevant to the problem.
> The standard the Criag's C compiler adheres to
> > (or at least tries) while compiling the program.
>
> Yes, C99 is the only relevant. I was compiling glib on FreeBSD recently
> and I noticed that at least 1 depency* of glib required -std=c99 and at
> least one required -std=gnu99 argument for compiling, that means glib
> and any app using glib is indirectly dependent on compiler with C99
> support. And without C99, glib's condition of "requiring 64bit integer
> type" could be hardly met e.g. on x86-32 linux with glibc without C99
> support - glibc has typedef "long long" to int64_t on such system and
> long long is only available in C99. So glib depends on C99 compiler, at
> least on x86-32 linux with glibc and on FreeBSD amd64  Because of that,
> "the standard" substitutes to C99 standard in my head.
>
> * direct, indirect, build time or runtime ... it is depency. Don't know
> names, but if you want, you can find out by yourself.
>
> > Yeti
>
> JardÃk