Hello,
Our Windows hosted development tools are compiled under Cygwin and I'm
observing a strange problem with Dos style text files not being
pre-processed correctly. Specifically, something like this:
printf("This is a long string across\
multiple lines");
or a backslashified #define is be
> printf("This is a long string across\
> multiple lines");
>
> or a backslashified #define is being concatenated. Now, if I use the
Cygwin
> cpp.exe, I get the following (expected) behaviour:
Correction: I meant NOT being concatenated.
--
Unsubscribe info: http://cygwin.com/ml/#unsubs
in
version of cpp.exe. I noticed that the version of gcc shipped with cygwin
is 2.95.3-5. Is the '-5' some form of Cygwin specific patch with some
assorted magic in it? Perhaps someone on this list would know.
cheers,
Kris
- Original Message -
From: "Dan Vasaru" <
ublic branch which is the puzzle.
I'm wondering if there is some reason why but I'm agreeing with you and I
think I might just hack the preprocessor to properly deal with the '\r'.
Probably the most portable way.
cheers,
Kris
- Original Message -
From: "Dan Vasaru
- Original Message -
From: "Larry Hall (RFK Partners, Inc)" <[EMAIL PROTECTED]>
To: "Kris Warkentin" <[EMAIL PROTECTED]>; "Dan Vasaru"
<[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Tuesday, October 01, 2002 10:21 PM
Subject: Re: CR/
Can anyone point me to some documentation as to what these are and how
they're supposed to be used? I see that binmode.o and textmode.o have a
__fmode defined. Does it change the default file opening behaviour?
cheers,
Kris
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
B
Well happy day! I just linked GNU cpp with textmode.o and it works fine. I
think that I'm going to take the easy way out and just do that. Now if I
can only figure out how to get the configure script to do that for me rather
than doing it manually. ;-)
Thank you very much.
Kris
- Origina
This has been bugging me for a while and I think I've finally got it to a
repeatable case.
Suppose I have a function in my .profile like so:
vi(){
/cygdrive/d/vim/vim60/gvim.exe `for file in $* ; do cygpath -w $file ;
done` &
}
If I do something like 'vi /usr/include/std' ( for command
comp
> Kris,
> I don't see this behavior on Win2k SP2, bash 2.05b-5... Try putting the
> whole gvim invocation line (including the '&') in parentheses (it'll
> force the invocation into a subshell), and see if this helps...
>
> Otherwise, please post the version of Cygwin and bash you have, and which
Well, the earlier suggestion of putting parentheses around the command did
the trick for me. Hasn't happened to me since. It's a strange one even
still. I could see if it happened every time but it really comes and goes.
cheers,
Kris
- Original Message -
From: "mx" <[EMAIL PROTECTED]
I'm running Windows XP with 1/2GB RAM and 2GB swap. Running Cygwin 1.3.18.
Consider the following program to use as much memory as possible:
#include
#include
int
main()
{
void *x;
unsigned long long mem=0;
while((x=malloc(50)) != NULL){
mem += 5000
, I can't
run a bash shell anymore.
Any more ideas?
cheers,
Kris
- Original Message -
From: "Ronald Landheer-Cieslak" <[EMAIL PROTECTED]>
To: "Kris Warkentin" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Wednesda
12 matches
Mail list logo
