On 2017-01-30 10:41, Пётр Б. wrote:
Why is popen from stdio.h disabled with -std=c++11? I am trying to
grasp it and I can't.
It is exposed if -std=c11 but not for c++11.
No, it's not, you get an implicit function declaration warning in C.
C++ is simply less forgiving (which is
See usr/include/stdio.h:343 (2016.12.16)
Why is popen from stdio.h disabled with -std=c++11? I am trying to
grasp it and I can't. It is exposed if -std=c11 but not for c++11.
What is the problem and can it be solved?
Why does -std=c++11 prevent POSIX visibility?
MinGW exposes popen as _
Hi,
>> >> is cygwin's __STRICT_ANSI__ and stdio.h behavior not so compatible to
>> >> glibc's?
>> >
>> > Cygwin is using newlib, newlib is BSD based. We introduced the
>> > compatibility checking macros from FreeBSD lately.
>&g
On Dec 15 02:17, KIMURA Masaru wrote:
> Hi,
>
> >> is cygwin's __STRICT_ANSI__ and stdio.h behavior not so compatible to
> >> glibc's?
> >
> > Cygwin is using newlib, newlib is BSD based. We introduced the
> > compatibility checking macros
Hi,
>> is cygwin's __STRICT_ANSI__ and stdio.h behavior not so compatible to
>> glibc's?
>
> Cygwin is using newlib, newlib is BSD based. We introduced the
> compatibility checking macros from FreeBSD lately.
i roughly checked FreeBSD include/stdio.h and sys/
On Dec 12 16:51, KIMURA Masaru wrote:
> Hi,
>
> is cygwin's __STRICT_ANSI__ and stdio.h behavior not so compatible to glibc's?
Cygwin is using newlib, newlib is BSD based. We introduced the
compatibility checking macros from FreeBSD lately.
Corinna
-
On 12/13/2015 11:56 PM, KIMURA Masaru wrote:
> Hi,
>
>>> is cygwin's __STRICT_ANSI__ and stdio.h behavior not so compatible to
>>> glibc's?
>>> especially, i meant routines in POSIX 1003.1:2001 (popen(), pclose(), etc).
>>> for a
oops!
forgot to attach p.c, so resending now...
> Hi,
>
>>> is cygwin's __STRICT_ANSI__ and stdio.h behavior not so compatible to
>>> glibc's?
>>> especially, i meant routines in POSIX 1003.1:2001 (popen(), pclose(), etc).
>>> for a
Hi,
>> is cygwin's __STRICT_ANSI__ and stdio.h behavior not so compatible to
>> glibc's?
>> especially, i meant routines in POSIX 1003.1:2001 (popen(), pclose(), etc).
>> for a specific example, see a cparser issue[1] i submitted.
>>
>
> Cygwin
On 12/12/2015 2:51 AM, KIMURA Masaru wrote:
> Hi,
>
> is cygwin's __STRICT_ANSI__ and stdio.h behavior not so compatible to glibc's?
> especially, i meant routines in POSIX 1003.1:2001 (popen(), pclose(), etc).
> for a specific example, see a cparser issue[1] i submitte
Hi,
is cygwin's __STRICT_ANSI__ and stdio.h behavior not so compatible to glibc's?
especially, i meant routines in POSIX 1003.1:2001 (popen(), pclose(), etc).
for a specific example, see a cparser issue[1] i submitted.
Peace,
-
[1] https://github.com/MatzeB/cparser/issues/10
And FWIW, MinGW's native gcc also doesn't include the GCC specific
headers in the /mingw/include directory.
--
Earnie
-- https://sites.google.com/site/earnieboyd
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://
:
>>>>> ...
>>>>> /usr/include/stdio.h:34:20: fatal error: stddef.h: No such file or
>>>>> directory
>>>> stddef.h comes from the gcc4-core package. It's located in:
>>>>
>>>> usr/lib/gcc/i686-pc-cygwin/4.5.3/include/
On 02/20/2012 03:57 PM, Robert Miles wrote:
> Why not put a stddef.h file into /user/include that includes comments
> showing
> where to find the compiler-specific stddef.h files?
Why not ask the upstream gcc list? This is not a situation specific to
Cygwin, so asking on this list won't get it ch
On 02/20/2012 03:58 PM, Thomas Wolff wrote:
>> Wrong. GNU/Linux does this too. On my Fedora machine,
>>
>> $ printf '#include\n#include\n' | gcc -E -\
>> |grep '^# 1 "/'
...
>> # 1 "/usr/lib/gcc/x86_64-redhat-linux/4.6.2/include/stddef.h" 1 3 4
>> # 1 "/usr/include/wchar.h" 1 3 4
>> # 1 "/usr
Am 20.02.2012 23:10, schrieb Eric Blake:
On 02/20/2012 02:39 PM, Thomas Wolff wrote:
Am 20.02.2012 01:25, schrieb Christopher Faylor:
On Sun, Feb 19, 2012 at 07:07:04PM -0500, Chris Sutcliffe wrote:
...
/usr/include/stdio.h:34:20: fatal error: stddef.h: No such file or
directory
stddef.h
On 2/20/2012 4:12 PM, JonY wrote:
On 2/21/2012 05:39, Thomas Wolff wrote:
Am 20.02.2012 01:25, schrieb Christopher Faylor:
On Sun, Feb 19, 2012 at 07:07:04PM -0500, Chris Sutcliffe wrote:
...
/usr/include/stdio.h:34:20: fatal error: stddef.h: No such file or
directory
stddef.h comes from the
On 2/21/2012 05:39, Thomas Wolff wrote:
> Am 20.02.2012 01:25, schrieb Christopher Faylor:
>> On Sun, Feb 19, 2012 at 07:07:04PM -0500, Chris Sutcliffe wrote:
>>> ...
>>> /usr/include/stdio.h:34:20: fatal error: stddef.h: No such file or
>>> directory
>>
On 02/20/2012 02:39 PM, Thomas Wolff wrote:
> Am 20.02.2012 01:25, schrieb Christopher Faylor:
>> On Sun, Feb 19, 2012 at 07:07:04PM -0500, Chris Sutcliffe wrote:
>>> ...
>>> /usr/include/stdio.h:34:20: fatal error: stddef.h: No such file or
>>> directory
Am 20.02.2012 01:25, schrieb Christopher Faylor:
On Sun, Feb 19, 2012 at 07:07:04PM -0500, Chris Sutcliffe wrote:
...
/usr/include/stdio.h:34:20: fatal error: stddef.h: No such file or directory
stddef.h comes from the gcc4-core package. It's located in:
usr/lib/gcc/i686-pc-cygwin/
On Sun, Feb 19, 2012 at 07:07:04PM -0500, Chris Sutcliffe wrote:
>I'm trying to compile vim now using the latest snapshot, and I'm
>having an issue with stdio.h referencing stddef.h, which seems to be
>missing. I checked my /usr/include directory and sure enough, it's
&
I'm trying to compile vim now using the latest snapshot, and I'm
having an issue with stdio.h referencing stddef.h, which seems to be
missing. I checked my /usr/include directory and sure enough, it's
not there. According to vim's configure:
configure:3089: gcc -o confte
Christopher Faylor writes:
The cygwin mailing list does not set Reply-To. It does set
"Mail-Followup-To".
Effectively, there is no difference.
This is an idiotic header that is defined by a 1998 IETF draft
that was never approved, as far as I can find.
This *DEAD* draft is here:
http://too
Greg Chicares writes:
An argument could be made for giving _POSIX_C_SOURCE precedence over
__STRICT_ANSI__ if both are defined; but as long as that's not the
The time to discuss this sort of stuff was back in 1990 or so,
when it was all settled and POSIX.1 came out. (Luckily, it went
your way
On Mon, Oct 10, 2011 at 09:58:50PM -0700, Kaz Kylheku wrote:
>Christopher Faylor writes:
>> The convention in this mailing list is that you read the mailing list.
>I see now from the archives that this list is configured
>to generate the unfortunate Reply-to header, which by many
>is considered a m
Greetings, Kaz Kylheku!
> I see now from the archives that this list is configured
> to generate the unfortunate Reply-to header, which by many
> is considered a mailing list misconfiguration.
First time I hear this bullshit.
Mailing lists intended for public conversation.
> RFC 2822:
> ``When
On 2011-10-10 18:42Z, Kaz Kylheku wrote:
>
> Corinna Vinschen writes:
>
>> > $ gcc -Wall -ansi -D_POSIX_C_SOURCE=2 posix-ansi.c
> ^
>> fileno and pclose are *not* ANSI functions. Therefore, if you define
>> -ansi, you get the below errors. The newlib headers have explicit
>> #ifndef __STRICT
One more thing:
RFC 2822:
``When the "Reply-To:" field is present, it indicates the mailbox(es)
to which the author of the message suggests that replies be sent.''
[ 3.6.2 Originator fields ]
Note that the Cygwin mailing list is not the author of this message;
herefore, it is abusing the Rep
Christopher Faylor writes:
The convention in this mailing list is that you read the mailing list.
Hi Christopher,
I see now from the archives that this list is configured
to generate the unfortunate Reply-to header, which by many
is considered a mailing list misconfiguration.
[[ Apologies t
On Mon, Oct 10, 2011 at 11:42:45AM -0700, Kaz Kylheku wrote:
>
>Corinna Vinschen writes:
>
>> > $ gcc -Wall -ansi -D_POSIX_C_SOURCE=2 posix-ansi.c
> ^
>> fileno and pclose are *not* ANSI functions. Therefore, if you define
>> -ansi, you get the below errors. The newlib headers have explicit
>>
Corinna Vinschen writes:
> $ gcc -Wall -ansi -D_POSIX_C_SOURCE=2 posix-ansi.c
^
fileno and pclose are *not* ANSI functions. Therefore, if you define
-ansi, you get the below errors. The newlib headers have explicit
#ifndef __STRICT_ANSI__ guards around the non-ANSI definitions.
Hi Corin
On Oct 9 11:23, Kaz Kylheku wrote:
>
> On Sun, 09 Oct 2011 11:08:58 -0700, Kaz Kylheku
> wrote:
> > reason, I cannot get a warning about fileno from this test case if
> > I add a reference to it. I will try to produce a minimal repro test
> > case for that.
>
> In my real program I have -Wall,
On Sun, 09 Oct 2011 11:08:58 -0700, Kaz Kylheku
wrote:
> reason, I cannot get a warning about fileno from this test case if
> I add a reference to it. I will try to produce a minimal repro test
> case for that.
In my real program I have -Wall, and I'm not taking the function
pointers.
With -Wal
On Thu, Mar 11, 2010 at 07:08:56AM -0500, Jacob Jacobson wrote:
>On 03/11/2010 04:24 AM, Csaba Raduly wrote:
>> On Wed, Mar 10, 2...@10:41 PM, Jacob Jacobson wrote:
>>> Larry Hall (Cygwin) wrote:
>> (snip)
You are missing a few entries, though it's not clear why you don't have
them.
On 03/11/2010 04:24 AM, Csaba Raduly wrote:
On Wed, Mar 10, 2010 at 10:41 PM, Jacob Jacobson wrote:
Larry Hall (Cygwin) wrote:
(snip)
You are missing a few entries, though it's not clear why you don't have
them. Reinstall the 'cygwin' package.
Thanks. I reinstalled "cygwin" package and "gc
On Wed, Mar 10, 2010 at 10:41 PM, Jacob Jacobson wrote:
> Larry Hall (Cygwin) wrote:
(snip)
>>
>> You are missing a few entries, though it's not clear why you don't have
>> them. Reinstall the 'cygwin' package.
>
> Thanks. I reinstalled "cygwin" package and "gcc" works now. I also
> noticed that t
Larry Hall (Cygwin) wrote:
On 3/9/2010 9:53 AM, Jacob Jacobson wrote:
Csaba Raduly wrote:
On Mon, Mar 8, 2010 at 11:37 PM, Jacob Jacobson wrote:
I am unable to run gcc. I keep getting stdio.h: No such file.
Hi Jacob,
What is the output of
gcc-4 -v hello.c
and the output of
find /usr
On 3/9/2010 9:53 AM, Jacob Jacobson wrote:
Csaba Raduly wrote:
On Mon, Mar 8, 2010 at 11:37 PM, Jacob Jacobson wrote:
I am unable to run gcc. I keep getting stdio.h: No such file.
Hi Jacob,
What is the output of
gcc-4 -v hello.c
and the output of
find /usr/include -name stdio.h -ls
Csaba Raduly wrote:
On Mon, Mar 8, 2010 at 11:37 PM, Jacob Jacobson wrote:
I am unable to run gcc. I keep getting stdio.h: No such file.
Hi Jacob,
What is the output of
gcc-4 -v hello.c
and the output of
find /usr/include -name stdio.h -ls
[~$:501] cd /usr/include
/usr/include
[include
Larry Hall (Cygwin) wrote:
On 3/8/2010 5:37 PM, Jacob Jacobson wrote:
I am unable to run gcc. I keep getting stdio.h: No such file.
Try getting rid of the ~\... paths from your Windows path.
I notice a reference to MKS in your cygcheck output. Make
sure MKS is completely hidden from Cygwin
Csaba Raduly wrote:
On Mon, Mar 8, 2010 at 11:37 PM, Jacob Jacobson wrote:
I am unable to run gcc. I keep getting stdio.h: No such file.
Hi Jacob,
What is the output of
gcc-4 -v hello.c
and the output of
find /usr/include -name stdio.h -ls
[hello$:502] gcc-4 -v hello.c
Using built-in
On Mon, Mar 8, 2010 at 11:37 PM, Jacob Jacobson wrote:
> I am unable to run gcc. I keep getting stdio.h: No such file.
Hi Jacob,
What is the output of
gcc-4 -v hello.c
and the output of
find /usr/include -name stdio.h -ls
--
Life is complex, with real and imaginary parts
--
Problem repo
On 3/8/2010 5:37 PM, Jacob Jacobson wrote:
I am unable to run gcc. I keep getting stdio.h: No such file.
Try getting rid of the ~\... paths from your Windows path.
I notice a reference to MKS in your cygcheck output. Make
sure MKS is completely hidden from Cygwin.
--
Larry Hall
he compiler's problem. The C compiler does conform; it's the newlib C
*run-time library* that is not C89-compatible. Gcc is doing it's part, but
gcc does not supply stdio.h; it's up to the library to wrap the headers in
#ifdef.
> Which list do I need to go to to consult someon
Eric Blake wrote...
> 1) the newlib headers pollute the namespace in strict ANSI mode (or in
> other words, gcc -ansi _still has bugs_ in newlib) because no one has
> submitted patches to the newlib project to clean them up. Patches are
> welcome, but should be directed to the newlib list rather
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Paul Edwards on 11/28/2007 5:55 PM:
Please avoid http://cygwin.com/acronyms/#TOFU - reformatting your mail.
>
> I'll ask them to stop doing that. I just got spammed. :-( Still, at
least now
> I know where to find replies. :-)
>
> BFN
l.
- Original Message -
From: "Paul Edwards" <[EMAIL PROTECTED]>
To:
Sent: Sunday, November 11, 2007 1:40 PM
Subject: cygwin 1.5.24-2 gcc 3.4.4 stdio.h
> I just downloaded cygwin 1.5.24-2 (just a couple of hours ago) and
> compiled the following program with "
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Robert Kiesling on 11/11/2007 1:50 AM:
> [ Charset ISO-8859-1 unsupported, converting... ]
>> I just downloaded cygwin 1.5.24-2 (just a couple of hours ago) and
>> compiled the following program with "gcc -ansi fred.c"
>> (NOTE the "-ansi"
[ Charset ISO-8859-1 unsupported, converting... ]
> I just downloaded cygwin 1.5.24-2 (just a couple of hours ago) and
> compiled the following program with "gcc -ansi fred.c"
> (NOTE the "-ansi" keyword):
I have only the C99 standard in front of me, but its syntax should
be the same as ANSI, whic
the following result:
In file included from /usr/include/stdio.h:46,
from fred.c:3:
/usr/include/sys/types.h:180: error: parse error before "was"
In file included from /usr/include/sys/types.h:373,
from /usr/include/stdio.h:46,
from fred.c:3
On Mon, May 29, 2006 at 05:04:02PM +0900, Wynfield Henman wrote:
>1.) Any idea of when a release of cygwin will be made of the "current
>versions" contiaining the
> _GNU_SOURCE to avoid collision with old-style declarations?
Look at the mailing list archives and see all of the messages asking
change doesn't seem(?) to be in /usr/include/sys/stdio.h from Cygwin
>DLL 1.5.19-4. So I think one may have to use CVS or a snapshot, rather than
>"just" using the usual setup.exe procedure.
That's what Brian meant by "current version".
cgf
--
Unsubsc
nux.
>
>This change doesn't seem(?) to be in /usr/include/sys/stdio.h from Cygwin
>DLL 1.5.19-4. So I think one may have to use CVS or a snapshot, rather than
>"just" using the usual setup.exe procedure.
That's what Brian meant by "current version".
cgf
On Fri, May 26, 2006, Brian Dessent wrote:
>
> 2. In current versions of Cygwin getline and getdelim are only defined
> if the user defines _GNU_SOURCE - this is the same way it's done on
> linux.
This change doesn't seem(?) to be in /usr/include/sys/stdio.h from Cygwin
DLL
Wynfield Henman wrote:
>
> I have run into problems with getline being defined in stdio.h
>
> I understand that a GNU system has it defined there but not any other system.
>
> Please look into where "getline" should be defined in stdio.h or not.
1. This issue
On 26 May 2006 06:14, Wynfield Henman wrote:
> I have run into problems with getline being defined in stdio.h
That's a really imprecise description of the situation. Could mean
anything.
> I understand that a GNU system has it defined there but not any other
> system.
&g
I have run into problems with getline being defined in stdio.h
I understand that a GNU system has it defined there but not any other system.
Please look into where "getline" should be defined in stdio.h or not.
Thank you.
--
Unsubscribe info: http://cygwin.com/ml/#unsubscr
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Vladimir Panov on 1/28/2006 3:54 PM:
> Hi.
>
> cygwin-1.5.19 has introduced getline() and getdelim() in
> /usr/include/sys/stdio.h. Since they are GNU extensions, I think that
> they should be enclosed with #ifdef _GNU_SOU
Hi.
cygwin-1.5.19 has introduced getline() and getdelim() in
/usr/include/sys/stdio.h. Since they are GNU extensions, I think that
they should be enclosed with #ifdef _GNU_SOURCE. ... #endif.
Vlado
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports
On Thu, Jul 07, 2005 at 06:37:08PM +0200, Gerrit P. Haase wrote:
>Corinna Vinschen wrote:
>>On Jul 7 14:26, Gerrit P. Haase wrote:
>>>Eric Blake wrote:
An alternative is to investigate using the gnulib module in your code.
gnulib is currently designed for CVS use only (so there is no cygwi
Corinna Vinschen wrote:
On Jul 7 14:26, Gerrit P. Haase wrote:
Eric Blake wrote:
An alternative is to investigate using the gnulib module in your code.
gnulib is currently designed for CVS use only (so there is no cygwin
distribution), but projects like coreutils use gnulib getline() and ot
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Gerrit P. Haase on 7/7/2005 6:35 AM:
>>> An alternative is to investigate using the gnulib module in your code.
>
> Wouldn't it be nice to have it as a Cygwin package?
Unfortunately, the gnulib maintainers aren't ready for it to be a pac
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Gerrit P. Haase on 7/7/2005 6:26 AM:
>>http://www.gnu.org/software/gnulib/
>
> Same approach as libgen? Are dirname() and basename() included?
Gnulib uses source code sharing. There is no libgnulib.a, just a lot of
small modules that ca
Gerrit P. Haase wrote:
Eric Blake wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to George Morgan on 7/7/2005 2:12 AM:
Ok, I was reading about the virtues of using getline and then looked
in cygwin's
stdio.h and it is not there! Did it get removed? Yeah, I foun
On Jul 7 14:26, Gerrit P. Haase wrote:
> Eric Blake wrote:
> >An alternative is to investigate using the gnulib module in your code.
> >gnulib is currently designed for CVS use only (so there is no cygwin
> >distribution), but projects like coreutils use gnulib getline() and other
> >modules to ma
Eric Blake wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to George Morgan on 7/7/2005 2:12 AM:
Ok, I was reading about the virtues of using getline and then looked in cygwin's
stdio.h and it is not there! Did it get removed? Yeah, I found the __getline
but when I ch
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to George Morgan on 7/7/2005 2:12 AM:
> Ok, I was reading about the virtues of using getline and then looked in
> cygwin's
> stdio.h and it is not there! Did it get removed? Yeah, I found the __getline
> but when I cha
On Jul 7 04:12, George Morgan wrote:
> Ok, I was reading about the virtues of using getline and then looked in
> cygwin's
> stdio.h and it is not there! Did it get removed? Yeah, I found the __getline
> but when I changed my C code to use that the linker does not find it
Ok, I was reading about the virtues of using getline and then looked in cygwin's
stdio.h and it is not there! Did it get removed? Yeah, I found the __getline
but when I changed my C code to use that the linker does not find it. This is
with cygwin DLL version 1.5.18 and gcc 3.4.4. Maybe I
69 matches
Mail list logo
