MinGW: How do I temporarily disable stderr in a C(++) program

[Vince C.]

Hi all.

I've installed Bloodshed Dev-C++ on a Windows 2000 SP4 machine. I'm using
MinGW 3.4.2.

I'd like to temporarily disable standard functions to write to stderr, i.e.
for instance redirect stderr to a temporary file (or /dev/null but is there
an equivalent under Windows? Is it "nul:") and then to *restore* the
default stderr so that standard library functions that write to stderr
produce output again.

I've checked freopen to redirect stderr to a file but, strangely enough,
error messages don't go to the file :(.

Also note I'm using stdio and iostream concurrently.

Is there a way to, say, close stderr and restore it later on in the same
program under Windows using standard libraries?

Thanks for any hint or suggestion.

Vince C.

[Kenny McCormack]

In article <46***********************@read.news.be.uu.net>,
Vince C. <no**@teledisnet.bewrote:

>Hi all.

I've installed Bloodshed Dev-C++ on a Windows 2000 SP4 machine. I'm using
MinGW 3.4.2.

I'd like to temporarily disable standard functions to write to stderr, i.e.
for instance redirect stderr to a temporary file (or /dev/null but is there
an equivalent under Windows? Is it "nul:") and then to *restore* the
default stderr so that standard library functions that write to stderr
produce output again.

Let me be the first of many to wish you all the best of luck and true
happiness, and, oh, yes, to point out that your question is:

Off topic. Not portable. Cant discuss it here. Blah, blah, blah.
--
Useful clc-related links:

http://en.wikipedia.org/wiki/Aspergers
http://en.wikipedia.org/wiki/Clique
http://en.wikipedia.org/wiki/C_programming_language

[Jens Thoms Toerring]

Vince C. <no**@teledisnet.bewrote:

I've installed Bloodshed Dev-C++ on a Windows 2000 SP4 machine. I'm using
MinGW 3.4.2.

I'd like to temporarily disable standard functions to write to stderr, i.e.

Can you name a single standard C function that writes to stderr
(of course except those output functions that you tell to write
to stderr - and for those it's already under your control where
they write to)?

for instance redirect stderr to a temporary file (or /dev/null but is there
an equivalent under Windows? Is it "nul:") and then to *restore* the
default stderr so that standard library functions that write to stderr
produce output again.

If you use freopen() to redirect stderr to a file then stderr gets
closed. If you somehow can get it back despite having it closed and
then re-redirect back to that again is a question that you have to
ask in a Windows group.

I've checked freopen to redirect stderr to a file but, strangely enough,
error messages don't go to the file :(.

What exactly did you do? Perhaps it's a buffering issue, i.e.
while stderr is line buffered the writes to new file are block-
buffered and, if your program crashes, the buffer isn't written
to the file?

Also note I'm using stdio and iostream concurrently.

There's no 'iostream' in C, I guess you must be using C++, not C,
and then you should ask in comp.lang.c++.

Is there a way to, say, close stderr and restore it later on in the same
program under Windows using standard libraries?

You would need to have a file name for stderr to be able to that
since the only function for redirection in standard C is freopen()
and this can only redirect to a file given by path, not to a FILE
pointer. If Windows supplies you with something in the file system
for (an already closed) stderr I can't tell, that you again need to
ask in a Windows group. But this solution then is already system
specific for this reason you probably also don't need to care if
the functions you use are standard C functions...

Regards, Jens
--
\ Jens Thoms Toerring ___ [e-mail]
\__________________________ http://toerring.de

[Default User]

Jens Thoms Toerring wrote:

Vince C. <no**@teledisnet.bewrote:

I've installed Bloodshed Dev-C++ on a Windows 2000 SP4 machine. I'm
using MinGW 3.4.2.

I'd like to temporarily disable standard functions to write to
stderr, i.e.

Can you name a single standard C function that writes to stderr
(of course except those output functions that you tell to write
to stderr - and for those it's already under your control where
they write to)?

perror().


Brian

[Jens Thoms Toerring]

Default User <de***********@yahoo.comwrote:

Jens Thoms Toerring wrote:

Vince C. <no**@teledisnet.bewrote:

I've installed Bloodshed Dev-C++ on a Windows 2000 SP4 machine. I'm
using MinGW 3.4.2.

I'd like to temporarily disable standard functions to write to
stderr, i.e.

Can you name a single standard C function that writes to stderr
(of course except those output functions that you tell to write
to stderr - and for those it's already under your control where
they write to)?

perror().

Got me;-) And assert() is another example that I didn't think of...

Regards, Jens
--
\ Jens Thoms Toerring ___ [e-mail]
\__________________________ http://toerring.de

[Vince C.]

Off topic. Not portable. Cant discuss it here. Blah, blah, blah.

Warning: troll behind!
Let me answer with the same terseness:

Off-topic

No! I'm using all but Windows API, only standard C function alls and GPL'd
code so that it runs on BOTH Win* and LINUX systems.

Not portable

Yes! I'm using all portable APIs like GNU getopt() and getopt_long().
Absolutely no Windows API is involved.

Can't discuss it here

Ah? So stderr is no part of C?

I suggest you read once more the C standard functions.

Thanks for your non-help anyways,
Vince C.

[Vince C.]

Tim Prince wrote:

This isn't a Windows help forum.

I'm not that dumb you know... I just posted enough information so that those
who want to help get the most accurate picture of what I'm trying to do and
on what platform.

Vince C.

[Harald van =?UTF-8?B?RMSzaw==?=]

Vince C. wrote:

>Off topic. Not portable. Cant discuss it here. Blah, blah, blah.

Warning: troll behind!

On occasion Kenny'll provide useful answers, but his troll messages are best
ignored. That said, I disagree with your reply to him.

Let me answer with the same terseness:

>Off-topic

No! I'm using all but Windows API, only standard C function alls and GPL'd
code so that it runs on BOTH Win* and LINUX systems.

