473,320 Members | 1,965 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,320 software developers and data experts.

scanf (yes/no) - doesn't work + deprecation errors scanf, fopen etc.

Hi,

Consider:
------------
char stringinput[64]

..bla. bla. bla.

do
{
printf("Write to result.txt (y/n)? ");
scanf("%s", stringinput);
}
while (writechar != 'y' || != 'n');
The compiler complaints. It says: error C2059: syntax error : '!='

Another problem is that MS VS 2005 keeps complaining about deprecated
commands such as:

1. warning C4996: 'fscanf' was declared deprecated.......: see
declaration of 'fscanf' - Message: 'This function or variable may be
unsafe. Consider using fscanf_s instead. To disable deprecation, use
_CRT_SECURE_NO_DEPRECATE. See online help for details.'

2. warning C4996: 'scanf' was declared deprecated: see declaration of
'scanf'... Message: 'This function or variable may be unsafe. Consider
using scanf_s instead. To disable deprecation, use ...

3. warning C4996: 'fopen' was declared deprecated.... : see declaration
of 'fopen' Message: 'This function or variable may be unsafe. Consider
using fopen_s instead. To disable deprecation, use
_CRT_SECURE_NO_DEPRECATE. See online help for details.'
How do I fix these problems? Sorry, but I'm not very experienced with C
programming.
Med venlig hilsen / Best regards
Martin Jørgensen

--
---------------------------------------------------------------------------
Home of Martin Jørgensen - http://www.martinjoergensen.dk
Feb 16 '06
185 17163

Richard G. Riley wrote:
On 2006-02-24, Richard Bos <rl*@hoekstra-uitgeverij.nl> wrote:
Niklas Matthies <us***********@nmhq.net> wrote:
On 2006-02-24 07:28, Richard Bos wrote:
:
> gets(), OTOH, is _never_ safe.

Well, that's not necessarily true.

Consider an implementation which provides saturation semantics for
pointer arithmetics
Considering a debugging implementation, or one which has a fixed length
hardware input buffer of 80 chars, one can also imagine that in those
cases gets() would be safe.

Until someone decides that your program is just what they need on their
MS-Windows computer, and recompiles it there.

One big problem with external safeguards for gets() is that there is
nothing in the Standard that requires them, suggests them, or even lets
you find out whether or not they're in place. Nor can there be. This
means that any code which uses gets() must rely, blindly, on what it
gets from the outside - and that information may be unreliable.

Another big problem is that code will be ported, programs will be
recompiled, possibly on another system, possibly on the same system with
different compiler options - IOW, a single compile of some code which
uses gets() _may_ be safe, but that code itself never is.


It is simple enough to see the issue with it : the main issue is that
it is there and needs to remain there to support legacy code. I dont
think the standards commitee will pay for millions of lines to have
system specific handwritten gets() to replace the old one or, god
forbid, to change all the calls themselves to do boundary checks and
use something more robust.

What is the process for C to depreciate something like this? Is it a
new flag to switch it on?

.... Like a lot of buggy old stuff, the people who used it were often not so
stupid and made big enough buffers to cope with the declared range of
inputs. Perfect? No. But worked for them at the time.


The problem occurs when inputs outside the declared range are provided.
No C program has sufficient portable control over it's standard input
to guarantee that this won't happen. Of course, not all programs need
to be portable, and there are non-portable ways to obtain sufficient
control.

I don't think it's good design for a C program to ever have undefined
behavior. When given inputs that are outside it's declared range, it
should fail gracefully. By gracefully, I mean that it should provide
error message in the appropriate log file or stderr, or at least return
a checkable error status to the calling environment. Even if that's not
possible, "failing gracefully" means, as an absolute minimum, that the
behavior of the program is not undefined. It's not possible to use
gets() in a portable fashion while conforming to this guideline.

Feb 24 '06 #101
On 2006-02-24, ku****@wizard.net <ku****@wizard.net> wrote:

Richard G. Riley wrote:
On 2006-02-24, Richard Bos <rl*@hoekstra-uitgeverij.nl> wrote:
> Niklas Matthies <us***********@nmhq.net> wrote:
>
>> On 2006-02-24 07:28, Richard Bos wrote:
>> :
>> > gets(), OTOH, is _never_ safe.
>>
>> Well, that's not necessarily true.
>>
>> Consider an implementation which provides saturation semantics for
>> pointer arithmetics
>
> Considering a debugging implementation, or one which has a fixed length
> hardware input buffer of 80 chars, one can also imagine that in those
> cases gets() would be safe.
>
> Until someone decides that your program is just what they need on their
> MS-Windows computer, and recompiles it there.
>
> One big problem with external safeguards for gets() is that there is
> nothing in the Standard that requires them, suggests them, or even lets
> you find out whether or not they're in place. Nor can there be. This
> means that any code which uses gets() must rely, blindly, on what it
> gets from the outside - and that information may be unreliable.
>
> Another big problem is that code will be ported, programs will be
> recompiled, possibly on another system, possibly on the same system with
> different compiler options - IOW, a single compile of some code which
> uses gets() _may_ be safe, but that code itself never is.
>
It is simple enough to see the issue with it : the main issue is that
it is there and needs to remain there to support legacy code. I dont
think the standards commitee will pay for millions of lines to have
system specific handwritten gets() to replace the old one or, god
forbid, to change all the calls themselves to do boundary checks and
use something more robust.

What is the process for C to depreciate something like this? Is it a
new flag to switch it on?

...
Like a lot of buggy old stuff, the people who used it were often not so
stupid and made big enough buffers to cope with the declared range of
inputs. Perfect? No. But worked for them at the time.


The problem occurs when inputs outside the declared range are

provided.

I think we all realise this and it was addressed above.
No C program has sufficient portable control over it's standard input
to guarantee that this won't happen. Of course, not all programs need
to be portable, and there are non-portable ways to obtain sufficient
control.
Yes, of course.

I don't think it's good design for a C program to ever have undefined
behavior. When given inputs that are outside it's declared range, it
It is not good design for any program to have undefined behaviour : a
lot do unfortunately...
should fail gracefully. By gracefully, I mean that it should provide
error message in the appropriate log file or stderr, or at least return
a checkable error status to the calling environment. Even if that's not
possible, "failing gracefully" means, as an absolute minimum, that the
behavior of the program is not undefined. It's not possible to use
gets() in a portable fashion while conforming to this guideline.


