Help...
Dave 'Yes, I'm weird' Newton
==========================
#include <stdio.h>
main ()
{
char h[];
scanf ("%s", h);
printf ("%s\n", h);
}
==========================
It seems innocent enuf, but just prints garbage. I'm missing something
obvious, but I'll be darned if I know what it is.
--
David L. Newton | dne...@carroll1.UUCP | Quote courtesy of
(414) 524-7343 (work) | dne...@carroll1.cc.edu | Marie Niechwiadowicz,
(414) 524-6809 (home) | 100 NE Ave, Waukesha, WI 53186 | Boston College.
[Q]: How many surrealists does it take to screw in a light bulb? [A]: The fish.
Austin Ziegler
dne...@carroll1.UUCP (Dave 'Yes, I'm weird' Newton) said:
Dave> Relay-Version: version B 2.10.3 4.3bds beta 6/6/85; site bu-cs.BU.EDU
Dave> Date-Received: 10 Oct 89 01:39:31 GMT
Dave> Why doesn't this work?
Dave> ==========================
Dave> #include <stdio.h>
Dave> main ()
Dave> {
Dave> char h[];
Dave> scanf ("%s", h);
Dave> printf ("%s\n", h);
Dave> }
Dave> ==========================
Dave> It seems innocent enuf, but just prints garbage. I'm missing something
Dave> obvious, but I'll be darned if I know what it is.
I don't know, but I just tried it. One possibility is to strcat a \0
to the end of h before printf'ing h. Otherwise, you can get the same
result from char *h, and not get too many problems.
\|/ Elminster, Sage of Shadowdale
-*-
/|\ aus...@bucsf.bu.edu
Anton Rang
>dne...@carroll1.UUCP (Dave 'Yes, I'm weird' Newton) said:
>Dave> Relay-Version: version B 2.10.3 4.3bds beta 6/6/85; site bu-cs.BU.EDU
>Dave> Date-Received: 10 Oct 89 01:39:31 GMT
>
>Dave> Why doesn't this work?
>
>Dave> ==========================
>Dave> #include <stdio.h>
>Dave> main ()
>Dave> {
>Dave> char h[];
>Dave> scanf ("%s", h);
>Dave> printf ("%s\n", h);
>Dave> }
>Dave> ==========================
>
>Dave> It seems innocent enuf, but just prints garbage. I'm missing something
>Dave> obvious, but I'll be darned if I know what it is.
>
>result from char *h, and not get too many problems.
[ This is not a flame, just a clarification, OK? ]
There is no difference between "char h[]" and "char *h" in a
declaration; they do exactly the same thing. This program fails
because there is no storage allocated for the string.
The "char h[]", or "char *h", declares a *pointer* to a character
array. It doesn't allocate any storage space for the array, though.
"scanf" happily uses the random contents of the pointer, which may
well point onto the stack, into unwritable locations, etc. In the
best case, this would generate a run-time error.
You need to either allocate an array:
char h[80];
or allocate a pointer, and then space for an array:
char *h, *malloc();
h = malloc(80);
Either one of these techniques will work.
+----------------------------------+------------------+
| Anton Rang (grad student) | ra...@cs.wisc.edu |
| University of Wisconsin--Madison | |
+----------------------------------+------------------+
David Yang
>
> Dave> Why doesn't this work?
>
> Dave> ==========================
> Dave> #include <stdio.h>
> Dave> main ()
> Dave> {
> Dave> char h[];
> Dave> scanf ("%s", h);
> Dave> printf ("%s\n", h);
> Dave> }
> Dave> ==========================
>
Try char h[some constant for the max str. length expected]
e.g., char h[80];
You can see the difference if you "cc -S" both versions and use "diff",
or whatever file comparing command your system has,
on the .s (assembly language) files created.
Note that declarations like "char h[]" are okay for parameters of functions
since in that case they are treated just like a pointer (i.e., char *h)
since when an array is an argument in a function call, it's address gets
passed.
Hope this was somewhat comprehensible,
David Yang
d-y...@cs.columbia.edu
the
Richard O'Keefe
> Dave> ==========================
> Dave> #include <stdio.h>
> Dave> main ()
> Dave> {
> Dave> char h[];
> Dave> scanf ("%s", h);
> Dave> printf ("%s\n", h);
> Dave> }
> Dave> ==========================
I thought, "this is just too obvious, no point me replying".
Appears it's not obvious.
char h[];
doesn't actually allocate any chars. So where is the scanf() supposed
to put them? Scanf doesn't allocate strings for you, you have to give
it pointers to blocks which already exist. When I tried this with gcc
it said
zabbo.c:4: array size missing in `h'
and it was absolutely right. Declare
#define MaxLineSize 512 /* or whatever you fancy */
char h[MaxLineSize];
Also, be very careful when using scanf(). After making the correction,
if the input file is " foo baz \n" the output will be "foo\n".
You may find fgets() easier to drive.
Doug Gwyn
-In article <39...@bu-cs.BU.EDU> aus...@bucsf.bu.edu (Austin Ziegler) writes:
->dne...@carroll1.UUCP (Dave 'Yes, I'm weird' Newton) said:
->Dave> #include <stdio.h>
->Dave> main ()
->Dave> {
->Dave> char h[];
->Dave> scanf ("%s", h);
->Dave> printf ("%s\n", h);
->Dave> }
-> I don't know [ ... ] you can get the same
->result from char *h, and not get too many problems.
-[ This is not a flame, just a clarification, OK? ]
-There is no difference between "char h[]" and "char *h" in a
-declaration; they do exactly the same thing.
What is this, comp.lang.c.morons?
[ This IS a flame! ]
At least Rang got one thing right:
-This program fails because there is no storage allocated for the string.
Joe English
>[ This is not a flame, just a clarification, OK? ]
>
>There is no difference between "char h[]" and "char *h" in a
>declaration; they do exactly the same thing. This program fails
>because there is no storage allocated for the string.
To clarify your clarification, char h[] and char *h
are different in some contexts. Most noticeably,
/* in file foo.c */
char *h;
/* in file bar.c */
extern char h[];
will break. char *h; says that the object stored at
&h is a pointer to char(s). char h[]; says that the
object stored at &h is itself a char (or vector thereof).
In the declaration of a function argument, they are
indeed the same, but as a local variable they are not.
(Is 'char h[]' as a local variable even legal? If so,
what does it mean?)
--Joe English
Conor P. Cahill
> main ()
> {
> char h[];
^^
You need to specify the size of the array. Otherwise your scanf will overwrite
other data on the stack and usualy will cause a core dump.
> scanf ("%s", h);
> printf ("%s\n", h);
> }
--
+-----------------------------------------------------------------------+
| Conor P. Cahill uunet!virtech!cpcahil 703-430-9247 !
| Virtual Technologies Inc., P. O. Box 876, Sterling, VA 22170 |
+-----------------------------------------------------------------------+
Conor P. Cahill
> to the end of h before printf'ing h. Otherwise, you can get the same
> result from char *h, and not get too many problems.
You can't scanf(.) into a char *h without first assigning the *h to point to
a real storage area.
nickolas.landsberg
> Dave> Why doesn't this work?
> Dave> main ()
> Dave> {
> Dave> char h[];
> Dave> scanf ("%s", h);
> Dave> printf ("%s\n", h);
> Dave> }
> Dave> obvious, but I'll be darned if I know what it is.
> I don't know, but I just tried it. One possibility is to strcat a \0
> to the end of h before printf'ing h. Otherwise, you can get the same
> result from char *h, and not get too many problems.
PLEASE!
Don't post an answer unless you know what the (expletive deleted)
you're talking about! Neither char h[] nor char *h reserve any storage
for the data. IMHO, the compiler which allowed an automatic to be used
in such a way is brain-dead, but that's another issue. The first poster
got garbage, as he should have. The fact that it worked for the second
poster was unfortunate, at best.
As an aside, scanf() DOES null-terminate strings, therefore
the strcat() "solution" is bogus. (Did you ever stop to think of how
strcat knows where the end of the original string is?)
Grumpy
david.f.prosser
>Why doesn't this work?
>
>==========================
>#include <stdio.h>
>main ()
>{
> char h[];
> scanf ("%s", h);
> printf ("%s\n", h);
>}
>==========================
>
> It seems innocent enuf, but just prints garbage. I'm missing something
>obvious, but I'll be darned if I know what it is.
The C compiler you are using allowed you to declare an automatic array
of characters with an unspecified length. The behavior of such a program
is undefined (and no diagnostic is required) according to the pANS.
Section 3.5, page 58, lines 30-31 (semantics):
If an identifier for an object is declared with no linkage, the
type for the object shall be complete by the end of its declarator,
or by the end of its init-declarator if it has an initializer.
(An array with an unspecified length is an incomplete type.)
What some compilers have done (still do) is declare a zero-sized object
with an address on the stack. If you are unlucky, when the scanf call
overwrites other parts of the stack, all that happens is that garbage
is printed. What this program deserves is to dump core because the
return address for scanf's stack frame is overwritten. This would let
you know (quickly) that something pretty basic is wrong.
A followup article asserted that "char h[];" in this context is the
same as "char *h;". This is incorrect. The latter declares a pointer
to one or more characters, but the value of the pointer is indeterminate
(uninitialized); such a pointer, when passed to scanf, will likewise
cause undefined behavior unless it is assigned a valid address. The
former declaration, if accepted at all, most likely declares a zero-
length array, but at least its address is known, and if carefully
handled, can be useful. (But not in the above example.)
Probably, this program wants a fixed-sized array of characters for h.
The following includes this and a few other changes as well.
#include <stdio.h>
main()
{
char h[1024];
if (scanf("%1023s", h) == 1) /* room for \0 */
printf("%s\n", h);
return 0;
}
Dave Prosser ...not an official X3J11 answer...
The Lint Program
(Dave 'Yes, I'm weird' Newton) writes:
>main ()
>{
> char h[];
> scanf ("%s", h);
> printf ("%s\n", h);
>}
t.c:
t.c(4): null storage definition
scanf returns value which is always ignored
printf returns value which is always ignored
Austin Ziegler
cpc...@virtech.UUCP (Conor P. Cahill) said:
Conor> In article <39...@bu-cs.BU.EDU>, aus...@bucsf.bu.edu (Austin
Conor> Ziegler) writes:
> I don't know, but I just tried it. One possibility is to strcat a \0
> to the end of h before printf'ing h. Otherwise, you can get the same
> result from char *h, and not get too many problems.
Conor> You can't scanf(.) into a char *h without first assigning the *h to
Conor> point to a real storage area.
Oops. Yes, you do need to assign the *h to point to a real storage
area. My mistake. Everybody makes them sometime. Thanks for the kind
clarification, unlike someone who posted an unnecessary flame. As I said
earlier, it also might help to make sure that you strcat a '\0' just to
insure that the string is properly defined. I have had problems like that
before and this solved it.
\|/ Elminster, Sage of Shadowdale
-*-
/|\ aus...@bucsf.bu.edu (the REAL address)
Chris Torek
>>>{
>>> char h[];
>>> scanf ("%s", h);
Someone writes:
>> I don't know [ ... ] you can get the same
>>result from char *h, and not get too many problems.
Dr. Lint has already posted his opinion of the above program.
I daresay it would be no better for `char *h'.
In article <RANG.89O...@derby.cs.wisc.edu> ra...@cs.wisc.edu (Anton Rang)
writes:
>[ This is not a flame, just a clarification, OK? ]
(It would be OK if it were right.)
>There is no difference between "char h[]" and "char *h" in a
>declaration; they do exactly the same thing.
This is false. `char h[]' can only be used in three places: after
the word `extern', declaring h as an external array, size unknown,
of char; statically or globally, before an initialiser, declaring
h as a global or static array of size determined by the initialiser,
type char; or in a formal parameter declaration, declaring h as a
pointer to char. (ANSI may add local automatic aggregate initialisers
to this list, modifying the second clause.)
Only in the last case---as a parameter declaration---is `char h[]'
rewritten by the compiler as `char *h'.
>This program fails because there is no storage allocated for the string.
This much is correct.
> The "char h[]", or "char *h", declares a *pointer* to a character
>array.
`char h[]', as a local variable, declares h as an array of zero
characters, not as a pointer. This is not legal C, although many
compilers do not diagnose it.
`char *h' always declares a pointer.
>It doesn't allocate any storage space for the array, though.
Assuming the compiler meekly accepts `char h[0]' (here spelled
`char h[]'), this is quite right.
>"scanf" happily uses the random contents of the pointer,
The referent here is missing: `the' pointer. There are actually
three pointers, for the call
scanf("%s", h)
is a three-part expression, all parts of which resolve to pointers.
First we have
scanf <function call context>
which implicitly declares scanf() as a function of unknown arguments
returning int, locates scanf somehow, and resolves to an rvalue
expression of type `pointer to function of unknown returning int',
whose value is the location (in some nebulous fashion) of scanf.
I shall write this as <value, ptr to fn (?) ret int, points to scanf>.
Next we have
"%s"
in a normal expression context. (Double quoted strings have a special
meaning in an initialiser context when being used to initialise an
array of char.) This generates (somewhere---likely in read-only
memory) the three-character sequence '%','s','\0' and names this
object. It is thus an <object, array 3 of char, value `%s\0'>; being
in an expression (rvalue) context, we apply the rule for C arrays in
such contexts and change this to <value, ptr to char, points to `%s\0'>.
Finally, we have
h
also in an expression context. H is (assuming our compiler has
accepted it) <object, array 0 of char, value `'> and we apply the
same rule, obtaining <value, ptr to char, points to zero chars>.
The two <value, ptr to char ...> values are packaged up, mailed to the
function indicated by the <value, ptr to fn ...> value, and scanf
gets control.
All we know of scanf is its description in some standards text or
manual. In this case, we expect it to read one string (by its first
argument) and stuff the `char's of the string in the location given by
its second argument. That second argument, however, points to zero
`char's, so if scanf stuffs even a single character, it will have
overrun the actual space provided.
When scanf returns, the result is a <value, int, ?>. To fill in the
question mark we need not only the description of scanf, but also
knowledge about whatever scanf scanned from stdin. That was not
specified, so there is nothing we can add here.
>In the best case, this would generate a run-time error.
Right. (Well, actually, the best case is a compile-time error,
since h is array-of-zero-char. Make it h[1] and then the best case
is a run-time error.)
>You need to either allocate an array:
>
> char h[80];
>
>or allocate a pointer, and then space for an array:
>
> char *h, *malloc();
>
> h = malloc(80);
>
>Either one of these techniques will work.
Both will, however, be limited to some fixed number of characters (80
above, and that 80 includes the '\0' stuffed by scanf to mark the end
of however many characters it stuffs).
--
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain: ch...@cs.umd.edu Path: uunet!mimsy!chris
Conor P. Cahill
> Oops. Yes, you do need to assign the *h to point to a real storage
> area. My mistake. Everybody makes them sometime. Thanks for the kind
> clarification, unlike someone who posted an unnecessary flame. As I said
> earlier, it also might help to make sure that you strcat a '\0' just to
Just in case you didn't know, strcat works by looking for the null terminator
on the first (target) string, so the null has to be there anyway.
If you do a strcat(str,"\0"), it should be a null operation (do nothing) since
this is the same as strcat(str,"").
If you do a strcat(str,'\0'), you should get a sore dump, or at least
undetermined results (whats at address 0?).
Henry Spencer
>...undetermined results (whats at address 0?).
Dragons, waiting hungrily to eat your program.
--
A bit of tolerance is worth a | Henry Spencer at U of Toronto Zoology
megabyte of flaming. | uunet!attcan!utzoo!henry he...@zoo.toronto.edu
James Shankland
>area. My mistake. Everybody makes them sometime. Thanks for the kind
>clarification, unlike someone who posted an unnecessary flame. As I said
>earlier, it also might help to make sure that you strcat a '\0' just to
>insure that the string is properly defined. I have had problems like that
>before and this solved it.
Good Lord.
Why don't you try slaughtering a goat over your terminal, and letting the
blood drip into the keyboard? I had problems once, and *that* solved it.
Randomly trying things, in the absence of an understanding of what's
really going on, is no way to solve a computer problem. Your suggestion
is nonsense: not because I say so, or because you're an Aries, or anything
like that, but because C is a programming language, not an evil, arbitrary
God that you try to appease with an offering of a strcat().
Was it Mark Twain who said it's not what people don't know that's the
problem, it's all the things they know that are false?
jas
Norman Diamond
>There is no difference between "char h[]" and "char *h" in a
>declaration; they do exactly the same thing.
char h[];
h = malloc(27); /* should generate an error message */
char *h;
h = malloc(27); /* should work */
Mr. Rang's posting proceeded to give a reasonably correct answer to
someone's question, but this bit of nonsense was a poor start.
--
Norman Diamond, Sony Corp. (diamond%ws.son...@uunet.uu.net seems to work)
The above opinions are inherited by your machine's init process (pid 1),
after being disowned and orphaned. However, if you see this at Waterloo or
Anterior, then their administrators must have approved of these opinions.
Richard Childers
>Why doesn't this work?
>
>#include <stdio.h>
>main ()
>{
> char h[];
> scanf ("%s", h);
> printf ("%s\n", h);
>}
I compiled it and ran it without problems, on a Sun 3/50 running SunOS 3.5.
It did complain about a segmenttation fault and dump core, though. Probably
related to the fact that nowhere is the size of h[] defined. I defined it
and the problem went away.
If you think about it from the compiler's point of view, it makes sense. It
allocates space as it is told to. If you don't allocate space, it might or
might not make an educated guess, hand you a predetermined buffer of a fixed
size, or hand you nothing but a pointer to a single byte, assuming you mean
to define h[] as h[1].
> It seems innocent enuf, but just prints garbage. I'm missing something
>obvious, but I'll be darned if I know what it is.
Hope this is of assistance ...
>David L. Newton | dne...@carroll1.UUCP | Quote courtesy of
>(414) 524-7343 (work) | dne...@carroll1.cc.edu | Marie Niechwiadowicz,
>(414) 524-6809 (home) | 100 NE Ave, Waukesha, WI 53186 | Boston College.
-- richard
--
* A CITIZEN: "Who might you be ? Samson ? --" *
* CYRANO: "Precisely. Would you kindly lend me your jawbone ?" *
* from _Cyrano de Bergerac_, by Edmond Rostand *
* ..{amdahl|decwrl|octopus|pyramid|ucbvax}!avsd.UUCP!childers *
Richard Childers
>ra...@cs.wisc.edu (Anton Rang) writes:
>-[ This is not a flame, just a clarification, OK? ]
>-There is no difference between "char h[]" and "char *h" in a
>-declaration; they do exactly the same thing.
>What is this, comp.lang.c.morons?
I think that is quite uncalled for. This is a newsgroup dedicated towards
helping novices get their feet under them, as well as answering particular
oddball questions best resolved through consensus. A little tolerance is
not inappropriate.
>[ This IS a flame! ]
I liked Anton's clarification better. He was trying to help, and I saw no
misinformation in _his_ posting, although he _did_ quote someone else who
was pretty confused.
>At least Rang got one thing right:
Oh, c'mon, he's trying to be helpful. Are you ?
Perhaps we need a com.lang.c.wiz for those too busy to help beginners.
Joe English
This article is not about C, it's about comp.lang.c.
Hit N now if you're not interested:
chil...@avsd.UUCP (Richard Childers) writes:
>gw...@brl.arpa (Doug Gwyn) writes:
>>ra...@cs.wisc.edu (Anton Rang) writes:
>>-[ This is not a flame, just a clarification, OK? ]
>>-There is no difference between "char h[]" and "char *h" in a
>>-declaration; they do exactly the same thing.
>>What is this, comp.lang.c.morons?
>
>I think that is quite uncalled for. This is a newsgroup dedicated towards
>helping novices get their feet under them, as well as answering particular
>oddball questions best resolved through consensus. A little tolerance is
>not inappropriate.
Doug Gwyn happens to be one of the more knowledgeable
and helpful posters on this group. I think it's fair
to allow him his occasional belligerence, which is
generally justifiable even if it is "inappropriate."
>>[ This IS a flame! ]
>
>I liked Anton's clarification better. He was trying to help, and I saw no
>misinformation in _his_ posting, although he _did_ quote someone else who
>was pretty confused.
There was misinformation in his posting:
char *h; and char h[]; are not identical.
>>At least Rang got one thing right:
>
>Oh, c'mon, he's trying to be helpful. Are you ?
Maybe not in this particular posting, but for the most
part, yes. He answers most of the "Stupid
Questions" that come up in this group, as well as
the non-stupid ones. Again, I don't think an
occasional flame is unforgivable. At least he looked
before he flamed. Did you?
>Perhaps we need a com.lang.c.wiz for those too busy to help beginners.
If you've read any of the stats for this group, (like
the "Bandwidth Wasters Hall of Fame" recently posted
by a certain notorious idiot) you'd see that Mr. Gwyn
is by no means "too busy to help beginners." If you
feel he has a bad attitude, then use lint (or Chris
Torek :-).
Followups to misc.test. Rather than start an endless
argument about netiquette, we now return to the
regularly scheduled endless argument about the programming
language.
--Joe English
Doug Gwyn
>gw...@brl.arpa (Doug Gwyn) writes:
>I think that is quite uncalled for. This is a newsgroup dedicated towards
My complaint was not at all with the original novice question,
but rather with the raft of incorrect "answers" posted by people
who didn't know what they were talking about.
Such ignorant wrong answers add to novice confusion.
It is such postings that are uncalled for.
David T. Sandberg
>It did complain about a segmenttation fault and dump core, though.
Just curious: how does a segmentation fault and a core dump equate
to "compiled and ran without problems"?
--
David Sandberg - Quadric Systems
"I began neglecting my shoes." PSEUDO: d...@quad.uucp
ACTUAL: ..uunet!rosevax!sialis!quad!dts
Alan J Rosenthal
>This is a newsgroup dedicated towards helping novices get their feet under
>them, as well as answering particular oddball questions best resolved through
>consensus.
Says who?
% grep 'comp\.lang\.c ' /usr/lib/news/newsgroups
comp.lang.c Discussion about C.
%
Orn E. Hansen
> dne...@carroll1.UUCP (Dave 'Yes, I'm weird' Newton) said:
>
> Dave> ==========================
> Dave> #include <stdio.h>
> Dave> main ()
> Dave> {
> Dave> char h[];
> Dave> scanf ("%s", h);
> Dave> printf ("%s\n", h);
> Dave> }
> Dave> ==========================
>
The code 'char h[]' equals 'char *h'. This pointer doesn't point to any
space that can hold any value's, it points to a random point naturally
giving random results.
The pointer probably points to your stack (the unused portion), so when
calling 'printf' it alters the space scanned by 'scanf' thus printing
garbage (I guess ...).
------------------------------------------------------------------------
Orn Hansen
National Hospital of Iceland, Internet: o...@rsp.is
Computer Department.
Orn E. Hansen
> Why don't you try slaughtering a goat over your terminal, and letting the
> blood drip into the keyboard? I had problems once, and *that* solved it.
>
If people BELIEVE that will solve there problem, who are we to say
othervise?
>
> Randomly trying things, in the absence of an understanding of what's
> really going on, is no way to solve a computer problem.
>
Randomly trying things gives you a multiple perspective to observe a single
point. Sometimes called SCIENCE, and used to gain new ways and methods to
help humanity on it's path through life.
How would you othervise come to know, what isn't known? to understand what
is misunderstood?
Chris Torek
No. Please do not make this claim; it is false. We just went through
this (probably my other followups have not reached Iceland yet).
T. William Wells
: In article <18...@pasteur.Berkeley.EDU>, j...@postgres.uucp (James Shankland) writes:
: > Why don't you try slaughtering a goat over your terminal, and letting the
: > blood drip into the keyboard? I had problems once, and *that* solved it.
: >
: If people BELIEVE that will solve there problem, who are we to say
: othervise?
Reasoning individuals, as opposed to superstitious savages.
All too many "modern" humans are.
: > Randomly trying things, in the absence of an understanding of what's
: > really going on, is no way to solve a computer problem.
: >
: Randomly trying things gives you a multiple perspective to observe a single
: point. Sometimes called SCIENCE, and used to gain new ways and methods to
: help humanity on it's path through life.
Ignorant fool.
Randomly trying things is the farthest thing from science.
Scientists try new things, but they do so because they have reasons.
:
: How would you othervise come to know, what isn't known? to understand what
: is misunderstood?
By thinking and directed activity, which you obviously don't believe
in. And are clearly not accustomed to.
Followups have been directed to alt.flame.
---
Bill { uunet | novavax | ankh | sunvice } !twwells!bill
bi...@twwells.com
Chris Torek
>writes:
>>Randomly trying things, in the absence of an understanding of what's
>>really going on, is no way to solve a computer problem.
In article <143@.rsp.is> o...@rsp.is (Orn E. Hansen) writes:
>Randomly trying things gives you a multiple perspective to observe a single
>point. Sometimes called SCIENCE, and used to gain new ways and methods to
>help humanity on it's path through life.
Randomly trying things is not called `science', it is called `poking
about'. It can indeed give you a better perspective. It is not,
however, very efficient. It is best used only when nothing else is
available.
>How would you othervise come to know, what isn't known? to understand what
>is misunderstood?
In this case, by a very simple method: read the description of the
components being used. The `computer problem' being `solved' is the
analysis as to what a certain bit of C source code might do when
compiled and/or run. There is a direct way to find out what C code
means, and that is to read and apply the language definition.
Doug Gwyn
No, we generally consider somebody who randomly tries things as a very
poor scientist.
>How would you othervise come to know, what isn't known? to understand what
>is misunderstood?
You can reason about things on the basis of the experience and knowledge
you already have. When that is insufficient, you should at least have
identified specifically the gap in your knowledge, so you can take NON-
random steps to find out what else you need to know.
There is really no excuse for randomly poking around in C; there are
numerous good text and reference books about C to which you could refer.
Ray Dunn
>> really going on, is no way to solve a computer problem.
>>
>Randomly trying things gives you a multiple perspective to observe a single
>point. Sometimes called SCIENCE, and used to gain new ways and methods to
>help humanity on it's path through life.
Randomly trying things **to solve a computer software problem** is probably
the single most abhorent thing I have to contend with when dealing with
junior (and sometimes not-so-junior) programmers.
The chaos is not caused when this "technique" is used to explore the limits
of the problem, but when it is used to find a "solution" (i.e. "that has
made the problem go away = the problem has been solved").
--
Ray Dunn. | UUCP: r...@philmt.philips.ca
Philips Electronics Ltd. | ..!{uunet|philapd|philabs}!philmtl!ray
600 Dr Frederik Philips Blvd | TEL : (514) 744-8200 Ext : 2347 (Phonemail)
St Laurent. Quebec. H4M 2S9 | FAX : (514) 744-6455 TLX : 05-824090
Jim Harkins
>No, we generally consider somebody who randomly tries things as a very
>poor scientist.
At my old company we called such people 'managers'.
jim