The license of code has nothing whatsoever to do with its portability, and I
fail to see how anyone might disagree. Plus, there are many more systems
than Windows and Linux, multiple processors that they run on, multiple
implementations of the C standard library per operating system, multiple
compilers per operating system, and there are probably other things I left
out.

>Not portable

Yes! I'm using all portable APIs like GNU getopt() and getopt_long().
Absolutely no Windows API is involved.

GNU getopt and getopt_long are not standard C functions. If you're calling
them externally, that's not portable, and it's off-topic here. If you're
including them in your own project, and they're doing something you don't
want, you'll need to show the relevant code.

[Malcolm McLean]

"Jens Thoms Toerring" <[e-mail] in message
news:5f*************@mid.uni-berlin.de...

Vince C. <no**@teledisnet.bewrote:

>I've installed Bloodshed Dev-C++ on a Windows 2000 SP4 machine. I'm using
MinGW 3.4.2.

>I'd like to temporarily disable standard functions to write to stderr,
i.e.

Can you name a single standard C function that writes to stderr
(of course except those output functions that you tell to write
to stderr - and for those it's already under your control where
they write to)?

assert() will often do so, though it is not obliged to.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

[Vince C.]

Jens Thoms Toerring wrote:

>I'd like to temporarily disable standard functions to write to stderr,
i.e.

Can you name a single standard C function that writes to stderr
(of course except those output functions that you tell to write
to stderr - and for those it's already under your control where
they write to)?

Functions getopt() and getopt_long(). They write error messages to stderr
whenever an option is not recognized or there is something wrong with the
command line syntax defined by the application.

If you use freopen() to redirect stderr to a file then stderr gets
closed. If you somehow can get it back despite having it closed and
then re-redirect back to that again is a question that you have to
ask in a Windows group.

It should be basically as simple as initializing device stderr when the
program starts, shouldn't it? There is code within stdlib that creates an
__iob[2] array of FILE*, each being stdout, stdin and stderr, respectively.
If my programm succeeds in doing the same, i.e. re-initializing stderr with
the default values, the trick is done. So I asked the question if it was
possible.

Of course my program is (currently) a Windows application but - while I'm
writing it - I'm building a set of functions that I'll be able to reuse
under whatever platform I want, provided it's running GNU code.

>I've checked freopen to redirect stderr to a file but, strangely enough,
error messages don't go to the file :(.

What exactly did you do? Perhaps it's a buffering issue, i.e.
while stderr is line buffered the writes to new file are block-
buffered and, if your program crashes, the buffer isn't written
to the file?

I'm trying to create a library of functions that basically runs with C++
code but with a base set of C functions. That base set of C functions
should be able to handle multiple command line argument syntaxes, like
argtable2 but much simpler (for my own usage).

I've read argtable2 uses get_opt() and getopt_long() so is 100% compatible
with GNU getopt() syntax. However if you want multiple command line
syntaxes and are using only getopt() and getopt_long() both functions
output error messages with the syntaxes that don't match - since there
should be only one command line parameter syntax that matches but you have
to check them all in a while loop (for instance) until you find one that
matches, i.e. during which neither getopt() and getopt_long() return any
error message.

Hence I'd like to temporarily disable stderr while I'm checking command line
parameter syntaxes since I might get error messages, which is the normal
behaviour of these functions.

>Also note I'm using stdio and iostream concurrently.

There's no 'iostream' in C, I guess you must be using C++, not C,
and then you should ask in comp.lang.c++.

Yes, I know there is no such iostream in C but iostream uses std* file
descriptors. Hence I suppose I must keep both libraries in sync, i.e. if I
close (or reopen) stderr cerr must be kept in sync so that it "knows" the
stderr file descriptor has changed.

I posted here for it's a C question first. And given the length of this
post, you can easily understand it's a hassle to type it again... ;-)

>Is there a way to, say, close stderr and restore it later on in the same
program under Windows using standard libraries?

You would need to have a file name for stderr to be able to that
since the only function for redirection in standard C is freopen()
and this can only redirect to a file given by path, not to a FILE
pointer. If Windows supplies you with something in the file system
for (an already closed) stderr I can't tell, that you again need to
ask in a Windows group. But this solution then is already system
specific for this reason you probably also don't need to care if
the functions you use are standard C functions...