This is not the issue I was raising. Of course it is not good to use
such a function. The issue is with maintenance of HUGE old systems
which do make a lot of use (carefully) of gets() and the like. I have
a fair degree of experience in trouble shooting such systems and
removing gets() would cause a lot of grief to a lot of people. No one
says it is nice but "its done now" as they say. A bit like C++ :-;

Hence my closing comments on compiler warnings.
--
Remove evomer to reply
Feb 24 '06 #102
"Richard G. Riley" <rg****@gmail.com> writes:
[...]
This is not the issue I was raising. Of course it is not good to use
such a function. The issue is with maintenance of HUGE old systems
which do make a lot of use (carefully) of gets() and the like. I have
a fair degree of experience in trouble shooting such systems and
removing gets() would cause a lot of grief to a lot of people. No one
says it is nice but "its done now" as they say. A bit like C++ :-;


gets() cannot be used carefully. (That's a little bit of an
overstatement, but only just barely.)

If gets() were removed by the standard, existing code that uses it
could easily be catered to by using the compiler in a non-standard
mode that provides it. There are plenty of non-standard functions in
most implementations (such as strdup()); there's no reason gets()
couldn't be another one.

gets() is also easy enough to implement yourself if necessary.

Having gets() in the standard is an implied endorsement of a uniquely
dangerous function. Removing it from the standard needn't cause any
significant inconvenience.

--
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.
Feb 24 '06 #103
On 2006-02-24, Keith Thompson <ks***@mib.org> wrote:
"Richard G. Riley" <rg****@gmail.com> writes:
[...]
This is not the issue I was raising. Of course it is not good to use
such a function. The issue is with maintenance of HUGE old systems
which do make a lot of use (carefully) of gets() and the like. I have
a fair degree of experience in trouble shooting such systems and
removing gets() would cause a lot of grief to a lot of people. No one
says it is nice but "its done now" as they say. A bit like C++ :-;
gets() cannot be used carefully. (That's a little bit of an
overstatement, but only just barely.)


defined input from stdio. But not ideal as I was at pains to point
out. Nobody is supporting the robustness of it.

If gets() were removed by the standard, existing code that uses it
could easily be catered to by using the compiler in a non-standard
mode that provides it. There are plenty of non-standard functions
in
Agreed. And what I was suggesting with regard to special compiler options.
most implementations (such as strdup()); there's no reason gets()
couldn't be another one.

gets() is also easy enough to implement yourself if necessary.

Not necessarily on huge (distributed) codebases where you would need
to change the calling code to encompass "to be sure" buffers of the
required size for the unlikely case of 20Gb of characters being force
fed into it.
Having gets() in the standard is an implied endorsement of a uniquely
dangerous function. Removing it from the standard needn't cause any
significant inconvenience.


Other than the need to provide compiler coverage or potentially
humongous work effort to fill the gaps.

I cant immediately see any easy way to just relink in "ones own" gets
since, due to the function parameters, it can not really be any safer other
than somehow catching the out of bounds which could arise. And that in
itself might well screw up a lot of monolithic dinosaurs out there
which have happily been churning away for donkeys years.

Please be sure that I am in no way condoning gets() as a function to
use : rather I am advising caution on the decision to remove
it.

--
Remove evomer to reply
Feb 24 '06 #104
Richard G. Riley wrote:
On 2006-02-24, ku****@wizard.net <ku****@wizard.net> wrote:

Richard G. Riley wrote: ....
Like a lot of buggy old stuff, the people who used it were often not so
stupid and made big enough buffers to cope with the declared range of
inputs. Perfect? No. But worked for them at the time.
The problem occurs when inputs outside the declared range are

provided.

I think we all realise this and it was addressed above.


I didn't get that impression. By referring to those people as "not so
stupid", you imply that the coping mechanism they used was acceptable.
That's what I was disagreeing with. If it doesn't fail gracefully when
given outputs outside it's declared range, it's not acceptable.

.... This is not the issue I was raising. Of course it is not good to use
such a function. The issue is with maintenance of HUGE old systems
which do make a lot of use (carefully) of gets() and the like. I have
a fair degree of experience in trouble shooting such systems and
removing gets() would cause a lot of grief to a lot of people. No one
says it is nice but "its done now" as they say. A bit like C++ :-;


I wasn't disagreeing with that point either. I was only responding to
your implied approval of the legacy code that used gets() "carefully".
Using gets() rather than fgets() was never the right choice, even for
code which relied on non-portable assumptions that made it safe; it may
have been an excusable bad decision in the early days of the language,
but it doesn't deserve approval.

Feb 24 '06 #105
"Keith Thompson" <ks***@mib.org> wrote in message
news:ln************@nuthaus.mib.org...
gets() cannot be used carefully.


But of course it can: you just need to be careful when using a program that
calls gets().
Feb 24 '06 #106
Richard Bos wrote:
I find it scary that someone this condescending can be on the Standard
committee.
...
I find it even scaries that someone who doesn't remember the Morris worm
can be on the Standard committee.


Who's being condescending? I was one of the people who
captured and analyzed the Morris worm at the time. I've
been involved with information security for more than
30 years. Perhaps you should try to understand my point
rather than rejecting it a priori.
Feb 24 '06 #107
"Richard G. Riley" wrote:
What is the process for C to depreciate something like this? Is it a
new flag to switch it on?


The usual standards mechanism is for a newly issued revision
of the standard to flag the item as a "deprecated feature",
which means that it must still be supported by conforming
implementations at least until the next major revision of
the standard. That typically means 10 years at least before
implementations need to do anything differently. It would
be likely that most implementations would continue to include
the function in their library (since it is needed to link
with existing objects), merely disabling the automatic
declaration obtained when the header is #included. It is
by no means obvious that that would benefit anyone.
Feb 24 '06 #108
Richard Bos wrote:
True. But it's a start. As long as gets() has the official OK of the
Standard, the kind of newbie programmer who doesn't look beyond what he
was taught will see that It Is Official, Therefore It Is Good.


