On Tuesday 11 December 2007 08:19, Maik Justus wrote:
> Hi,
>
> there are two "What's New" lists in the wiki:
> http://wiki.flightgear.org/flightgear_wiki/index.php?title=Changes_since_0.
>9.10 and
> http://wiki.flightgear.org/flightgear_wiki/index.php?title=FlightGear_pre-r
>elease_changelog_summa
Hi,
there are two "What's New" lists in the wiki:
http://wiki.flightgear.org/flightgear_wiki/index.php?title=Changes_since_0.9.10
and
http://wiki.flightgear.org/flightgear_wiki/index.php?title=FlightGear_pre-release_changelog_summary
Which one will be used as the "official" What's new list"?
I wo
On Wednesday 05 September 2007 08:56, I wrote:
>
>
> To me, the most obvious course of action seems to be the following:
>
> [SNIP]
>
Since I've seen no further comments, I assume nobody objects. :-)
Last week, I checked out most of FlightGear's dependencies and as far as I can
tell, FlightGear
Hi,
On Tuesday 04 September 2007 20:41, Andy Ross wrote:
>
> The goal here, I will point out yet again, isn't to decide how best to
> develop plib, but to decide how best to get it built
> under windows for a FlightGear release. I'd argue that
> building our released version against an inconsiste
Hi,
>>> If my memory serves, VC8 shipped with a new runtime that won't work
>>> on XP without an update, right?
>> Wrong.
>
> Can you elaborate? I'm all but certain that default builds want to
> link against MSVCR80.DLL (or whatever) at runtime, no?
One possibility: link statically.
> Are we s
olaf flebbe wrote:
> > If my memory serves, VC8 shipped with a new runtime that won't work
> > on XP without an update, right?
>
> Wrong.
Can you elaborate? I'm all but certain that default builds want to
link against MSVCR80.DLL (or whatever) at runtime, no? Are we set up
to install that in our
Hi,
> If my memory serves, VC8
> shipped with a new runtime that won't work on XP without an update,
> right?
Wrong.
> Regardless, you need to fix that patch if you want to see it used.
Yes, I would have to update to current SVN. But I am getting tired of
fixing non-gcc bugs.
Olaf
---
olaf flebbe wrote:
> Please do not mix the terms "compiles o.k. and works for me" with
> "the code is correct".
I did no such thing. The issue here is whether or not the code is the
*same* as the one we are shipping on other platforms. Yours is not,
and therefore really shouldn't be packaged up
Hi,
thanks John!
---
>Returning to the higher-level discussion, it is not necessary to do a
>strdup in this situation, as the following constructive suggestion
>illustrates.
... Johns nice example ...
int main(){
char aa[100];
const char* xx(aa)
olaf flebbe wrote:
> As a side note: The gcc does not enforce const-correctness very
> much.
Sigh, and the flames continue... Your basis for that statement is
what, exactly? Of course gcc enforces const correctness. I suspect
what's happening here is that plib, which is using and not
, is getti
Hi,
> I wrote:
>> Plib's behavior in the lines touched by this patch is platform
>> independent.
>
> And this bit of the patch is just flat wrong. The original version
> finds the first "_" in the string and nul-terminates it at that
> location. The "fixed" code it a complete no-op.
>
> -
Hi,
>
> No, the confusion seems to come from the difference between standard C runtime
> and standard C++ runtime. MSVC8 wants to conform to the latter when compiling
> C++ code. Look at that page :
Thanks.
As a side note: The gcc does not enforce const-correctness very much.
The SUN Compilers a
Hans Fugal wrote:
> I could be wrong, but I think you missed his point. I don't think he
> was arguing that you couldn't cast a const char* to a char*. The
> argument was that without the cast it doesn't work, and the cast is
> bad form and leads to bugs.
A point, you will note, I never disagreed
On 09/04/2007 09:47 AM, Andy Ross wrote:
> the patch
I assume we are still talking about:
http://sourceforge.net/tracker/index.php?func=detail&aid=1584727&group_id=382&atid=100382
> strchr()
> returns a pointer into the *same* memory it got. The constness needs
> to be synchroni
On 9/4/07, Andy Ross <[EMAIL PROTECTED]> wrote:
> John Denker wrote:
> > 2) It seems vacuous to compare writing via a const char* to
> > writing via a non-const char*, because AFAIK there is no such
> > thing as writing via a const char*. No compiler AFAIK will
> > generate any CPU instructions fo
On 9/4/07, Andy Ross <[EMAIL PROTECTED]> wrote:
> And in any case I already
> mentioned (and dismissed) this possibility. From three posts above:
Oops, missed that. Sorry.
--
Csaba
-
This SF.net email is sponsored by: Splu
Quoting Andy Ross :
> The confusion seems to be that Microsoft declared strchr() as taking
> and returning a const pointer. Which is broken, because strchr()
> returns a pointer into the *same* memory it got. The constness needs
> to be synchronized between the pointers, which is outside the
> c
Csaba Halász wrote:
> Note that literal string constants may be allocated in read-only
> data section, thus causing segmentation fault at runtime. Try
> calling your "foo" function passing a literal string,
What does this have to do with the discussion? We are talking about
const pointers, not li
On 9/4/07, Andy Ross <[EMAIL PROTECTED]> wrote:
> John Denker wrote:
> > 2) It seems vacuous to compare writing via a const char* to
> > writing via a non-const char*, because AFAIK there is no such
> > thing as writing via a const char*. No compiler AFAIK will
> > generate any CPU instructions fo
I wrote:
> Plib's behavior in the lines touched by this patch is platform
> independent.
And this bit of the patch is just flat wrong. The original version
finds the first "_" in the string and nul-terminates it at that
location. The "fixed" code it a complete no-op.
- char *p = s
John Denker wrote:
> 2) It seems vacuous to compare writing via a const char* to
> writing via a non-const char*, because AFAIK there is no such
> thing as writing via a const char*. No compiler AFAIK will
> generate any CPU instructions for it.
Oh, good grief:
$ echo 'void foo(const char* p){
On 09/03/2007 10:49 PM, Andy Ross wrote:
> A "const" char* is exactly the same thing as a regular pointer at
> the level of CPU instructions.
H.
> Writing to it does exactly the
> same thing as writing to a non-const pointer.
1) I assume "writing to it" means writing to the chars (not wr
olaf flebbe wrote:
> You may be wrong. They are writing to const char *. I had to strdup().
A "const" char* is exactly the same thing as a regular pointer at
the level of CPU instructions. Writing to it does exactly the
same thing as writing to a non-const pointer. The difference
exists at *comp
Andy Ross schrieb:
> olaf flebbe wrote:
>> Durk Talsma wrote:
>>> SimGear require plib-1.8.4, but this version no longer builds on my
>>> box
>> There is still an patch for MSVC8 waiting to be applied.
>
> Looking at that patch, it seems entirely typecast stuff. Those are
> warning conditions; I
olaf flebbe wrote:
> Durk Talsma wrote:
> > SimGear require plib-1.8.4, but this version no longer builds on my
> > box
>
> There is still an patch for MSVC8 waiting to be applied.
Looking at that patch, it seems entirely typecast stuff. Those are
warning conditions; I don't see any changes that
Thank you Vivian for that report,
I'm running Linux-2.4.34 with GCC-3.3.2 and make-3.79.2a1 , and have
checked for library conflicts, but ldd lists the same 5 .so files as
SimGear-0.3.10/simgear/math/SGMathTest, which DOES work correctly.
Checking further, I can say that the error occurs in SGMat
Hi,
AJ MacLeod schrieb:
> On Saturday 01 September 2007 09:18:18 Durk Talsma wrote:
>
>> Right at the beginning, I found one significant problem: FlightGear /
>> SimGear require plib-1.8.4, but this version no longer builds on my box
>> (using gcc 4.1.2). I'm getting the following compiler error:
Stewart Andreason
> Sent: 01 September 2007 15:03
> To: FlightGear developers discussions
> Subject: Re: [Flightgear-devel] The Release
>
>
> Did anybody ever acknowledge, duplicate, or fix the bug I reported in
> Simgear-0.3.11-pre1 on May21?
>
> make[3]: Ente
Did anybody ever acknowledge, duplicate, or fix the bug I reported in
Simgear-0.3.11-pre1 on May21?
make[3]: Entering directory `/usr/src/SimGear-0.3.11-pre1/simgear/math'
FAIL: SGMathTest
Stewart
-
This SF.net email is s
On Saturday 01 September 2007 09:18:18 Durk Talsma wrote:
> Right at the beginning, I found one significant problem: FlightGear /
> SimGear require plib-1.8.4, but this version no longer builds on my box
> (using gcc 4.1.2). I'm getting the following compiler error:
> This problem is fixed in CVS/
Gentlemen,
A few months back, we had an increase in activity related to a possible
release of FlightGear 0.9.11. After the initial pre-release, things fell
silent again. Most of us probably know that Curt has been forced to cut back
on his FlightGear time, mainly for reasons beyond his control.
31 matches
Mail list logo