I'd say "no" since the libraries I'm using implement the same code on all
supported platforms (it's GNU code). So it's completely independent from
Windows. The only difference is there is no /dev/null, as when we redirect
output in shell scripts. I think that device is "nul:" under windows (I
remember batch scripts where I used:

do_something_with_possible_error_messages nul:

The only thing I need to know, I suppose, is how does standard C library
initialize stderr so that I can do the same in my program - provided it's
safe, of course. Hence my question(s)...

Vince C.

[Kenny McCormack]

In article <f7**********@news2.zwoll1.ov.home.nl>,
Harald van Dijk <tr*****@gmail.comwrote:

>Vince C. wrote:

>>Off topic. Not portable. Cant discuss it here. Blah, blah, blah.

Warning: troll behind!

On occasion Kenny'll provide useful answers, but his troll messages are best
ignored. That said, I disagree with your reply to him.

>Let me answer with the same terseness:

>>Off-topic

No! I'm using all but Windows API, only standard C function alls and GPL'd
code so that it runs on BOTH Win* and LINUX systems.

The license of code has nothing whatsoever to do with its portability, and I
fail to see how anyone might disagree. Plus, there are many more systems

Right. The rule is: If it's the slightest bit interesting, it is OT here.

[Keith Thompson]

"Malcolm McLean" <re*******@btinternet.comwrites:

"Jens Thoms Toerring" <[e-mail] in message
news:5f*************@mid.uni-berlin.de...

>Vince C. <no**@teledisnet.bewrote:

>>I've installed Bloodshed Dev-C++ on a Windows 2000 SP4 machine. I'm using
MinGW 3.4.2.

>>I'd like to temporarily disable standard functions to write to
stderr, i.e.

Can you name a single standard C function that writes to stderr
(of course except those output functions that you tell to write
to stderr - and for those it's already under your control where
they write to)?

assert() will often do so, though it is not obliged to.

<quibble>assert is a macro, not a function.</quibble>

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Jens Thoms Toerring]

Vince C. <no**@teledisnet.bewrote:

Jens Thoms Toerring wrote:

I'd like to temporarily disable standard functions to write to stderr,
i.e.

Can you name a single standard C function that writes to stderr
(of course except those output functions that you tell to write
to stderr - and for those it's already under your control where
they write to)?

Functions getopt() and getopt_long(). They write error messages to stderr
whenever an option is not recognized or there is something wrong with the
command line syntax defined by the application.

Neither are standard C functions. But, on the other hand, as already
others have pointed out, there are (at least) the perror() and
assert() function which write to stderr...

If you use freopen() to redirect stderr to a file then stderr gets
closed. If you somehow can get it back despite having it closed and
then re-redirect back to that again is a question that you have to
ask in a Windows group.

It should be basically as simple as initializing device stderr when the
program starts, shouldn't it? There is code within stdlib that creates an
__iob[2] array of FILE*, each being stdout, stdin and stderr, respectively.
If my programm succeeds in doing the same, i.e. re-initializing stderr with
the default values, the trick is done. So I asked the question if it was
possible.

But there's also an operating system in the background, from which
the C library gets the value it uses to initializes stderr with.
And the C library is, of course, limited by what the operating
system does. stdin, stdout and stderr are an abstraction layer
on top of what the operating system supplies. Now the standard
requires that stderr gets closed when you use freopen() to re-
direct it to a file. And at least under Unix (I don't now about
Windows but I could imaging that it's similar) once you have
closed stderr (and thus the underlying file descriptor) there's
no going back.

Of course my program is (currently) a Windows application but - while I'm
writing it - I'm building a set of functions that I'll be able to reuse
under whatever platform I want, provided it's running GNU code.

I've checked freopen to redirect stderr to a file but, strangely enough,
error messages don't go to the file :(.

What exactly did you do? Perhaps it's a buffering issue, i.e.
while stderr is line buffered the writes to new file are block-
buffered and, if your program crashes, the buffer isn't written
to the file?

I'm trying to create a library of functions that basically runs with C++
code but with a base set of C functions. That base set of C functions
should be able to handle multiple command line argument syntaxes, like
argtable2 but much simpler (for my own usage).

I've read argtable2 uses get_opt() and getopt_long() so is 100% compatible
with GNU getopt() syntax. However if you want multiple command line
syntaxes and are using only getopt() and getopt_long() both functions
output error messages with the syntaxes that don't match - since there
should be only one command line parameter syntax that matches but you have
to check them all in a while loop (for instance) until you find one that
matches, i.e. during which neither getopt() and getopt_long() return any
error message.

You can "silence" getopt() (i.e. force it not to write to stderr)
by setting 'opterr' to 0, so there's no need to temporarily redirect
stderr if it's only about the error messages from getopt(). You seem
not to be the first to have had that problem;-)

Regards, Jens
--
\ Jens Thoms Toerring ___ [e-mail]
\__________________________ http://toerring.de

[Vince C.]

Jens Thoms Toerring wrote:

....

You can "silence" getopt() (i.e. force it not to write to stderr)
by setting 'opterr' to 0, so there's no need to temporarily redirect
stderr if it's only about the error messages from getopt(). You seem
not to be the first to have had that problem;-)

Thanks a lot for taking your time to reply, Jens. This is exactly what I
needed. I'll use opterr. This is much smarter than what I imagined.

--

Vince C.

[Martin Ambuhl]

Vince C. wrote:

Jens Thoms Toerring wrote:

>>I'd like to temporarily disable standard functions to write to stderr,
i.e.

Can you name a single standard C function that writes to stderr
(of course except those output functions that you tell to write
to stderr - and for those it's already under your control where
they write to)?

Functions getopt() and getopt_long(). They write error messages to stderr
whenever an option is not recognized or there is something wrong with the
command line syntax defined by the application.

Neither getopt() or getopt_long() is a standard C function. It might be
useful for you to review what functions are specific to your
implementation and which are standard C functions. This will have been
a useful exercise if you use what you learn to isolate those
non-standard functions into implementation-specific translation units.
The day that you move out of Bill Gates's empire you will be glad that
you have taken these simple precaution. The day that the next version of
your implementation or of the next update to Windows might also be the
day that you are glad you have isolated those non-standard functions.

[Flash Gordon]

Vince C. wrote, On 14/07/07 21:16:

Jens Thoms Toerring wrote:

>>I'd like to temporarily disable standard functions to write to stderr,
i.e.

Can you name a single standard C function that writes to stderr
(of course except those output functions that you tell to write
to stderr - and for those it's already under your control where
they write to)?

Functions getopt() and getopt_long(). They write error messages to stderr
whenever an option is not recognized or there is something wrong with the
command line syntax defined by the application.

Those are not standard C functions.

>If you use freopen() to redirect stderr to a file then stderr gets
closed. If you somehow can get it back despite having it closed and
then re-redirect back to that again is a question that you have to
ask in a Windows group.

It should be basically as simple as initializing device stderr when the
program starts, shouldn't it?

Maybe, maybe not.

There is code within stdlib that creates an
__iob[2] array of FILE*, each being stdout, stdin and stderr, respectively.

Maybe on your implementations, but it is not required to work like that
else where.

If my programm succeeds in doing the same, i.e. re-initializing stderr with
the default values, the trick is done. So I asked the question if it was
possible.

C provides no mechanism for doing it.

Of course my program is (currently) a Windows application but - while I'm
writing it - I'm building a set of functions that I'll be able to reuse
under whatever platform I want, provided it's running GNU code.