If they don't think any more clearly than that,
gets() is the least of their worries. The standard
doesn't cater to sloppy programmers, nor should it.
Feb 24 '06 #109
On 2006-02-24, Douglas A. Gwyn <DA****@null.net> wrote:
"Richard G. Riley" wrote:
What is the process for C to depreciate something like this? Is it a
new flag to switch it on?


The usual standards mechanism is for a newly issued revision
of the standard to flag the item as a "deprecated feature",
which means that it must still be supported by conforming
implementations at least until the next major revision of
the standard. That typically means 10 years at least before
implementations need to do anything differently. It would
be likely that most implementations would continue to include
the function in their library (since it is needed to link
with existing objects), merely disabling the automatic
declaration obtained when the header is #included. It is
by no means obvious that that would benefit anyone.


How about making attempted use of gets() a required diagnostic?

or changing the standard to allow gets() to print an
implementation-defined string to stderr before accepting input
Feb 24 '06 #110
"Richard G. Riley" <rg****@gmail.com> writes:
[...]
gets() is also easy enough to implement yourself if necessary.
Not necessarily on huge (distributed) codebases where you would need
to change the calling code to encompass "to be sure" buffers of the
required size for the unlikely case of 20Gb of characters being force
fed into it.


I don't understand your point here. If gets() is removed from the
standard, it can still be provided by the library. If gets() is
removed from the library, an exactly equivalent function with the same
name would be trivial to write. This replacement would be exactly as
useful, and exactly as dangerous, as the current standard gets().

If replacing all calls to gets() by calls to a safer alternative is
too much effort, *you don't have to do it*.

[snip]
Please be sure that I am in no way condoning gets() as a function to
use : rather I am advising caution on the decision to remove
it.


I don't believe that removing it from the standard would cause any
harm in the real world.

--
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.
Feb 24 '06 #111
"Douglas A. Gwyn" <DA****@null.net> writes:
Richard Bos wrote:
I find it scary that someone this condescending can be on the Standard
committee.
...
I find it even scaries that someone who doesn't remember the Morris worm
can be on the Standard committee.


Who's being condescending? I was one of the people who
captured and analyzed the Morris worm at the time. I've
been involved with information security for more than
30 years. Perhaps you should try to understand my point
rather than rejecting it a priori.


I can't speak for anyone else, but I haven't rejected your point a
priori. I've rejected your point after careful consideration.

--
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.
Feb 24 '06 #112
"Douglas A. Gwyn" <DA****@null.net> writes:
Richard Bos wrote:
True. But it's a start. As long as gets() has the official OK of the
Standard, the kind of newbie programmer who doesn't look beyond what he
was taught will see that It Is Official, Therefore It Is Good.


If they don't think any more clearly than that,
gets() is the least of their worries. The standard
doesn't cater to sloppy programmers, nor should it.


The standard caters to sloppy programmers by providing the gets()
function. It shouldn't.

--
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.
Feb 24 '06 #113
"Richard G. Riley" <rg****@gmail.com> writes:
On 2006-02-24, Richard Bos <rl*@hoekstra-uitgeverij.nl> wrote:
Niklas Matthies <us***********@nmhq.net> wrote:
On 2006-02-24 07:28, Richard Bos wrote:
:
> gets(), OTOH, is _never_ safe.


It is simple enough to see the issue with it : the main issue is that
it is there and needs to remain there to support legacy code. I dont
think the standards commitee will pay for millions of lines to have
system specific handwritten gets() to replace the old one or, god
forbid, to change all the calls themselves to do boundary checks and
use something more robust.


Removing it before deprecation would be mean. Deprecating it, and then
removing it sometime later, would be a very good idea. Keeping in
mind, too, that conforming implementations can still provide access to
the function through the usual means of extending C.

Also, legacy code that actually uses gets() is very likely to use
implementations of previous C standards, rather than implementations
of more current ones. Seems to me, anyway.
Feb 24 '06 #114
"Wojtek Lerch" <Wo******@yahoo.ca> writes:
"Keith Thompson" <ks***@mib.org> wrote in message
news:ln************@nuthaus.mib.org...
gets() cannot be used carefully.


But of course it can: you just need to be careful when using a program that
calls gets().


That's perfectly alright if you're certain to be the only user of your
program, ever. Simple, quick test progs might be alright.

Anything else, you're asking for trouble. I would never dream of
making such a program accessible from the 'Net in any way, or
available to other users on a system I cared to keep.

-Micah
Feb 24 '06 #115
Richard G. Riley wrote:
On 2006-02-24, Keith Thompson <ks***@mib.org> wrote:
"Richard G. Riley" <rg****@gmail.com> writes:
[...]
This is not the issue I was raising. Of course it is not good to use
such a function. The issue is with maintenance of HUGE old systems
which do make a lot of use (carefully) of gets() and the like. I have
a fair degree of experience in trouble shooting such systems and
removing gets() would cause a lot of grief to a lot of people. No one
says it is nice but "its done now" as they say. A bit like C++ :-;
gets() cannot be used carefully. (That's a little bit of an
overstatement, but only just barely.)


defined input from stdio.


Relying upon defined input from stdio in order to avoid producing
undefined behavior does not qualify as careful. It counts as sloppy.
most implementations (such as strdup()); there's no reason gets()
couldn't be another one.

gets() is also easy enough to implement yourself if necessary.


Not necessarily on huge (distributed) codebases where you would need
to change the calling code to encompass "to be sure" buffers of the
required size for the unlikely case of 20Gb of characters being force
fed into it.


I believe he's talking about providing your own gets() replacement,
with behavior identical to that of the gets() currently provided by the
standard library. This would require changing all of the gets() calls
to refer to the replacement, #inclusion of the appropriate non-standard
header in each source code file where that replacement is needed: it's
simple enough that it could probably be safely automated. Of course,
the non-standard file should contain something like the following:

#ifndef BUFFER_OVERRUNS_INVITED
#error Use of mygets() allows buffer overruns.
#endif

The required #define of BUFFER_OVERRUNS_INVITED would help document the
danger you've decided is worth living with.

No matter what happens, increased safety for code that uses gets()
requires source code re-writes that are hard to automate. If you've got
a sufficiently strong need for increased safety to justify such
re-writes, you don't need your own user-defined replacement for the
standard gets(), just replace all of the gets() calls with fgets()
calls.
I cant immediately see any easy way to just relink in "ones own" gets
since, due to the function parameters, it can not really be any safer other
than somehow catching the out of bounds which could arise. And that in


