cygwin g++ strictness

classic Classic list List threaded Threaded
38 messages Options
12
Reply | Threaded
Open this post in threaded view
|

cygwin g++ strictness

John Emmas
When compiling things under cygwin I'm noticing that the compiler is very
strict about things like typedef'd variables.  For example if 'gint' is
typedef'd as int and 'int32' is also typedef'd as int I can't pass an int32
to a function that requires gint.  This means I'm having to put dozens of
casts all over the place.  Is there any way to avoid this?  e.g. a compiler
switch that would make the compiler a bit more lenient?

John


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Reply | Threaded
Open this post in threaded view
|

Re: cygwin g++ strictness

Václav Haisman
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

John Emmas wrote:
> When compiling things under cygwin I'm noticing that the compiler is very
> strict about things like typedef'd variables.  For example if 'gint' is
> typedef'd as int and 'int32' is also typedef'd as int I can't pass an int32
> to a function that requires gint.  This means I'm having to put dozens of
> casts all over the place.  Is there any way to avoid this?  e.g. a compiler
> switch that would make the compiler a bit more lenient?
I think the problem is between keyboard and chair. GCC, no matter how
ancient version, just does not do that. That would be in violation of
very basic principle of all C and C++ standards. Typedef does not create
new types, it merely creates aliases for existing types.

>
> John

- --
VH
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iFYEAREIAAYFAkkKMMgACgkQhQBMvHf/WHmCeQDfcXkerTqBBcqjk8rgPqjSZUJW
sRQRkBy8MyLmqQDgl58i+4wWsA0GFerYruZLJyq0A21np0ficI9+Zw==
=hRam
-----END PGP SIGNATURE-----

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Reply | Threaded
Open this post in threaded view
|

Re: cygwin g++ strictness

Larry Hall (Cygwin)
In reply to this post by John Emmas
John Emmas wrote:
> When compiling things under cygwin I'm noticing that the compiler is very
> strict about things like typedef'd variables.  For example if 'gint' is
> typedef'd as int and 'int32' is also typedef'd as int I can't pass an int32
> to a function that requires gint.  This means I'm having to put dozens of
> casts all over the place.  Is there any way to avoid this?  e.g. a compiler
> switch that would make the compiler a bit more lenient?

This is gcc/g++ question, not a Cygwin one.  Please find an appropriate
forum to ask this question if you can't find it in the available
documentation.

Thanks,

--
Larry Hall                              http://www.rfk.com
RFK Partners, Inc.                      (508) 893-9779 - RFK Office
216 Dalton Rd.                          (508) 893-9889 - FAX
Holliston, MA 01746

_____________________________________________________________________

A: Yes.
 > Q: Are you sure?
 >> A: Because it reverses the logical flow of conversation.
 >>> Q: Why is top posting annoying in email?

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Reply | Threaded
Open this post in threaded view
|

Re: cygwin g++ strictness

John Emmas
In reply to this post by Václav Haisman
----- Original Message -----
From: "Larry Hall (Cygwin)"
Sent: 30 October 2008 22:23
Subject: Re: cygwin g++ strictness
>
> This is gcc/g++ question, not a Cygwin one.  Please find an appropriate
> forum to ask this question if you can't find it in the available
> documentation.
>

----- Original Message -----
From: "Vaclav Haisman"
Sent: 30 October 2008 22:10
Subject: Re: cygwin g++ strictness
>
> I think the problem is between keyboard and chair. GCC, no matter how
> ancient version, just does not do that.
>
Regardless of your ascerbic comments, adding the compiler flag -fpermissive
seems to have solved the problem.   Cygwin's version of gcc seems to be 3.4
on my system whereas my Linux box is running 4.4.  Maybe this is something
that got relaxed between the two of them?  Whatever the explanation, the
exact same code compiles fine under Linux/gcc4.4 without needing that flag.
Maybe it wouldn't have done under Linux/gcc3.4?

John


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Reply | Threaded
Open this post in threaded view
|

Re: cygwin g++ strictness

Václav Haisman
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

John Emmas wrote:

> ----- Original Message ----- From: "Larry Hall (Cygwin)"
> Sent: 30 October 2008 22:23
> Subject: Re: cygwin g++ strictness
>>
>> This is gcc/g++ question, not a Cygwin one.  Please find an appropriate
>> forum to ask this question if you can't find it in the available
>> documentation.
>>
>
> ----- Original Message ----- From: "Vaclav Haisman"
> Sent: 30 October 2008 22:10
> Subject: Re: cygwin g++ strictness
>>
>> I think the problem is between keyboard and chair. GCC, no matter how
>> ancient version, just does not do that.
>>
> Regardless of your ascerbic comments, adding the compiler flag -fpermissive
> seems to have solved the problem.   Cygwin's version of gcc seems to be 3.4
> on my system whereas my Linux box is running 4.4.  Maybe this is something
> that got relaxed between the two of them?  Whatever the explanation, the
> exact same code compiles fine under Linux/gcc4.4 without needing that flag.
> Maybe it wouldn't have done under Linux/gcc3.4?
>
> John

Watch this:

(vhaisman@fiona)[1010] /cygdrive/c/wilx
$ cat pebkac.cxx
#include <iostream>

using namespace std;

typedef int gint;
typedef int int32;
void foo (gint x)
{
  cout << x;
}

int main ()
{
  int32 x = 2;
  foo (x);
}

(vhaisman@fiona)[1011] /cygdrive/c/wilx
$ g++ -Wall -Wextra -ansi -pedantic -o pebkac pebkac.cxx

(vhaisman@fiona)[1012] /cygdrive/c/wilx
$ g++ -v
Reading specs from /usr/lib/gcc/i686-pc-cygwin/3.4.4/specs
Configured with:
/usr/build/package/orig/test.respin/gcc-3.4.4-3/configure --verbose
- --prefix=/usr --exec-prefix=/usr --sysconfdir=/etc --libdir=/usr/lib
- --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info
- --enable-languages=c,ada,c++,d,f77,pascal,java,objc --enable-nls
- --without-included-gettext --enable-version-specific-runtime-libs
- --without-x --enable-libgcj --disable-java-awt --with-system-zlib
- --enable-interpreter --disable-libgcj-debug --enable-threads=posix
- --enable-java-gc=boehm --disable-win32-registry --enable-sjlj-exceptions
- --enable-hash-synchronization --enable-libstdcxx-debug
Thread model: posix
gcc version 3.4.4 (cygming special, gdc 0.12, using dmd 0.125)

It just works. You are doing something wrong. There is nothing wrong
with GCC 3.4 in this respect.


- --
wilx
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iFYEAREIAAYFAkkK2M8ACgkQhQBMvHf/WHktsQDfUCmfLwof8JgmiBUCjnAhxVlB
1UeClAO5B70OcADgx8k5fi00xozHySX/fSdcXwCwLmPRKNET3y7gDA==
=HrNG
-----END PGP SIGNATURE-----

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Reply | Threaded
Open this post in threaded view
|

Re: cygwin g++ strictness

John Emmas
In reply to this post by John Emmas
----- Original Message -----
From: "John Emmas"
Sent: 31 October 2008 08:21
Subject: Re: cygwin g++ strictness
>
> adding the compiler flag -fpermissive seems to have solved the problem.
>


----- Original Message -----
From: "Václav Haisman"
Sent: 31 October 2008 10:07
Subject: Re: cygwin g++ strictness
>
> It just works. You are doing something wrong. There is nothing wrong
> with GCC 3.4 in this respect.
>