Then ask on a GNU group, although I suspect you will find it depends on
the target platform not on whether you are running GNU code. Unless by
running GNU code you are limiting yourself to systems using the GNU
implementation of the standard C library, which I believe would actually
exclude MinGW and 3/4 of the systems on which I've used gcc.

>>I've checked freopen to redirect stderr to a file but, strangely enough,
error messages don't go to the file :(.

What exactly did you do? Perhaps it's a buffering issue, i.e.
while stderr is line buffered the writes to new file are block-
buffered and, if your program crashes, the buffer isn't written
to the file?

I'm trying to create a library of functions that basically runs with C++
code but with a base set of C functions. That base set of C functions
should be able to handle multiple command line argument syntaxes, like
argtable2 but much simpler (for my own usage).

If C++ is involved you need to ask else where, we don't deal with it here.

I've read argtable2 uses get_opt() and getopt_long() so is 100% compatible
with GNU getopt() syntax. However if you want multiple command line

argtable2, getopt, get_opt and getopt_long are not standard.

<snip>

Hence I'd like to temporarily disable stderr while I'm checking command line
parameter syntaxes since I might get error messages, which is the normal
behaviour of these functions.

You can't in standard C.

>>Also note I'm using stdio and iostream concurrently.

There's no 'iostream' in C, I guess you must be using C++, not C,
and then you should ask in comp.lang.c++.

Yes, I know there is no such iostream in C but iostream uses std* file
descriptors. Hence I suppose I must keep both libraries in sync, i.e. if I
close (or reopen) stderr cerr must be kept in sync so that it "knows" the
stderr file descriptor has changed.

I posted here for it's a C question first. And given the length of this
post, you can easily understand it's a hassle to type it again... ;-)

Ah, so hassle for everyone else is OK but hassle for you is not?

>>Is there a way to, say, close stderr and restore it later on in the same
program under Windows using standard libraries?

You would need to have a file name for stderr to be able to that
since the only function for redirection in standard C is freopen()
and this can only redirect to a file given by path, not to a FILE
pointer. If Windows supplies you with something in the file system
for (an already closed) stderr I can't tell, that you again need to
ask in a Windows group. But this solution then is already system
specific for this reason you probably also don't need to care if
the functions you use are standard C functions...