Defining your own replacement for gets() isn't for increased safety,
it's to allow your old, unsafe code to continue to be buildable with
exactly the same lack of safety, even if gets() is no longer part of
the standard library.

Feb 24 '06 #116
"Douglas A. Gwyn" <DA****@null.net> writes:
Richard Bos wrote:
True. But it's a start. As long as gets() has the official OK of the
Standard, the kind of newbie programmer who doesn't look beyond what he
was taught will see that It Is Official, Therefore It Is Good.


If they don't think any more clearly than that,
gets() is the least of their worries. The standard
doesn't cater to sloppy programmers, nor should it.


Nor could it, without changing the language entire. However, if we sum
up the points that have been made:

1. gets() is virtually impossible to use safely.
2. Deprecating it would serve as a warning to would-be users.
3. Deprecating and later removing it would likely not produce
any notable effect in the real world for some time.
4. But it hopefully would eventually.

So essentially, your arguments, AIUI, have been that it would only do
a little good. But, I think most of us lurkers at clc are saying:
"little good is better than nothing". And I haven't heard any actual
arguments from you as to why we should not do it, only why doing it
would not amount to much. (I'm discounting your comparison of it with
other unsafe functions that may still be used safely under some
conditions.)

-Micah
Feb 24 '06 #117
Douglas A. Gwyn wrote:
The standard
doesn't cater to sloppy programmers, nor should it.


It shouldn't, but it does.

%lf now allowed for doubles with printf.
return statement no longer required in main.

--
pete
Feb 24 '06 #118
Keith Thompson wrote:
"Douglas A. Gwyn" <DA****@null.net> writes:
Richard Bos wrote:
I find it scary that someone this condescending can be on the Standard
committee.
...
I find it even scaries that someone who doesn't remember the Morris worm
can be on the Standard committee.

Who's being condescending? I was one of the people who
captured and analyzed the Morris worm at the time. I've
been involved with information security for more than
30 years. Perhaps you should try to understand my point
rather than rejecting it a priori.


I can't speak for anyone else, but I haven't rejected your point a
priori. I've rejected your point after careful consideration.


Same here. Including after noting and commenting on in this thread the
fact that the more harmless implicit int *has* been removed from the
standard and this has not suddenly rendered millions of lines of code
using it unusable.

If anyone thinks removing implicit int was a good thing because it adds
a requirement for using a function without a declaration in scope, there
was a more direct way the same result could have been achieved. Adding a
requirement that there be a declaration in scope.

If it take 5 years to get it deprecated and another 10 years to get it
removed it is *still* worth starting the process. If the process is not
started it will *never* finish.

If removing it is truly such a scary prospect (and I've yet to see an
argument for that which I consider to be strong) then as someone else
stated mandating that a diagnostic be produced for it's use would be a
start.
--
Flash Gordon
Living in interesting times.
Web site - http://home.flash-gordon.me.uk/
comp.lang.c posting guidlines and intro -
http://clc-wiki.net/wiki/Intro_to_clc
Feb 24 '06 #119
On 2006-02-24, Micah Cowan <mi***@cowan.name> wrote:
"Wojtek Lerch" <Wo******@yahoo.ca> writes:
"Keith Thompson" <ks***@mib.org> wrote in message
news:ln************@nuthaus.mib.org...
> gets() cannot be used carefully.


But of course it can: you just need to be careful when using a program that
calls gets().


That's perfectly alright if you're certain to be the only user of your
program, ever. Simple, quick test progs might be alright.

Anything else, you're asking for trouble. I would never dream of
making such a program accessible from the 'Net in any way, or
available to other users on a system I cared to keep.


On most systems that would only be a danger if the code is running with
rights that you don't want the other users / internet users to be able
to gain access to. You certainly can't get root from a non-setuid
program.
Feb 24 '06 #120
Wojtek Lerch wrote:
"Keith Thompson" <ks***@mib.org> wrote in message
news:ln************@nuthaus.mib.org...
gets() cannot be used carefully.

But of course it can: you just need to be careful when using a program that
calls gets().

I don't see a smiley. Are you serious? How is one 'careful' when using a
program which calls gets()?

This is one of the oldest talking points in this newsgroup. The
overwhelming consensus is that gets() cannot be used safely where you do
not control the input to stdin. Dan Pop said he could use it safely but
only on a specific hardware of his own design. That doesn't count.

--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---
Feb 24 '06 #121
"Jordan Abel" <ra*******@gmail.com> wrote in message
news:sl***********************@random.yi.org...
On most systems that would only be a danger if the code is running with
rights that you don't want the other users / internet users to be able
to gain access to. You certainly can't get root from a non-setuid
program.


Well, there also is the theoretical possibility that after gets() overwrites
the return address on the stack, your program happens to jump to the
"remove" function, and the memory that the function thinks its argument
points to happens to contain a sequence of bytes that matches the name of an
important file.

And let's not forget about the possibility that the person running your
program is your boss and that seeing it crash may affect his decision about
whether to give you a raise.
Feb 24 '06 #122
"Joe Wright" <jo********@comcast.net> wrote in message
news:Ir******************************@comcast.com. ..
Wojtek Lerch wrote:
"Keith Thompson" wrote...
gets() cannot be used carefully. But of course it can: you just need to be careful when using a program
that calls gets().

I don't see a smiley. Are you serious? How is one 'careful' when using a
program which calls gets()?


By avoiding to type very long strings into its stdin, obviously.
This is one of the oldest talking points in this newsgroup. The
overwhelming consensus is that gets() cannot be used safely where you do
not control the input to stdin.


Well, exactly. It can be used safely, if you do control the input to stdin.
Feb 24 '06 #123
In article <43**************@null.net>, Douglas A. Gwyn
<DA****@null.net> writes
The usual standards mechanism is for a newly issued revision
of the standard to flag the item as a "deprecated feature",
which means that it must still be supported by conforming
implementations at least until the next major revision of
the standard. That typically means 10 years at least before
implementations need to do anything differently.


You mean like we did with implicit int? :-)