It seems like I spoke to soon.....  -fpermissive seems to have helped in
some cases but not in every case.  I'll give an example. Please can someone
tell me if I'm misunderstanding something here.  Consider the following
function prototype (where 'gint' is typedef'd as an int in gtypes.h):-

#include <gtypes.h>
int AddTwoInts (gint& a, gint& b);

This code compiles under both Linux/gcc4.4 and also under Cygwin:-
gint x = 4;
gint y = 5;
int z = AddTwoInts (x, y);

This code compiles under Linux/gcc4.4 but not under Cygwin:-
#include <sys/types.h>   // typedefs int32_t as int
int32_t x = 4;
int32_t y = 5;
int z = AddTwoInts (x, y);

The last example produces this error on my system:-
error: no matching function for call to `AddTwoInts(int32_t&, int32_t&)'
note: candidates are: int AddTwoInts(gint&, gint&)
:: === Build finished: 2 errors, 0 warnings ===

Here's the compiler's command line:-
gcc.exe -Wall -DXTHREADS -DXUSE_MTSAFE_API -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include
 -I/usr/X11R6/include -I/usr/include/atk-1.0 -I/usr/include/pango-1.0 -I/usr/include/freetype2
 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -mwindows -g -IC:/cygwin/include
 -IC:/cygwin/usr/include/gtk-2.0 -IC:/cygwin/usr/include/glib-2.0 -IC:/cygwin/usr/include/pango-1.0
 -IC:/cygwin/lib/glib-2.0/include -IC:/cygwin/lib/gtk-2.0/include -IC:/cygwin/usr/include/atk-1.0
 -IC:/cygwin/usr/include/cairo -IC:/cygwin/usr/include/libgnomecanvas-2.0 -IF:/GTK/HelloWorld
 -c F:/GTK/HelloWorld/Test.c -o obj/Debug/Test.o

This is an example where adding -fpermissive doesn't help (in fact, I don't
even think it's relevant for plain old 'C').  So can anyone see what I'm
doing wrong?

Thanks,

John


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Reply | Threaded
Open this post in threaded view
|

Re: cygwin g++ strictness

Václav Haisman
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

John Emmas wrote:

> ----- Original Message ----- From: "John Emmas"
> Sent: 31 October 2008 08:21
> Subject: Re: cygwin g++ strictness
>>
>> adding the compiler flag -fpermissive seems to have solved the problem.
>>
>
>
> ----- Original Message ----- From: "Václav Haisman"
> Sent: 31 October 2008 10:07
> Subject: Re: cygwin g++ strictness
>>
>> It just works. You are doing something wrong. There is nothing wrong
>> with GCC 3.4 in this respect.
>>
>
> It seems like I spoke to soon.....  -fpermissive seems to have helped in
> some cases but not in every case.  I'll give an example. Please can someone
> tell me if I'm misunderstanding something here.  Consider the following
> function prototype (where 'gint' is typedef'd as an int in gtypes.h):-
>
> #include <gtypes.h>
> int AddTwoInts (gint& a, gint& b);
>
> This code compiles under both Linux/gcc4.4 and also under Cygwin:-
> gint x = 4;
> gint y = 5;
> int z = AddTwoInts (x, y);
>
> This code compiles under Linux/gcc4.4 but not under Cygwin:-
> #include <sys/types.h>   // typedefs int32_t as int
> int32_t x = 4;
> int32_t y = 5;
> int z = AddTwoInts (x, y);
Check what type is gint really is. I suspect the gint will be typedef
for long. Long and int are two different types even though they are both
32bits wide on 32bit platforms. Either declare x, y as gint or use
temporaries for the AddTwoInts() call.

>
> The last example produces this error on my system:-
> error: no matching function for call to `AddTwoInts(int32_t&, int32_t&)'
> note: candidates are: int AddTwoInts(gint&, gint&)
[...]

- --
VH
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iFYEAREIAAYFAkkK6KAACgkQhQBMvHf/WHnLpwDeMNkb5Gf8KL5fkj1kGbYA94LM
cKMQbaW5jHxZXQDfRoB6wH03WYo8tliLcgpH2ceZ9gkGvy2YtbhbDg==
=KUkg
-----END PGP SIGNATURE-----

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Reply | Threaded
Open this post in threaded view
|

Re: cygwin g++ strictness

John Emmas
----- Original Message -----
From: "Václav Haisman"
Sent: 31 October 2008 11:14
Subject: Re: cygwin g++ strictness
>
> Check what type is gint really is. I suspect the gint will be typedef
> for long. Long and int are two different types even though they are both
> 32bits wide on 32bit platforms.

Thanks Vaclav.  It must be something like that because I've noticed that if
the function prototype is changed to look like this:-

int AddTwoInts (int& a, int& b);

this works.....
gint x = 4;
gint y = 5;
int z = AddTwoInts (x, y);

wheareas this doesn't.....
int32_t x = 4;
int32_t y = 5;
int z = AddTwoInts (x, y);

So, even though it looks like 'sys/types.h' is typedefing int32_t as an int,
that section must either be getting conditionally (not) compiled or maybe
int32_t is getting redefined somewhere else.

Having said all that, most compilers provide implicit conversions between
related types.  gcc4.4 seems to be doing that and I'm pretty sure that MSVC
would allow it also (although I haven't tried it).

Thanks also for the suggestion about changing to temporary variables but it
won't help in this case because this isn't my own code and I'd probably need
to change dozens of modules.  Explicit casting is probably the safest
solution.

John


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Reply | Threaded
Open this post in threaded view
|

Re: cygwin g++ strictness

Václav Haisman
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

John Emmas wrote:

> ----- Original Message ----- From: "Václav Haisman"
> Sent: 31 October 2008 11:14
> Subject: Re: cygwin g++ strictness
>>
>> Check what type is gint really is. I suspect the gint will be typedef
>> for long. Long and int are two different types even though they are both
>> 32bits wide on 32bit platforms.
>
> Thanks Vaclav.  It must be something like that because I've noticed that if
> the function prototype is changed to look like this:-
>
> int AddTwoInts (int& a, int& b);
>
> this works.....
> gint x = 4;
> gint y = 5;
> int z = AddTwoInts (x, y);
>
> wheareas this doesn't.....
> int32_t x = 4;
> int32_t y = 5;
> int z = AddTwoInts (x, y);
>
> So, even though it looks like 'sys/types.h' is typedefing int32_t as an
> int,
> that section must either be getting conditionally (not) compiled or maybe
> int32_t is getting redefined somewhere else.
Try getting preprocessed source to see where int32_t get defined to
anything else than typedef of int.

>
> Having said all that, most compilers provide implicit conversions between
> related types.  gcc4.4 seems to be doing that and I'm pretty sure that MSVC
> would allow it also (although I haven't tried it).
That has nothing to do with your problem. Reference to int and reference
to long are two totally unrelated types. The implicit conversions of
C/C++ only apply to values, not references.

>
> Thanks also for the suggestion about changing to temporary variables but it
> won't help in this case because this isn't my own code and I'd probably
> need
> to change dozens of modules.  Explicit casting is probably the safest
> solution.
No, casting is not an option, really. You have references. What do you
intend to cast x and y to?

- --
VH

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iFYEAREIAAYFAkkK8eIACgkQhQBMvHf/WHl+kgDfYntRu/+NS1A6Z5/2TYlV96K0
Tih8AggNNdhejADeMweLvprsehppWaNqAczAv/DJ5NWQwBYJicAUzA==
=MlgZ
-----END PGP SIGNATURE-----

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Reply | Threaded
Open this post in threaded view
|

RE: cygwin g++ strictness

Dave Korn
In reply to this post by John Emmas
John Emmas wrote on 31 October 2008 11:40:

> Having said all that, most compilers provide implicit conversions between
> related types.  

  Both GCC and MSVC implement the same C and C++ language standards, which
define clearly what type conversions are allowed and which are not.  Further,
the rules are different for C and for C++, and different again when references
are involved.

  Also your previous example was pretty confused:

John Emmas wrote on 31 October 2008 10:25:

> Here's the compiler's command line:-
> gcc.exe

  That's the C compiler.

>  -c F:/GTK/HelloWorld/Test.c

  That's a C source file.

  Clearly this is nothing to do with the examples you have shown us that rely
on C++ references.

  BTW, Cygwin has gcc v4 packages available; they're named gcc4, gcc4-core,
gcc4-g++ and so on.

    cheers,
      DaveK
--
Can't think of a witty .sigline today....


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Reply | Threaded
Open this post in threaded view
|

Re: cygwin g++ strictness

John Emmas
In reply to this post by Václav Haisman
----- Original Message -----
From: "Václav Haisman"
Sent: 31 October 2008 11:54
Subject: Re: cygwin g++ strictness
>
> That has nothing to do with your problem. Reference to int and reference
> to long are two totally unrelated types. The implicit conversions of
> C/C++ only apply to values, not references.
>
Ah, fair enough, I'd never thought about it but it's obvious now you've
mentioned it.


>
> No, casting is not an option, really. You have references. What do you
> intend to cast x and y to?
>
Maybe it's a happy accident but this seems to compile and link (and work)

int AddTwoInts (int& a, int& b);

int32_t x = 4;
int32_t y = 5;
int z = AddTwoInts ((int&)x, (int&)y);  // Compiles, links and works
int zz = AddTwoInts (x, y);  // Doesn't compile


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Reply | Threaded
Open this post in threaded view
|

RE: cygwin g++ strictness

Dave Korn
John Emmas wrote on 31 October 2008 12:15:

> ----- Original Message -----
> From: "Václav Haisman"
> Sent: 31 October 2008 11:54
> Subject: Re: cygwin g++ strictness
>>
>> That has nothing to do with your problem. Reference to int and reference
>> to long are two totally unrelated types. The implicit conversions of
>> C/C++ only apply to values, not references.
>>
> Ah, fair enough, I'd never thought about it but it's obvious now you've
> mentioned it.
>
>
>>
>> No, casting is not an option, really. You have references. What do you
>> intend to cast x and y to?
>>
> Maybe it's a happy accident but this seems to compile and link (and work)
>
> int AddTwoInts (int& a, int& b);
>
> int32_t x = 4;
> int32_t y = 5;
> int z = AddTwoInts ((int&)x, (int&)y);  // Compiles, links and works

  You are creating temporaries here.  If AddTwoInts modifies either of the int
references it has, that will only change the temporaries; x and y will /not/
be modified.


    cheers,
      DaveK
--
Can't think of a witty .sigline today....


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Reply | Threaded
Open this post in threaded view
|

Re: cygwin g++ strictness

John Emmas
----- Original Message -----
From: "Dave Korn"
Sent: 31 October 2008 12:22
Subject: RE: cygwin g++ strictness
>
> You are creating temporaries here.  If AddTwoInts modifies either of the
> int references it has, that will only change the temporaries; x and y will
> /not/ be modified.

You'll be surprised if you try it Dave....

int AddTwoInts (int& a, int& b)
{
    int x = a;
    int y = b;

    a = 6;  // Note this line

    return x + y;
}

int main()
{
int32_t  m=4;
gint  n=5;

    AddTwoInts ((int&)m, n);

    return 0;  // 'm' equals 6 by the time you get to this line !!
}

I was surprised too - but it works (!?!)

John


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Reply | Threaded
Open this post in threaded view
|

Re: cygwin g++ strictness

John Emmas
In reply to this post by Václav Haisman
----- Original Message -----
From: "Václav Haisman"
Sent: 31 October 2008 11:54
Subject: Re: cygwin g++ strictness
>
> Try getting preprocessed source to see where int32_t get defined to
> anything else than typedef of int.
>
I quite like this idea because I can see that this situation is going to
cause me lots of problems - in fact, it's ALREADY causing me lots of
problems... :-)

Can you expand on that suggestion please?  Where is the preprocessed
source available?  If you mean searching through Cygwin's normal header
files it would be very difficult to track this down (although I agree with
you - int32_t must be getting defined differently, somewhere).

John


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Reply | Threaded
Open this post in threaded view
|

Re: cygwin g++ strictness

Václav Haisman
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

John Emmas wrote:

> ----- Original Message ----- From: "Václav Haisman"
> Sent: 31 October 2008 11:54
> Subject: Re: cygwin g++ strictness
>>
>> Try getting preprocessed source to see where int32_t get defined to
>> anything else than typedef of int.
>>
> I quite like this idea because I can see that this situation is going to
> cause me lots of problems - in fact, it's ALREADY causing me lots of
> problems... :-)
>
> Can you expand on that suggestion please?  Where is the preprocessed
> source available?  If you mean searching through Cygwin's normal header
> files it would be very difficult to track this down (although I agree with
> you - int32_t must be getting defined differently, somewhere).
I mean the -save-temps switch of GCC.

>
> John
>

- --
VH
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iFYEAREIAAYFAkkLAIMACgkQhQBMvHf/WHl9nQDgrofeXENv0R1If6vi5Y2AxzPV
jklp779yZa34bQDfUOSynmoptQAotxHMm7AQxePJ8cZ+EbVwDgf0PQ==
=dkF6
-----END PGP SIGNATURE-----

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Reply | Threaded
Open this post in threaded view
|

RE: cygwin g++ strictness

Dave Korn
In reply to this post by John Emmas
John Emmas wrote on 31 October 2008 12:35:

> ----- Original Message -----
> From: "Dave Korn"
> Sent: 31 October 2008 12:22
> Subject: RE: cygwin g++ strictness
>>
>> You are creating temporaries here.  If AddTwoInts modifies either of the
>> int references it has, that will only change the temporaries; x and y
>> will /not/ be modified.
>
> You'll be surprised if you try it Dave....

  Ah, I overlooked that you were using plain int32_t types in this example.
It wouldn't work with gints (in fact, contrary to what I said, the compiler
won't even create temps for you), not even if gint is a typedef for int32_t.
Your example requires gint to be a typedef for int.

  If gint is a typedef for long, and you make 'm' a gint as well as 'n', and
compile on a platform where longs are 64 bits and ints 32, the assignment to
'a' in AddTwoInts will overwrite both n and m in main (simulated here by
typedef'ing gint to long long on a 32-bit platform):


~ $ cat woo.cxx
#include <stdio.h>
typedef long long gint;

int AddTwoInts (int& a, int& b)
{
    int x = a;
    int y = b;

    a = 6;  // Note this line

    return x + y;
}

int main()
{
gint  m=4;
int  n=5;

    AddTwoInts ((int&)m, n);
    printf ("m is %d n is %d\n", m, n);

    return 0;  // 'm' equals 6 by the time you get to this line !!
}
@_______. .
(       /"\
 ||--||(___)
 '"  '"'---'
~ $ g++ woo.cxx -o woo
@_______. .
(       /"\
 ||--||(___)
 '"  '"'---'
~ $ ./woo.exe
m is 6 n is 0
@_______. .
(       /"\
 ||--||(___)
 '"  '"'---'
~ $


  That's why the casts are inadvisable.

  Add "--save-temps" to your compiler flags to get the preprocessed sources in
*.i or *.ii (for C or C++) files.


    cheers,
      DaveK
--
Can't think of a witty .sigline today....


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Reply | Threaded
Open this post in threaded view
|

Re: cygwin g++ strictness

John Emmas
In reply to this post by Václav Haisman
----- Original Message -----
From: "Václav Haisman"
Sent: 31 October 2008 12:56
Subject: Re: cygwin g++ strictness
>
> I mean the -save-temps switch of GCC.
>
Wow - that was really useful.  In fact I tracked down the problem..!

On Cygwin, '/usr/include/stdint.h' typedefs int32_t as long.  The same file
on my Linux partition typedefs it to int.  I must admit, I don't know what
to do now.....  :-(

Is there a simple solution to this?

John


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Reply | Threaded
Open this post in threaded view
|

Re: cygwin g++ strictness

Ralph Hempel
John Emmas wrote:

> Is there a simple solution to this?

In general, no. Writing portable code is hard and requires
quite a bit of thought and perhaps more importantly, experience.

First, use the strictest possible warning setting on the compiler
and strive for warning free compiles.

Then what I'd probably do is look closely at the offending code
and imagine all the ways that having incompatible types
that are silently converted will break your code.

Then read up on these issues on the many resources out there
on the web to educate yourself on how these problems manifest
themselves and how to solve them.

Sorry, but it's hard work.

Ralph


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Reply | Threaded
Open this post in threaded view
|

Re: cygwin g++ strictness

Tim Prince-3
In reply to this post by John Emmas
John Emmas wrote:

> On Cygwin, '/usr/include/stdint.h' typedefs int32_t as long.  The same file
> on my Linux partition typedefs it to int.  I must admit, I don't know what
> to do now.....  :-(
>
> Is there a simple solution to this?
>
Change your include file, if you disagree with it being more aligned with
Windows tradition than with linux.  Or, change your source code, so that
it doesn't mix int32_t with int.

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Reply | Threaded
Open this post in threaded view
|

Re: cygwin g++ strictness

Eric Blake (cygwin)
In reply to this post by John Emmas
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

According to John Emmas on 10/31/2008 7:14 AM:
> On Cygwin, '/usr/include/stdint.h' typedefs int32_t as long.  The same file
> on my Linux partition typedefs it to int.  I must admit, I don't know what
> to do now.....  :-(
>
> Is there a simple solution to this?

Both implementations comply with POSIX - your code is buggy for assuming
that int32_t can be converted without casts to either long or int (for
that matter, it is theoretically possible that int32_t could be a
completely distinct type from either int or long, although I don't know of
any such platform).

But yes, it might be nice if cygwin used the same type as Linux, as we
claim to strive for Linux source compatibility.  However, changing it now
would be changing the C++ ABI, with far-reaching effects (anything in C++
that involves a mangled name would change what the function name is, which
will in turn cause link errors if you mix code pre-change and post-change
that expect different function names).  On the other hand, gcc 4 may
already be causing ABI changes, so maybe this would be appropriate as part
of the switch to gcc 4 and cygwin 1.7.0?

- --
Don't work too hard, make some time for fun as well!

Eric Blake             [hidden email]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkkLB4sACgkQ84KuGfSFAYCD3gCgwXa1C5W55LSXmHSYmhYs7TiQ
FHYAn3WMNVs6zIBjkuLPhbtMznRdASHB
=amZ/
-----END PGP SIGNATURE-----

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

12