I'd say "no" since the libraries I'm using implement the same code on all
supported platforms (it's GNU code). So it's completely independent from
Windows.

That does not follow. I have used Windows specifics in code written with
MinGW and things which will not run on Windows using gcc and glibc.

The only difference is there is no /dev/null, as when we redirect
output in shell scripts. I think that device is "nul:" under windows (I
remember batch scripts where I used:

do_something_with_possible_error_messages nul:

All of which is implementation specific. I've programmed on systems
which had neither /dev/null not nul: (or whatever Windows uses), and no
they were not embedded systems.

The only thing I need to know, I suppose, is how does standard C library
initialize stderr so that I can do the same in my program - provided it's
safe, of course. Hence my question(s)...

The answer is as has already been stated implementation specific. So you
need to ask in system specific groups and accept that the answer may be
completely different for Windows using MinGW to Windows using Cygwin to
Windows to Linux to gcc on AIX 4.x to gcc on AIX 5.3 to gcc on SCO 4.x
to gcc on SCO 5.x to...

One off topic hint is that gcc normally uses whatever the normal C
library is on the implementations, so on most implementations it does
not use the GNU implementation of the standard C library.

Yes, there are important differences between what you can do with gcc on
AIX 4.x and AIX 5.3, I know because I have done both and I could do
things with gcc on AIX 5.3 that I could not on AIX 4.x (or had to do
differently, at any rate).
--
Flash Gordon

[Kenny McCormack]

In article <46*********************@read.news.be.uu.net>,
Vince C. <no**@teledisnet.bewrote:

>Tim Prince wrote:

>This isn't a Windows help forum.

I'm not that dumb you know... I just posted enough information so that those
who want to help get the most accurate picture of what I'm trying to do and
on what platform.

Part of the problem is that you mentioned GNU and GNU things like
getopt*, which is, in and of itself, enough to set them off.

However, when you mention the 'W' word, you're really rubbing salt in
their wounds. You can't expect to get away with that.

[Kenny McCormack]

In article <5f*************@mid.individual.net>,
Martin Ambuhl <ma*****@earthlink.netwrote:

>Vince C. wrote:

>Jens Thoms Toerring wrote:

>>>I'd like to temporarily disable standard functions to write to stderr,
i.e.
Can you name a single standard C function that writes to stderr
(of course except those output functions that you tell to write
to stderr - and for those it's already under your control where
they write to)?

Functions getopt() and getopt_long(). They write error messages to stderr
whenever an option is not recognized or there is something wrong with the
command line syntax defined by the application.

Neither getopt() or getopt_long() is a standard C function. It might be
useful for you to review what functions are specific to your
implementation and which are standard C functions. This will have been
a useful exercise if you use what you learn to isolate those
non-standard functions into implementation-specific translation units.
The day that you move out of Bill Gates's empire you will be glad that
you have taken these simple precaution. The day that the next version of
your implementation or of the next update to Windows might also be the
day that you are glad you have isolated those non-standard functions.

It's not like adhering to the standard is going to protect you against
the next version of Windows (or, as you observe, the next service pack,
which is essentially the same thing as "the next version"). MS is under
no obligation to adhere to standards (that they do, to some degree at
least, is more or less an accident).

So, the point is that adherence to standards doesn't get you much,
except acceptance in CLC.

[Vince C.]

Keith Thompson wrote:

>It should be basically as simple as initializing device stderr when the
program starts, shouldn't it? There is code within stdlib that creates an
__iob[2] array of FILE*, each being stdout, stdin and stderr,
respectively. If my programm succeeds in doing the same, i.e.
re-initializing stderr with the default values, the trick is done. So I
asked the question if it was possible.

The C standard says nothing about __iob, or about stdin, stdout, and
stderr being elements of an array.

Googling the Internet about "stdio.c" listed some results which showed such
an implementation.

How do you know that iostream uses std* file descriptors? The C
standard certainly doesn't guarantee this.

That's how iostream are written. Function ios_base::sync_with_stdio() allows
for synchronizing iostream streams with standard C streams. They are
synchronized by default.

--

Vince C.

[Vince C.]

>Vince C. wrote:

>>Warning: troll behind!

Richard wrote:

I have never seen him troll.

In fact I was talking about me: *I* was about to launch a troll.

--

Vince C.

[Richard Heathfield]

Richard said:

Harald van D?k <tr*****@gmail.comwrites:

>Vince C. wrote:

>>>Off topic. Not portable. Cant discuss it here. Blah, blah, blah.

Warning: troll behind!

On occasion Kenny'll provide useful answers, but his troll messages
are best ignored. That said, I disagree with your reply to him.

I have never seen him troll.

Then presumably either you've killfiled him, or you keep your eyes
tightly closed when reading comp.lang.c, or you don't know what
trolling is, or you yourself are a troll.

Pointing out the retentive behaviour of
some of the regulars is a valuable input

No, it isn't. It's a complete waste of time. If P is the magnitude of a
particular poster's positive contributions to the group, and N is the
magnitude of their negative contributions, then they are valuable to
the group if N < P; the greater the difference, the greater the value.
And here's the weird thing - people are perfectly capable of deciding
for themselves whether they consider N < P for any given poster.

From what I've seen of Mr McCormack's articles, his N is huge, and his P
is just about 0. From what I've seen of your articles, your N is pretty
vast, albeit not as big as Mr McCormack's N, and your P is fairly
miniscule, although not as microscopic as Mr McCormack's. So I don't
ascribe any great value to your opinions about the group. If you worked
on your P a bit more, maybe I'd treat your N a bit more seriously. If
you really cared about the people whose interests you claim to be
protecting, you'd provide some high quality answers to their questions.
Instead, you do little but snap, snipe, and sneer.

Having said that, it is certainly true that some of the regular
contributors spend rather too much time berating those who are
incapable of learning. They would do better ignoring them completely.

Those who earnestly desire, and can profit from, high quality C advice
are perfectly capable of acting in a way that won't get them killfiled
by the C experts in this group. Those who can't act in a way that won't
get them killfiled are not going to be able to profit from the advice
they would have got, so no loss there. Let them content themselves with
broken answers from people who remain uncorrected only because nobody
with a clue is reading their articles any more.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Vince C.]

Martin Ambuhl wrote:

Neither getopt() or getopt_long() is a standard C function. It might be
useful for you to review what functions are specific to your
implementation and which are standard C functions. This will have been
a useful exercise if you use what you learn to isolate those
non-standard functions into implementation-specific translation units.

Ok, these are not standards, sorry.

The day that you move out of Bill Gates's empire you will be glad that
you have taken these simple precaution. The day that the next version of
your implementation or of the next update to Windows might also be the
day that you are glad you have isolated those non-standard functions.

Rule number 1: never make assumptions about what the original poster said if
he/she didn't say it explicitly...

I never said *I* had installed W2K;
I never said I was working daily with Windows;
I never said that I liked it;
I never said Windows was my only platform;
I never said I wasn't aware about difference between M$ view of "standard"
and others

And I didn't say that, fed up of Window$, I switched to Gentoo Linux in
March 2004 and that I'm much more happy with it.

I've already moved way from Bill Gates' Empire...

Let me tell you a little about me.

In fact I've spent 10 years studying Windows and developing under Windows. I
started with C and soon C++. I was mainly developing GUI and system
applications while I never wrote console programs.

After I started being upset about losing control of my computer to the
profit of a monopolistic company, I started to look for something that
would allow me to get control aver my machine and to be able to decide what
I put onto it. I was advised Gentoo Linux.

That's the whole story of me.

This is just to warn I'm not a newbie and I hate being thrown at with abrupt
sentences like "You're off-topic". It's like I'd be to be shot at just
because I had pronounced the words "Windows". I said "it's like", I don't
mean it's the real reason.

Damn, I know that it's tempting to treat most Windows user like a computer
illiterate but it's only tempting. Noone's supposed to follow his/her
temptation without thinking a little. I recon there are many people asking
dummy questions and who deserve a blind "RTFM" but there is at least one
person who replied kindly, patiently to my question. I never do that to
anyone. Even with those I consider they are dummies for as dummies as they
are I consider there might always be something I can learn...

Not giving someone the slightest chance to explain is closing the door
before a conversation may occur. It's not my way of thinking.

Stating "Let me be the first to tell you ... [bla bla bla]" is all but a
demonstration of someone who wants to listen before bashing.

I just wonder why so little compassion and understanding. I didn't start my
post throwing bullets at anyone. If I was off topic, there sure was a kind
way to say it. And again, it doesn't prevent from responding in a gentle
way, seeking for the real matter, like another person has.

I have absolutely nothing against you, Martin. I just took the opportunity
of my response to go on a little further on that particular topic.

--

Vince C.

[Vince C.]

Flash Gordon wrote:

Those are not standard C functions.

....

Then ask on a GNU group, although I suspect you will find it depends on
the target platform not on whether you are running GNU code. Unless by
running GNU code you are limiting yourself to systems using the GNU
implementation of the standard C library, which I believe would actually
exclude MinGW and 3/4 of the systems on which I've used gcc.

....

If C++ is involved you need to ask else where, we don't deal with it here.

....

argtable2, getopt, get_opt and getopt_long are not standard.

Ok, these are not standard. But my question pointed at using stderr and only
that. Things like GNU, iostream, Windows and MinGW are the context. My
question didn't deal with them directly. (Although the real solution is to
use opterr but how could I have figured that out since I didn't realize I
had missed something?)

>Hence I'd like to temporarily disable stderr while I'm checking command
line parameter syntaxes since I might get error messages, which is the
normal behaviour of these functions.

You can't in standard C.