If something is so bad that the consensus is that it can never be used
safely we should not be endorsing it in any way. We should have the
courage to tell the world today that gets() will not be in the next
release of the C Standard whenever it is that we decide to produce one.
--
Francis Glassborow ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects
Feb 25 '06 #124
In article <87************@mcowan.barracudanetworks.com>, Micah Cowan
<mi***@cowan.name> writes
Removing it before deprecation would be mean.


Well I think that the meanness is in not removing it. I get tired of the
number of books for novices that still use gets(). As long as it is in
the Standard authors will just argue that they are using the standard
library.

If we removed it tomorrow, not a single program would fail but we could
condemn those that continue to teach its use and they would have
absolutely no defence.
--
Francis Glassborow ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects
Feb 25 '06 #125
Keith Thompson wrote:
I don't believe that removing it from the standard would cause any
harm in the real world.


Nor benefit.
It would actually cause new problems due to removal of the
declaration from <stdio.h>.
Specification of an interface in the standard doesn't imply
blessing its use in contexts where it isn't appropriate;
if it did, we'd have to remove all the interfaces.
Further, so long as it is easy to find the specification for
gets(), it can readily be used as an example when teaching
student programmers about overrun issues, so it might make
a positive net contribution to safer programming.
Certainly, anyone using gets() where it could pose a safety
problem (which contrary to trendy claims is *not* everywhere)
must be so oblivious to the relevant issues that even the
(unlikely) total ansence of the function from his development
environment wouldn't make him an appreciably safer programmer.
Feb 25 '06 #126
Jordan Abel wrote:
How about making attempted use of gets() a required diagnostic?
or changing the standard to allow gets() to print an
implementation-defined string to stderr before accepting input


No, you would be mandating breaking programs that did not
exhibit a problem before, perhaps because they used gets()
only in contexts where it was sufficiently safe. Causing
other people problems in order to promote your own political
agenda is one of the banes of modern life, and we don't need
to encourage more of that.
Feb 25 '06 #127
pete wrote:
%lf now allowed for doubles with printf.
That was actually in the reference implementation of the
base library, and seems to have been intended to permit
wider sharing of the same format string by printf and
scanf.
return statement no longer required in main.


Yes, and there was heated debate about that. The only
real selling point for the change is that it retroactively
sanctioned that usage in the earlier examples in K&R2
(until section 1.7), which failed to be strictly
conforming programs only in that one respect. Apparently
requiring all conforming implementations to make those
examples work without weird undefined behavior (such as
system messages saying that the programs report failure)
was considered a worthy goal. Anyway, as 1.7 shows, it
wasn't sloppiness when K&R did it that way. (We even had
a discussion about the matter when I reviewed a draft of
the book before it was published.)
Feb 25 '06 #128
Douglas A. Gwyn wrote:
Keith Thompson wrote:
I don't believe that removing it from the standard would cause any
harm in the real world.
Nor benefit.
It would actually cause new problems due to removal of the
declaration from <stdio.h>.


It would cause certain programs to fail at compile time that should
fail. I don't see that as a seriouis problem, particularly since the
function will always be available as non-standard extension, even if it
is someday removed from the standard library.
Specification of an interface in the standard doesn't imply
blessing its use in contexts where it isn't appropriate;
No, but it implies, in this case falsely, that there are at least some
contexts where it is appropriate. You can put together contrived cases
where gets() is actually safe, but there are none where it's
appropriate, when fgets() is available.
Certainly, anyone using gets() where it could pose a safety
problem (which contrary to trendy claims is *not* everywhere)
It's close enough to everywhere. While there are non-portable ways in
which a program can have sufficient control over it's standard input to
allow safe use of gets(), the standard should mainly be concerned with
the needs of portable code, where no such control is possible.
must be so oblivious to the relevant issues that even the
(unlikely) total ansence of the function from his development
environment wouldn't make him an appreciably safer programmer.


It would make his programs marginally safer. In the absence of good
reasons for not doing it, even that marginal improvement would still be
worthwhile.

Feb 25 '06 #129
"Douglas A. Gwyn" <DA****@null.net> writes:
Jordan Abel wrote:
How about making attempted use of gets() a required diagnostic?
or changing the standard to allow gets() to print an
implementation-defined string to stderr before accepting input


No, you would be mandating breaking programs that did not
exhibit a problem before, perhaps because they used gets()
only in contexts where it was sufficiently safe. Causing
other people problems in order to promote your own political
agenda is one of the banes of modern life, and we don't need
to encourage more of that.


I don't believe that there are a significant number of programs that
use gets() safely. I believe there are a plethora of programs that
use it unsafely. Leaving Jordan's suggestions aside, simply removing
gets() from the standard would not break a single one of them.

--
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.
Feb 25 '06 #130
"Douglas A. Gwyn" <DA****@null.net> writes:
Keith Thompson wrote:
I don't believe that removing it from the standard would cause any
harm in the real world.


Nor benefit.


Obviously, I disagree.

Prior to the ANSI standard, strdup() was commonly part of the C
library, right? Why did the C89 standard include gets() but not
strdup()? If gets() had been dropped from the standard back in 1989,
would that have been a bad thing; would you have (or did you) argue
for including it?

--
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.
Feb 25 '06 #131
On 2006-02-25, Douglas A. Gwyn <DA****@null.net> wrote:
Jordan Abel wrote:
How about making attempted use of gets() a required diagnostic?
or changing the standard to allow gets() to print an
implementation-defined string to stderr before accepting input
No, you would be mandating breaking programs that did not
exhibit a problem before, perhaps because they used gets()
only in contexts where it was sufficiently safe.


What contexts are those?
Causing
other people problems in order to promote your own political
agenda is one of the banes of modern life, and we don't need
to encourage more of that.


A required diagnostic does NOT mean a program must fail to compile. Many
implementations _DO_ emit a diagnostic if they detect that gets() is
being used.
Feb 25 '06 #132
On 2006-02-25, Douglas A. Gwyn <DA****@null.net> wrote:
pete wrote:
%lf now allowed for doubles with printf.


That was actually in the reference implementation of the
base library, and seems to have been intended to permit
wider sharing of the same format string by printf and
scanf.