Aaah, here we are :-) . Thanks, I didn't know that.
....

>I posted here for it's a C question first. And given the length of this
post, you can easily understand it's a hassle to type it again... ;-)

Ah, so hassle for everyone else is OK but hassle for you is not?

That's not (that it's Ok for anyone else) what I meant, surely not.

Look, I had to make a choice: where should I post my question?

1. comp.lang.c++? Because I'm making C++ applications in general? or
2. something.gnu...? Because I'm using GNU tools? or
3. comp.lang.mingw (provided it existed)? Because I'm using MinGW? or
4. microsoft.public.windows2000...? Because I'm developing for Windows? or
5. comp.lang.c? Because I want to use standard C file descriptors in a way
for which I still need some information?

So should I write the whole story from the beginning, including the dozens
of lines that are irrelevant of the very first question? Or may I hope
someone pays attention to my question, asks the necessary questions to get
more information and, little by little, finally tells me the right
solution?

I've made a choice. And finally I've got answers. Maybe I was a little bit
lame selecting the right forum but I then expect someone to say it gently.
And I also expect good reasons for being off-topic.

Nothing against you personnally but I'm just justifying my choice, which I
shouldn't be supposed to do, IMHO.

--

Vince C.

[Martin Ambuhl]

Vince C. wrote:

Martin Ambuhl wrote:

>Neither getopt() or getopt_long() is a standard C function. It might be
useful for you to review what functions are specific to your
implementation and which are standard C functions. This will have been
a useful exercise if you use what you learn to isolate those
non-standard functions into implementation-specific translation units.

Ok, these are not standards, sorry.

>The day that you move out of Bill Gates's empire you will be glad that
you have taken these simple precaution. The day that the next version of
your implementation or of the next update to Windows might also be the
day that you are glad you have isolated those non-standard functions.

Rule number 1: never make assumptions about what the original poster said if
he/she didn't say it explicitly...

Rule number 1a: Never overlook the actual content of my posts just to
fuel your personal rants ...

>
I never said *I* had installed W2K;
I never said I was working daily with Windows;
I never said that I liked it;
I never said Windows was my only platform;
I never said I wasn't aware about difference between M$ view of "standard"
and others

Big deal. Everything I said applies *no matter what* implementation or
platform you are using. Go vent elsewhere.

[Default User]

Richard Heathfield wrote:

Richard said:

Harald van D?k <tr*****@gmail.comwrites:

On occasion Kenny'll provide useful answers, but his troll messages
are best ignored. That said, I disagree with your reply to him.

I have never seen him troll.

Then presumably either you've killfiled him, or you keep your eyes
tightly closed when reading comp.lang.c, or you don't know what
trolling is, or you yourself are a troll.

The last choice is the correct one. I'm surprised there was any
question.

Brian

[Army1987]

On Sat, 14 Jul 2007 18:32:01 +0000, Jens Thoms Toerring wrote:

Vince C. <no**@teledisnet.bewrote:

>I've installed Bloodshed Dev-C++ on a Windows 2000 SP4 machine. I'm using
MinGW 3.4.2.

>I'd like to temporarily disable standard functions to write to stderr, i.e.

Can you name a single standard C function that writes to stderr

perror()
--
Army1987 (Replace "NOSPAM" with "email")
"Never attribute to malice that which can be adequately explained
by stupidity." -- R. J. Hanlon (?)

[jacob navia]

Richard Heathfield wrote:

[snip]

I think the situation was somewhat complicated by the mention of
Windows, since Windows might reasonably be regarded as what the
Standard calls a "freestanding implementation"; as such, it is not
required to provide support for stdin, stdout, and stderr, and AFAIK it
doesn't.

You are wrong. Windows provides support for stdin, stdout and stderr
The problem with mentioning windows in this newsgroup is that some
people will immediately think that you are a slave of the evil empire
and try to convince you of leaving your sinful ways and attain nirvana
with some linux version...

[Flash Gordon]

Vince C. wrote, On 15/07/07 00:47:

Flash Gordon wrote:

<snip>

>>I posted here for it's a C question first. And given the length of this
post, you can easily understand it's a hassle to type it again... ;-)

Ah, so hassle for everyone else is OK but hassle for you is not?

That's not (that it's Ok for anyone else) what I meant, surely not.

Look, I had to make a choice: where should I post my question?

1. comp.lang.c++? Because I'm making C++ applications in general? or

In general, yes, comp.lang.c++ is a better place to post when building a
C++ application, because C++ provides all sorts of facilities not
available in C including facilities for calling between C and C++. So
folks over in comp.lang.c++ will know what you can do in C++ and how
that will interract with what you can do in C.

2. something.gnu...? Because I'm using GNU tools? or

Actually, once you know that the functions giving you grief a GNU
specific ones (and not knowing that is an acceptable starting point),
yes, going to a GNU group is not a bad thing.

3. comp.lang.mingw (provided it existed)? Because I'm using MinGW? or

The are mingw groups and/or mailing lists I'm sure, so potentially yes.
Again, this applies once you know they are non-standard.

4. microsoft.public.windows2000...? Because I'm developing for Windows? or
5. comp.lang.c? Because I want to use standard C file descriptors in a way
for which I still need some information?

C does not have file descriptors ;-)

Seriously, C++ has the same standard file handles as C, so I would
expect asking about them in comp.lang.c++ would be acceptable, and C++
may be able to do things with them that C cannot.

So should I write the whole story from the beginning, including the dozens
of lines that are irrelevant of the very first question? Or may I hope
someone pays attention to my question, asks the necessary questions to get
more information and, little by little, finally tells me the right
solution?

A better way to ask your questions, and also much shorter, would have
been...

I'm using the getopt and getopt_long functions which are sending output
to stderr. I want to prevent these functions from sending error output
without stopping the rest of the application from writing to stderr.

See, much shorter and contains the important information. Note also that
the above states what you want to achieve, rather than simply saying how
you want to achieve it. By all means go on from there to say how you
were thinking of achieving your desired result, but ALWAYS start be
explaining the real problem you are trying to solve.