Where is this "reference implementation"?
Feb 25 '06 #133
On 2006-02-25, Douglas A. Gwyn <DA****@null.net> wrote:
Yes, and there was heated debate about that. The only real selling
point for the change is that it retroactively sanctioned that usage in
the earlier examples in K&R2 (until section 1.7), which failed to be
strictly conforming programs only in that one respect.
Ironic, then, that this was the same version of the standard that
removed implicit int.
Apparently requiring all conforming implementations to make those
examples work without weird undefined behavior (such as system
Well, at least it's a constraint violation now.
messages saying that the programs report failure) was considered a
worthy goal. Anyway, as 1.7 shows, it wasn't sloppiness when K&R did
it that way. (We even had a discussion about the matter when I
reviewed a draft of the book before it was published.)

Feb 25 '06 #134
"Douglas A. Gwyn" <DA****@null.net> writes:
Certainly, anyone using gets() where it could pose a safety
problem (which contrary to trendy claims is *not* everywhere)

^^^^^^

"You keep using that word. I do not think it means what you think it
means."

You also keep talking about the fact that it is not truly impossible
to use gets() safely (given certain nonportable situations). While
this may be literally true, I strongly suspect that we could count the
number of totally safe usages using our hands. Even when it really
/is/ safe, the *huge* majority of safety-conscious coders will /still/
refuse to use it. I expect that the safe use of it is so incredibly
rare, you're worrying about nothing.

In any case, as has already been pointed out by more than one person,
simply removing it from the Standard is certainly /not/ going to
"suddenly break" all the existing legacy code.

The changes from C90 to C99 were /far/ more likely to break migrated
code than the removal of gets() would be.
Feb 25 '06 #135
ptk
On 2006-02-16 15:41:23 -0600, Al Balmer <al******@att.net> said:
On Thu, 16 Feb 2006 13:09:03 -0600, Broeisi <br*******@gmail.com>
wrote:
This code will do what you want...

#include <stdio.h>

int main(void)
{
char stringInput;

do
{
printf("\nWrite to result.txt (y/n)? ");
stringInput = getchar();
__fpurge(stdin); // clear the stdin to strip off the previous newline char.

???__ fpurge? What page of the standard is that on?
[snip]


man fpurge

I think he meant fpurge not __fpurge. At any rate, fpurge is in stdio

Feb 25 '06 #136
On 2006-02-25, ptk <pt*@nospam4me.net> wrote:
On 2006-02-16 15:41:23 -0600, Al Balmer <al******@att.net> said:
On Thu, 16 Feb 2006 13:09:03 -0600, Broeisi <br*******@gmail.com>
wrote:
This code will do what you want...

#include <stdio.h>

int main(void)
{
char stringInput;

do
{
printf("\nWrite to result.txt (y/n)? ");
stringInput = getchar();
__fpurge(stdin); // clear the stdin to strip off the previous newline char.

???__ fpurge? What page of the standard is that on?
[snip]


man fpurge

I think he meant fpurge not __fpurge. At any rate, fpurge is in stdio


but not in standard c.
Feb 25 '06 #137

"Keith Thompson" <ks***@mib.org> wrote in message
news:ln************@nuthaus.mib.org...
"Douglas A. Gwyn" <DA****@null.net> writes:
Jordan Abel wrote:
How about making attempted use of gets() a required diagnostic?
or changing the standard to allow gets() to print an
implementation-defined string to stderr before accepting input


No, you would be mandating breaking programs that did not
exhibit a problem before, perhaps because they used gets()
only in contexts where it was sufficiently safe. Causing
other people problems in order to promote your own political
agenda is one of the banes of modern life, and we don't need
to encourage more of that.


I don't believe that there are a significant number of programs that
use gets() safely. I believe there are a plethora of programs that
use it unsafely. Leaving Jordan's suggestions aside, simply removing
gets() from the standard would not break a single one of them.


Why stop with gets()? Why don't you just list all features of C you think
are

1) unsafe
2) useless
3) unstructured
4) lacking sufficient bits, etc...

Mentally remove the features from C, and ask yourself this: "Have I
recreated Java? Or worse, Pascal?"
Rod Pemberton
Feb 25 '06 #138
ptk wrote:
On 2006-02-16 15:41:23 -0600, Al Balmer <al******@att.net> said:
On Thu, 16 Feb 2006 13:09:03 -0600, Broeisi <br*******@gmail.com>
wrote:
This code will do what you want...

#include <stdio.h>

int main(void)
{
char stringInput;

do
{
printf("\nWrite to result.txt (y/n)? ");
stringInput = getchar();
__fpurge(stdin); // clear the stdin to strip off the previous
newline char.

???__ fpurge? What page of the standard is that on?
[snip]


man fpurge

I think he meant fpurge not __fpurge. At any rate, fpurge is in stdio


Whichever he meant it is not in stdio.h on my system, and nor is it part
of the language. It may be an extension available on your system but
that is a different matter. Here we only deal with standard C.
--
Flash Gordon
Living in interesting times.
Web site - http://home.flash-gordon.me.uk/
comp.lang.c posting guidlines and intro -
http://clc-wiki.net/wiki/Intro_to_clc
Feb 25 '06 #139
Rod Pemberton wrote:
"Keith Thompson" <ks***@mib.org> wrote in message
news:ln************@nuthaus.mib.org...
"Douglas A. Gwyn" <DA****@null.net> writes:
Jordan Abel wrote:
How about making attempted use of gets() a required diagnostic?
or changing the standard to allow gets() to print an
implementation-defined string to stderr before accepting input
No, you would be mandating breaking programs that did not
exhibit a problem before, perhaps because they used gets()
only in contexts where it was sufficiently safe. Causing
other people problems in order to promote your own political
agenda is one of the banes of modern life, and we don't need
to encourage more of that. I don't believe that there are a significant number of programs that
use gets() safely. I believe there are a plethora of programs that
use it unsafely. Leaving Jordan's suggestions aside, simply removing
gets() from the standard would not break a single one of them.


Why stop with gets()? Why don't you just list all features of C you think
are

1) unsafe
2) useless
3) unstructured
4) lacking sufficient bits, etc...


The reason has already been stated in this thread by more than one
person. gets is the only function that it is *impossible* to use safely
without a lot of things completely outside of the standard, and even if
you go outside the standard it is still exceedingly hard to make the use
of gets safe.
Mentally remove the features from C, and ask yourself this: "Have I
recreated Java? Or worse, Pascal?"