I've made a choice. And finally I've got answers. Maybe I was a little bit
lame selecting the right forum but I then expect someone to say it gently.
And I also expect good reasons for being off-topic.

You were given good reasons. You were just very lucky that someone
eventually found out what your real requirements were, rather than what
you initially asked about, and happened to know something about the
functions in question. Had you asked in a GNU group as soon as you were
told that getopt etc were non-standard you would probably have got an
answer much faster, thus benefiting you.

Nothing against you personnally but I'm just justifying my choice, which I
shouldn't be supposed to do, IMHO.

You don't have to justify it, just accept that it is wrong when it is
pointed out to you. You also need to develop a fairly thick skin, since
there are a lot of groups that are very tough, some of them from what I
here much tougher than here. There is also a lot of expertise.
--
Flash Gordon

[Flash Gordon]

jacob navia wrote, On 15/07/07 10:37:

Richard Heathfield wrote:

[snip]

>I think the situation was somewhat complicated by the mention of
Windows, since Windows might reasonably be regarded as what the
Standard calls a "freestanding implementation"; as such, it is not
required to provide support for stdin, stdout, and stderr, and AFAIK
it doesn't.

You are wrong. Windows provides support for stdin, stdout and stderr

True in some situations, not in others. Some implementations on Windows
are freestanding, some are hosted, and with some (e.g. MSVC++, all
versions I've used) whether it is freestanding or hosted depends on how
you use it.

The problem with mentioning windows in this newsgroup is that some
people will immediately think that you are a slave of the evil empire
and try to convince you of leaving your sinful ways and attain nirvana
with some linux version...

Yes, that is a problem. However people also get told they are off topic
with GNU specific stuff, i.e. the GNU implementation of getopt as in
this case.
--
Flash Gordon

[Richard]

"Default User" <de***********@yahoo.comwrites:

Richard Heathfield wrote:

>Richard said:

Harald van D?k <tr*****@gmail.comwrites:

>On occasion Kenny'll provide useful answers, but his troll messages
are best ignored. That said, I disagree with your reply to him.

I have never seen him troll.

Then presumably either you've killfiled him, or you keep your eyes
tightly closed when reading comp.lang.c, or you don't know what
trolling is, or you yourself are a troll.

The last choice is the correct one. I'm surprised there was any
question.

Brian

As one of the worst offenders of loving the sound of your own voice in
the "OT" race, I expected nothing less from you. There appears to be
some kind of "mania" in this group. A shame as there are so many people
who know what they are talking about and could be so more helpful if
they were to drop the snide, picky sides which they use to advertise
their grudging availability between solving the worlds problems out
there in the real world.

[Kenny McCormack]

In article <u4************@news.flash-gordon.me.uk>,
Flash Gordon <sp**@flash-gordon.me.ukwent all parental on you:
....

>You were given good reasons. You were just very lucky that someone
eventually found out what your real requirements were, rather than what
you initially asked about, and happened to know something about the
functions in question. Had you asked in a GNU group as soon as you were
told that getopt etc were non-standard you would probably have got an
answer much faster, thus benefiting you.

Yup, just like that helpful genius Kenny McCormack initially observed.

[Kenny McCormack]

In article <ac************@news.flash-gordon.me.uk>,
Flash Gordon <sp**@flash-gordon.me.ukwrote:

>jacob navia wrote, On 15/07/07 10:37:

>Richard Heathfield wrote:

[snip]

>>I think the situation was somewhat complicated by the mention of
Windows, since Windows might reasonably be regarded as what the
Standard calls a "freestanding implementation"; as such, it is not
required to provide support for stdin, stdout, and stderr, and AFAIK
it doesn't.

You are wrong. Windows provides support for stdin, stdout and stderr

True in some situations, not in others. Some implementations on Windows
are freestanding, some are hosted, and with some (e.g. MSVC++, all
versions I've used) whether it is freestanding or hosted depends on how
you use it.

It is pretty clear you don't know what you are talking about. You know
nothing about Windows, qua Windows and are just trying to use your CLC-ish
and Unix-y words, and appear to know something about a platform that you
despise.

>The problem with mentioning windows in this newsgroup is that some
people will immediately think that you are a slave of the evil empire
and try to convince you of leaving your sinful ways and attain nirvana
with some linux version...

Yes, that is a problem. However people also get told they are off topic
with GNU specific stuff, i.e. the GNU implementation of getopt as in
this case.

Yeah, but not with anywhere near the religious ferver that the 'W' word
inspires among you and the other faithful here.

[Richard Heathfield]

jacob navia said:

Richard Heathfield wrote:

[snip]

>I think the situation was somewhat complicated by the mention of
Windows, since Windows might reasonably be regarded as what the
Standard calls a "freestanding implementation"; as such, it is not
required to provide support for stdin, stdout, and stderr, and AFAIK
it doesn't.

You are wrong. Windows provides support for stdin, stdout and stderr

Well, I didn't say it very well, did I? I apologise for expressing
myself poorly. Yes, if you're writing a console program, you can have
your stdin, stdout, and stderr. But I was in fact thinking specifically
of Win32 API programs, programs that actually use the Windowiness of
Windows. Now, it's entirely possible that Windows programs (of the
WinMain variety, so to speak) can take advantage of stdin/stdout/stderr
support, but I was under the impression that they cannot.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[jacob navia]

Richard Heathfield wrote:

jacob navia said:

>Richard Heathfield wrote:

[snip]

>>I think the situation was somewhat complicated by the mention of
Windows, since Windows might reasonably be regarded as what the
Standard calls a "freestanding implementation"; as such, it is not
required to provide support for stdin, stdout, and stderr, and AFAIK
it doesn't.

You are wrong. Windows provides support for stdin, stdout and stderr

Well, I didn't say it very well, did I? I apologise for expressing
myself poorly. Yes, if you're writing a console program, you can have
your stdin, stdout, and stderr. But I was in fact thinking specifically
of Win32 API programs, programs that actually use the Windowiness of
Windows. Now, it's entirely possible that Windows programs (of the
WinMain variety, so to speak) can take advantage of stdin/stdout/stderr
support, but I was under the impression that they cannot.