Get rid of uncontrolled level crossings on blind bends and you still
have a railway and road system, but you no longer have a feature that is
impossible to use safely.

There are other features of the language you would have to work hard to
convince me to use, but I'm not arguing for there removal.
--
Flash Gordon
Living in interesting times.
Web site - http://home.flash-gordon.me.uk/
comp.lang.c posting guidlines and intro -
http://clc-wiki.net/wiki/Intro_to_clc
Feb 25 '06 #140
Rod Pemberton wrote:
....
Why stop with gets()?


a) We shouldn't stop with gets(), In the long run, every feature of the
C standard that can be improved while staying within the spirit of C
should be improved, sooner or later. All that we're saying is that
removal of gets() should have been high on the list of features to be
removed from C, even way back when it was first standardized. The fact
that the standard has gone through several amendments and one full
revision since then, and gets() is still not even deprecated, is quite
hard to understand.

b) The reason why gets() should be high on the list has been repeatedly
pointed out in this thread. It is unique among all of the other
problematic features of C, in that there is essentially NO safe way to
use it (Doug's assertions to the contrary notwithstanding), and there
has always been a safer alternative.

Feb 25 '06 #141
ptk wrote:
On 2006-02-16 15:41:23 -0600, Al Balmer <al******@att.net> said:
On Thu, 16 Feb 2006 13:09:03 -0600, Broeisi <br*******@gmail.com>
wrote:
This code will do what you want...

#include <stdio.h>

int main(void)
{
char stringInput;

do
{
printf("\nWrite to result.txt (y/n)? ");
stringInput = getchar();
__fpurge(stdin); // clear the stdin to strip off the previous
newline char.


???__ fpurge? What page of the standard is that on?
[snip]

man fpurge

I think he meant fpurge not __fpurge. At any rate, fpurge is in stdio

It is in my DJGPP setup but nonetheless..

Syntax
------

#include <stdio.h>

int fpurge(FILE *file);

Description
-----------

If FILE designates a buffered stream open for writing or for both
reading and writing, this function purges the stream's buffer without
writing it to disk. Otherwise, it does nothing (so it has no effect on
read-only streams such as `stdin').

Return Value
------------

Zero on success, -1 on failure.

Portability
-----------

not ANSI, not POSIX

Read it and weep.
--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---
Feb 25 '06 #142
"Rod Pemberton" <do*********@sorry.bitbucket.cmm> writes:
"Keith Thompson" <ks***@mib.org> wrote in message
news:ln************@nuthaus.mib.org...

[...]
I don't believe that there are a significant number of programs that
use gets() safely. I believe there are a plethora of programs that
use it unsafely. Leaving Jordan's suggestions aside, simply removing
gets() from the standard would not break a single one of them.


Why stop with gets()? Why don't you just list all features of C you think
are

1) unsafe
2) useless
3) unstructured
4) lacking sufficient bits, etc...

Mentally remove the features from C, and ask yourself this: "Have I
recreated Java? Or worse, Pascal?"


You really haven't been paying attention, have you?

I'm stopping with gets() because gets() is uniquely dangerous.
The reasons have been explained many times.

--
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.
Feb 25 '06 #143

"Keith Thompson" <ks***@mib.org> wrote in message
news:ln************@nuthaus.mib.org...
"Rod Pemberton" <do*********@sorry.bitbucket.cmm> writes:
"Keith Thompson" <ks***@mib.org> wrote in message
news:ln************@nuthaus.mib.org...

[...]
I don't believe that there are a significant number of programs that
use gets() safely. I believe there are a plethora of programs that
use it unsafely. Leaving Jordan's suggestions aside, simply removing
gets() from the standard would not break a single one of them.


Why stop with gets()? Why don't you just list all features of C you think are

1) unsafe
2) useless
3) unstructured
4) lacking sufficient bits, etc...

Mentally remove the features from C, and ask yourself this: "Have I
recreated Java? Or worse, Pascal?"


You really haven't been paying attention, have you?

I'm stopping with gets() because gets() is uniquely dangerous.
The reasons have been explained many times.


It's also a low use function that noone really cares about and is rarely
used. People who do care about it use safer functions. And, I think you
missed the point of my statement. If you can correct problems with C, why
not just fix all of them? It's hard to believe that you think gets() is the
absolute worst feature or problem with C. But, for a guy who heavily argued
over a single bit difference with P.J. Plauger, I guess it might be the most
important thing to you.
Rod Pemberton


Feb 25 '06 #144
Rod Pemberton wrote:
"Keith Thompson" <ks***@mib.org> wrote in message
news:ln************@nuthaus.mib.org...
"Rod Pemberton" <do*********@sorry.bitbucket.cmm> writes:
"Keith Thompson" <ks***@mib.org> wrote in message
news:ln************@nuthaus.mib.org... [...]
I don't believe that there are a significant number of programs that
use gets() safely. I believe there are a plethora of programs that
use it unsafely. Leaving Jordan's suggestions aside, simply removing
gets() from the standard would not break a single one of them.
Why stop with gets()? Why don't you just list all features of C you think are

1) unsafe
2) useless
3) unstructured
4) lacking sufficient bits, etc...

Mentally remove the features from C, and ask yourself this: "Have I
recreated Java? Or worse, Pascal?"

You really haven't been paying attention, have you?

I'm stopping with gets() because gets() is uniquely dangerous.
The reasons have been explained many times.


It's also a low use function that noone really cares about and is rarely
used.


The problem is it *is* *still* *used*. Just search this group for all
the times people use gets.
People who do care about it use safer functions.
If it didn't exist, no one would use it.
And, I think you
missed the point of my statement. If you can correct problems with C, why
not just fix all of them?
Because most of the other dangerous features (or problems) have at least
some redeeming points, sometimes the redeeming point being that it
allows you to write your low level HW access routines in what is
basically C with one or two system specific assumptions (i.e. converting
0x1234 to a pointer will give you a pointer to some HW register you need
to access).
It's hard to believe that you think gets() is the
absolute worst feature or problem with C.
It's easy to believe, since it is the only feature that fundamentally
*cannot* be used safely.
But, for a guy who heavily argued
over a single bit difference with P.J. Plauger, I guess it might be the most
important thing to you.


I'm sure there are far more important things to Keith, just as there are
to me. For example, whether my new notebook arrives next week as
promised is far more important to me.
--
Flash Gordon, living in interesting times.
Web site - http://home.flash-gordon.me.uk/
comp.lang.c posting guidelines and intro:
http://clc-wiki.net/wiki/Intro_to_clc
Feb 25 '06 #145
In article <fd******************************@comcast.com>
Joe Wright <jo********@comcast.net> wrote:
[The fpurge() function] is in my DJGPP setup but nonetheless.. [... snippage]If FILE designates a buffered stream open for writing or for both
reading and writing, this function purges the stream's buffer without
writing it to disk. Otherwise, it does nothing (so it has no effect on
read-only streams such as `stdin'). [...]Portability
-----------
not ANSI, not POSIX


And not compatible with the 4.4BSD fpurge() (which I wrote):

The function fpurge() erases any input or output buffered in the given
stream. For output streams this discards any unwritten output. For input
streams this discards any input read from the underlying object but not
yet obtained via getc(3); this includes any text pushed back via ungetc.

Hence, there are multiple functions with the same or similar names
that do different things. This is one of several risks you take
if you choose to use non-Standard functions.
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.
Feb 26 '06 #146
Chris Torek wrote:
Joe Wright <jo********@comcast.net> wrote:
[The fpurge() function] is in my DJGPP setup but nonetheless..

[... snippage]
If FILE designates a buffered stream open for writing or for
both reading and writing, this function purges the stream's
buffer without writing it to disk. Otherwise, it does nothing
(so it has no effect on read-only streams such as `stdin').

[...]
Portability
-----------
not ANSI, not POSIX


And not compatible with the 4.4BSD fpurge() (which I wrote):

The function fpurge() erases any input or output buffered in the
given stream. For output streams this discards any unwritten
output. For input streams this discards any input read from the
underlying object but not yet obtained via getc(3); this
includes any text pushed back via ungetc.

Hence, there are multiple functions with the same or similar names
that do different things. This is one of several risks you take
if you choose to use non-Standard functions.


Your version seems eminently useful, and offhand I see no reason
for it not to be implementable on all C systems. Not portably
implementable, however. Which, to me, is an excellent reason to
incorporate it in the standard.

It might return EOF if at EOF, 0 for success, positive for error.
Maybe it does.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>
Also see <http://www.safalra.com/special/googlegroupsreply/>
Feb 26 '06 #147
On 2006-02-24, Keith Thompson <ks***@mib.org> wrote:
"Richard G. Riley" <rg****@gmail.com> writes:
[...]
gets() is also easy enough to implement yourself if necessary.
Not necessarily on huge (distributed) codebases where you would need
to change the calling code to encompass "to be sure" buffers of the
required size for the unlikely case of 20Gb of characters being force
fed into it.


I don't understand your point here. If gets() is removed from the
standard, it can still be provided by the library. If gets() is


End of subject there. I was under the impression that pitchfork and
torch crowd wanted it removed completely. So no real argument from me.
removed from the library, an exactly equivalent function with the same
name would be trivial to write. This replacement would be exactly as
useful, and exactly as dangerous, as the current standard gets().

If replacing all calls to gets() by calls to a safer alternative is
too much effort, *you don't have to do it*.

[snip]
Please be sure that I am in no way condoning gets() as a function to
use : rather I am advising caution on the decision to remove
it.


I don't believe that removing it from the standard would cause any
harm in the real world.


Assuming as it is still there , then no.

--
Remove evomer to reply
Feb 26 '06 #148
"Wojtek Lerch" <Wo******@yahoo.ca> wrote:
"Joe Wright" <jo********@comcast.net> wrote in message
news:Ir******************************@comcast.com. ..
This is one of the oldest talking points in this newsgroup. The
overwhelming consensus is that gets() cannot be used safely where you do
not control the input to stdin.


Well, exactly. It can be used safely, if you do control the input to stdin.


Sure. But this involves bondage gear, a single-user computer that has
never been connected to any kind of network, and deleting the executable
immediately after the single run. Even then, you'd better not slip while
entering your allotted 128 - oops, 127 - characters.

Richard
Feb 27 '06 #149
"Douglas A. Gwyn" <DA****@null.net> wrote:
Richard Bos wrote:
I find it scary that someone this condescending can be on the Standard
committee.
...
I find it even scaries that someone who doesn't remember the Morris worm
can be on the Standard committee.
Who's being condescending?


Someone who dismisses an opinion held by many people for years as
"trendy".
I was one of the people who
captured and analyzed the Morris worm at the time. I've
been involved with information security for more than
30 years.
Then you should know better than to continue to support one of its entry
holes.
Perhaps you should try to understand my point rather than rejecting it a priori.


Perhaps you should not dismiss an opinion I've held for years now as "a
priori".

Richard
Feb 28 '06 #150

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

2
by: Juggernaut | last post by:
Hi I was trying to write a script to replace some text inside some tags. Lets say I had <tag stuff=stuff><tag stuff=otherstuff><another> I wanted it to find all the <tag and remove them. So...
11
by: Savas Ates | last post by:
CREATE PROCEDURE st_deneme @userid numeric (18) ,@result numeric (18) output AS select * from users return "10" GO **************************** <!--METADATA TYPE="typelib" NAME="Microsoft...
7
by: Wen | last post by:
Hi everyone, ..After my first lesson, I have to create a asp page with: ..asp tag for time ..client script that runs at the server for date ..client script that runs at client and shows a...
0
by: Daniel | last post by:
how to make sure a xsl document has valid xsl syntax? i tried loading it into an xml document but that doesnt show syntax errors inside attributes such as "foo/bar" vs "bar\foo"
13
by: nigel.t | last post by:
Using linux <?php exec("/bin/tar -cvzf myfile.tgz /home/",$arrayout,$returnval); ?> or perhaps try it on your system and tell me if it does/doesnt and what your linux is? I've also tried
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
0
by: jfyes | last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
0
by: CloudSolutions | last post by:
Introduction: For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
0
by: af34tf | last post by:
Hi Guys, I have a domain whose name is BytesLimited.com, and I want to sell it. Does anyone know about platforms that allow me to list my domain in auction for free. Thank you
0
by: Faith0G | last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...
0
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome former...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.