The only difference between windows and console programs is that
for console programs the system calls for you the API AllocConsole();
and you start in a "Dos" window. Within a console program you can use
the whole windows API, open windows, call any API function just as any
other windows program.

In the other hand, for "windows" programs, the system does NOT open
a console, and if you want to use stdin stderr and stdout you have to
call the API AllocConsole(). That is the ONLY difference.

[Richard Heathfield]

jacob navia said:

<snip>

The only difference between windows and console programs is that
for console programs the system calls for you the API AllocConsole();
and you start in a "Dos" window. Within a console program you can use
the whole windows API, open windows, call any API function just as any
other windows program.

In the other hand, for "windows" programs, the system does NOT open
a console, and if you want to use stdin stderr and stdout you have to
call the API AllocConsole(). That is the ONLY difference.

Fine - so what you're saying is that stdin, stdout, and stderr are not
available to a Win32 GUI program unless the programmer sets them up
especially by calling a special function. Okay - I didn't know that.
(Because of the source of the information, which is well-known in
comp.lang.c to be unreliable, obviously I'll have to check it myself
before agreeing that it's correct.)

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Vince C.]

Flash Gordon wrote:

>I've made a choice. And finally I've got answers. Maybe I was a little
bit lame selecting the right forum but I then expect someone to say it
gently. And I also expect good reasons for being off-topic.

You were given good reasons. You were just very lucky that someone
eventually found out what your real requirements were, rather than what
you initially asked about, and happened to know something about the
functions in question. Had you asked in a GNU group as soon as you were
told that getopt etc were non-standard you would probably have got an
answer much faster, thus benefiting you.

Technical

When I posted the first time, I *really* believed that the heart of the
question was about stderr, which is C standard. Should I be blamed for
that? Also note my question was still usefull since I learnt I redirecting
stderr to a file is a one-way operation and there is no return. After all,
this is *exactly* what I wanted to know.

I just learnt the matter was off topic *after* I was asked what the context
was, of course. Had I known the stderr stuff was impossible, I wouldn't
even have bothered people asking any question here, of course.

Human

And my other point, which I felt forced to explain after being bashed the
first time, is maybe I was asking in the wrong forum (though I still doubt)
but there are several ways to tell somebody he's wrong, rude and non-rude.

I'm not objecting the technical reasons which tend to make my post
off-topic. I'm obecjting against the human nature of some of the responses.
I'm objecting against the way I was told.

I can cope with the technical reasons even if I disagree but I can't with
the rudeness of some of the people who "answered" - to be polite.

Sure I have to get a thicker skin but I find it so bad people are wasting
their skills with such humanly poor relations. We're all human being and
there are some who seem to have forgotten the definition.

Anyways I'll most probably won't post here ever again.

--

Vince C.

[santosh]

Vince C. wrote:

Flash Gordon wrote:

I've made a choice. And finally I've got answers. Maybe I was a little
bit lame selecting the right forum but I then expect someone to say it
gently. And I also expect good reasons for being off-topic.

You were given good reasons. You were just very lucky that someone
eventually found out what your real requirements were, rather than what
you initially asked about, and happened to know something about the
functions in question. Had you asked in a GNU group as soon as you were
told that getopt etc were non-standard you would probably have got an
answer much faster, thus benefiting you.

<snip>

I can cope with the technical reasons even if I disagree but I can't with
the rudeness of some of the people who "answered" - to be polite.

Sure I have to get a thicker skin but I find it so bad people are wasting
their skills with such humanly poor relations. We're all human being and
there are some who seem to have forgotten the definition.

Anyways I'll most probably won't post here ever again.

Don't let the "rudeness" of a few people prevent you from
participating in this group. If you ever want to learn about C, this
is probably among the best places on the Net to do so. Yes, a handful
are perhaps a bit what you might call as "rude", but you can stop
reading their posts if you choose to. IMHO, almost all of the best
contributors to this group are very helpful.

[Joe Wright]

Vince C. wrote:

Flash Gordon wrote:

>>I've made a choice. And finally I've got answers. Maybe I was a little
bit lame selecting the right forum but I then expect someone to say it
gently. And I also expect good reasons for being off-topic.

You were given good reasons. You were just very lucky that someone
eventually found out what your real requirements were, rather than what
you initially asked about, and happened to know something about the
functions in question. Had you asked in a GNU group as soon as you were
told that getopt etc were non-standard you would probably have got an
answer much faster, thus benefiting you.

Technical

When I posted the first time, I *really* believed that the heart of the
question was about stderr, which is C standard. Should I be blamed for
that? Also note my question was still usefull since I learnt I redirecting
stderr to a file is a one-way operation and there is no return. After all,
this is *exactly* what I wanted to know.

I just learnt the matter was off topic *after* I was asked what the context
was, of course. Had I known the stderr stuff was impossible, I wouldn't
even have bothered people asking any question here, of course.

Human

And my other point, which I felt forced to explain after being bashed the
first time, is maybe I was asking in the wrong forum (though I still doubt)
but there are several ways to tell somebody he's wrong, rude and non-rude.

I'm not objecting the technical reasons which tend to make my post
off-topic. I'm obecjting against the human nature of some of the responses.
I'm objecting against the way I was told.

I can cope with the technical reasons even if I disagree but I can't with
the rudeness of some of the people who "answered" - to be polite.

Sure I have to get a thicker skin but I find it so bad people are wasting
their skills with such humanly poor relations. We're all human being and
there are some who seem to have forgotten the definition.

Anyways I'll most probably won't post here ever again.

You've chosen an excellent whine sir. Perhaps some cheese?

--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---