lubich@ethz.UUCP (Hannes Lubich) (11/16/86)
Well, I'm trapped.
When using something like :
while (fgets (teststring, 100, myfptr) != NULL)
if (do_something_with_string (teststring)) {
fclose (myfptr);
return 1;
}
fclose (myfptr);
return 0;
I get 'Illegal instruction' when returning (both 1 and 0), if
the filesize is greater than 0 (but the string which is read from
file is correct).
When the filesize is 0 the return works correct but it's not too
useful then.
Furthermore when I declare teststring as : char teststring[];
the above result appears but when I try to declare it as
char *teststring; I get a 'Bus error' at once.
Could somebody give me a hint about that misterious 'fgets' ?
Thanks
Hannes
{known world}!cernvax!ethz!lubichgreg@utcsri.UUCP (Gregory Smith) (11/17/86)
In article <408@ethz.UUCP> lubich@ethz.UUCP (Hannes Lubich) writes: >Well, I'm trapped. >When using something like : > while (fgets (teststring, 100, myfptr) != NULL) ... bombs on return... >Furthermore when I declare teststring as : char teststring[]; >the above result appears but when I try to declare it as >char *teststring; I get a 'Bus error' at once. > >Could somebody give me a hint about that misterious 'fgets' ? Did you try 'char teststring[100]'? fgets doesn't allocate storage for you. When you declare 'char teststring[];', you get a zero-byte array, and then pass its address to fgets, meanwhile you are telling fgets that there are 100 bytes there. So fgets scribbles all over your stack frame, and the return address is destroyed. If you say 'char *teststring', you are passing the pointer itself to fgets without initializing it to anything. So fgets writes the string to an undefined area. -- ---------------------------------------------------------------------- Greg Smith University of Toronto UUCP: ..utzoo!utcsri!greg Have vAX, will hack...
ubi@sri-unix.ARPA (Ron Ueberschaer) (11/17/86)
In article <408@ethz.UUCP> lubich@ethz.UUCP (Hannes Lubich) writes: >Well, I'm trapped. > > while (fgets (teststring, 100, myfptr) != NULL) >.... > fclose (myfptr); > >I get 'Illegal instruction' when returning (both 1 and 0), if >.... >Furthermore when I declare teststring as : char teststring[]; ^^^^^^^^^^^^^^^^^ >the above result appears but when I try to declare it as >char *teststring; I get a 'Bus error' at once. ^^^^^^^^^^^^^^^^ >.... > {known world}!cernvax!ethz!lubich Well, I don't know about the problem of return status, but I *do* know that you need to allocate some memory for "teststring". Both declarations above only allow teststring to point to the location of a previously defined character (or array thereof). It is possible that the empty brackets declaration finds an unallocated byte of memory and initializes teststring to point there, thus explaining the different results you observed. Why not try this declaration: char teststring[100]; Good luck! Ron Ueberschaer ubi@sri-unix.UUCP {know world}!{hplabs,rutgers}!sri-unix!ubi
throopw@dg_rtp.UUCP (Wayne Throop) (11/19/86)
> lubich@ethz.UUCP (Hannes Lubich) > char teststring[]; > ...fgets(teststring, 100, myfptr)... > [this gets "illegal instruction" when the procedure that contains this > returns, unless the fgets gets nothing from the f] > char *teststring; > ...fgets(teststring, 100, myfptr)... > [this gets "bus error" at the fgets] Um. Well. Let me put it this way. You promised fgets that you would allocate 100 bytes of storage for it to get things into from the f. Remember that second argument? The 100? Well... you lied, you see. That isn't nice. In the first case, the compiler didn't complain about an illegal array declaration, and allocated zero bytes for the array. Then, the poor fgets (confused by the pervarication of the second argument) clobbered the return frame, causing the return to land in the middle of some random memory location, where there was indeed (I suspect) an illegal instruction. In the second case, the compiler did just what was said perfectly. Unfortunately what was said was that teststring is a pointer to an undefined place (in particular, teststring was not initialized to point to 100 characters). Again, poor fgets relied on the promise implied by its second argument, and in this case, when it tried to reference memory that wasn't even there (through the uninitialized pointer that was the first argument), the hardware slapped its "hand", yielding a bus error. To fix the problem, keep your promise to fgets by allocating 100 bytes of storage, either by char teststring[100]; ...fgets(teststring, 100, myfptr)... or by char *teststring; teststring = (char *)malloc(100); ...fgets(teststring, 100, myfptr)... Further, it is worth noting that lint will NOT normally catch the first error. (I consider this a bug in lint, as well as a common pcc bug. I think Guy Harris has posted fixes for these, but I could be wrong). On the other hand, lint *WILL* probably catch the second error, saying: warning: teststring may be used before set Lastly, I will note that this type of error is symptomatic of not understanding the differences between arrays and pointers, and not understanding allocation very well. I suggest further study of the Holy Scripture of K&R, and rigid fasting. Scourging and wearing of hair shirts is no longer in fashion (though it SHOULD be!). (Chris Torek!! You listenin'? You might want to get out your zillion-line explanation of arrays and pointers. I feel it may soon be needed.) -- "The word 'language' is a misnomer -- languages are things like Dutch and English. They are for telling jokes in and making love in." --- Edsgar Dijkstra -- "Mrs. Peel.... we're needed!" -- Wayne Throop <the-known-world>!mcnc!rti-sel!dg_rtp!throopw
amir@cnt.UUCP (amir vafaei) (09/06/87)
I have sent a few articles asking for some info, but never received a reply!! So I am wandering whether these are going out or not, since we just installed the software!!! So I will be sending this message out every day, till I find out. So would some kind soul, please respond to this message. Thanks.
afoster@ogcvax.UUCP (Allan Foster) (09/10/87)
AAAARRRRRGGGGGGGG! No don't send it out any more we promis to respond. It got to me here in Oregon. Regards
eal@tut.UUCP (Lehtim{ki Erkki) (09/18/87)
In article <119@cnt.UUCP> amir@cnt.UUCP (amir vafaei) writes: > > >I have sent a few articles asking for some info, but never received a >reply!! So I am wandering whether these are going out or not, since >we just installed the software!!! > >So I will be sending this message out every day, till I find out. > >So would some kind soul, please respond to this message. > >Thanks. I tried to reply to Amir Vafaei, but following is what happened. Sorry. Date: Wed, 9 Sep 87 17:45:47 GMT Message-Id: <8709180907.AA00104@tutor.tut.fi> From: MAILER-DAEMON (Mail Delivery Subsystem) Subject: Returned mail: Service unavailable To: eal ----- Transcript of session follows ----- >>> RCPT To:<amir@cnt> <<< 554 <amir@cnt>... Host cnt not known 554 amir@cnt.UUCP... Service unavailable ----- Unsent message follows ----- (Rest is deleted) -- Erkki A. Lehtim{ki eal@tut.uucp
vjk@tut.fi (Vesa Kein{nen) (09/21/87)
in article <420@tutor.tut.UUCP>, eal@tut.UUCP (Lehtim{ki Erkki) says: > > I tried to reply to Amir Vafaei, but following is what happened. Sorry. > > [ Mailer error message deleted ] > > Erkki A. Lehtim{ki eal@tut.uucp At that time tut (Finnish backbone) didn't know about host called cnt, so mail was rejected. Cnt is mentioned in latest uucp site list (received 21.9). Sending mail to Amir should work now. Vesa -- Vesa Keinanen # Tampere University of Technology vjk@tut.fi # /Computer Systems Laboratory (vjk@tut.UUCP mcvax!tut!vjk) # PO box 527, SF-33101 Tampere, Finland postmaster@tut.fi # tel: 358 31 162590
CKUB12%DDOHRZ11.BITNET@wiscvm.wisc.EDU (10/28/87)
Date: 27 October 1987, 14:11:13 SET From: the UNIX-GURU n. c. CKUB12 at DDOHRZ11 To: INFO-C at BRL help
Q02Z9002%TWNMOE10.BITNET@wiscvm.wisc.EDU (Mu Hwa Harn) (11/16/87)
HELP
A50D%DKAUNI11.BITNET@CUNYVM.CUNY.EDU (01/11/88)
Date: 11 January 1988, 16:18:13 MEZ From: A50D at DKAUNI11 To: INFO-C at BRL
JT7B0002%TWNMOE10.BITNET@CUNYVM.CUNY.EDU (CHOU YI PING) (02/08/88)
Dear Sir:
I am a new user of bitnet.I need some help about your group.
Please send me some useful information and command about your discussion group.
How can I subscribe your discussion group ?Thank you very much.
SINCERLY
Chou Yi PingHAVERKOR%HENTHT5.BITNET@CUNYVM.CUNY.EDU (02/08/88)
help
decot@hpisod2.HP.COM (Dave Decot) (02/09/88)
HAVERKOR%HENTHT5.BITNET@CUNYVM.CUNY.EDU writes: > help Your problem is that your address is too long. You're welcome.
mitchemt@silver.bacs.indiana.edu (09/23/88)
struct string
{
char content;
struct string *next;
};
typedef struct string STRING;
main()
{
STRING *stringptr;
STRING *newstrptr;
newstrptr = newstrel(newstrptr);
(*newstrptr).content = 'a';
}
STRING newstrel(sptr)
STRING *sptr;
{
sptr = ( STRING * ) malloc (sizeof(STRING));
return sptr;
}
fuller@kadsma.kadsm (Bill Fuller) (09/24/88)
You have not declare your function call in main to be returning a pointer to a STRING type. Bill
dnewton@carroll1.UUCP (Dave 'Yes, I'm weird' Newton) (10/10/89)
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.
--
David L. Newton | dnewton@carroll1.UUCP | Quote courtesy of
(414) 524-7343 (work) | dnewton@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@bucsf.bu.edu (Austin Ziegler) (10/10/89)
On 9 Oct 89 23:26:06 GMT,
dnewton@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
-*-
/|\ austin@bucsf.bu.edurang@cs.wisc.edu (Anton Rang) (10/10/89)
In article <39902@bu-cs.BU.EDU> austin@bucsf.bu.edu (Austin Ziegler) writes: >dnewton@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 [ ... ] 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. 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) | rang@cs.wisc.edu | | University of Wisconsin--Madison | | +----------------------------------+------------------+
d-yang@cs.columbia.edu (David Yang) (10/10/89)
> dnewton@carroll1.UUCP (Dave 'Yes, I'm weird' Newton) said: > > 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> ========================== > char h[] doesn't reserve any memory for the array. 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-yang@cs.columbia.edu the
ok@cs.mu.oz.au (Richard O'Keefe) (10/10/89)
In article <39902@bu-cs.BU.EDU>, austin@bucsf.bu.edu (Austin Ziegler) writes: > Dave> ========================== > Dave> #include <stdio.h> > Dave> main () > Dave> { > Dave> char h[]; > Dave> scanf ("%s", h); > Dave> printf ("%s\n", h); > Dave> } > Dave> ========================== > I don't know, but I just tried it. 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.
gwyn@smoke.BRL.MIL (Doug Gwyn) (10/10/89)
In article <RANG.89Oct9215608@derby.cs.wisc.edu> rang@cs.wisc.edu (Anton Rang) writes: -In article <39902@bu-cs.BU.EDU> austin@bucsf.bu.edu (Austin Ziegler) writes: ->dnewton@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.
jeenglis@girtab.usc.edu (Joe English) (10/10/89)
rang@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. 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 jeenglis@nunki.usc.edu
cpcahil@virtech.UUCP (Conor P. Cahill) (10/10/89)
In article <731@carroll1.UUCP>, dnewton@carroll1.UUCP (Dave 'Yes, I'm weird' Newton) writes: > 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 | +-----------------------------------------------------------------------+
cpcahil@virtech.UUCP (Conor P. Cahill) (10/10/89)
In article <39902@bu-cs.BU.EDU>, austin@bucsf.bu.edu (Austin 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. You can't scanf(.) into a char *h without first assigning the *h to point to a real storage area. -- +-----------------------------------------------------------------------+ | Conor P. Cahill uunet!virtech!cpcahil 703-430-9247 ! | Virtual Technologies Inc., P. O. Box 876, Sterling, VA 22170 | +-----------------------------------------------------------------------+
npl@cbnewsi.ATT.COM (nickolas.landsberg) (10/10/89)
In article <39902@bu-cs.BU.EDU>, austin@bucsf.bu.edu (Austin Ziegler) writes: > dnewton@carroll1.UUCP (Dave 'Yes, I'm weird' Newton) said: > Dave> Why doesn't this work? > Dave> #include <stdio.h> > Dave> main () > Dave> { > Dave> char h[]; > Dave> scanf ("%s", h); > Dave> printf ("%s\n", h); > 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. 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
dfp@cbnewsl.ATT.COM (david.f.prosser) (10/10/89)
In article <731@carroll1.UUCP> dnewton@carroll1.cc.edu (Dave 'Yes, I'm weird' Newton) writes: >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...
lint@mimsy.umd.edu (The Lint Program) (10/11/89)
In article <731@carroll1.UUCP> dnewton@carroll1.UUCP (Dave 'Yes, I'm weird' Newton) writes: >#include <stdio.h> >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@bucsf.bu.edu (Austin Ziegler) (10/11/89)
On 10 Oct 89 11:54:32 GMT, cpcahil@virtech.UUCP (Conor P. Cahill) said: Conor> In article <39902@bu-cs.BU.EDU>, austin@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 -*- /|\ austin@bucsf.bu.edu (the REAL address)
chris@mimsy.UUCP (Chris Torek) (10/11/89)
>>>main () >>>{ >>> 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.89Oct9215608@derby.cs.wisc.edu> rang@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: chris@cs.umd.edu Path: uunet!mimsy!chris
cpcahil@virtech.UUCP (Conor P. Cahill) (10/11/89)
In article <39953@bu-cs.BU.EDU>, austin@bucsf.bu.edu (Austin Ziegler) writes: > 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?). -- +-----------------------------------------------------------------------+ | Conor P. Cahill uunet!virtech!cpcahil 703-430-9247 ! | Virtual Technologies Inc., P. O. Box 876, Sterling, VA 22170 | +-----------------------------------------------------------------------+
henry@utzoo.uucp (Henry Spencer) (10/11/89)
In article <1256@virtech.UUCP> cpcahil@virtech.UUCP (Conor P. Cahill) writes: >...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 henry@zoo.toronto.edu
jas@postgres.uucp (James Shankland) (10/11/89)
In article <39953@bu-cs.BU.EDU> austin@bucsf.bu.edu (Austin Ziegler) writes: > 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. 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
diamond@csl.sony.co.jp (Norman Diamond) (10/11/89)
In article <RANG.89Oct9215608@derby.cs.wisc.edu> rang@cs.wisc.edu (Anton Rang) writes: >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.sony.junet@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.
childers@avsd.UUCP (Richard Childers) (10/12/89)
dnewton@carroll1.cc.edu (Dave 'Yes, I'm weird' Newton) writes: >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 | dnewton@carroll1.UUCP | Quote courtesy of >(414) 524-7343 (work) | dnewton@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 *
childers@avsd.UUCP (Richard Childers) (10/12/89)
gwyn@brl.arpa (Doug Gwyn) writes: >rang@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. -- 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 *
jeenglis@nunki.usc.edu (Joe English) (10/12/89)
This article is not about C, it's about comp.lang.c. Hit N now if you're not interested: childers@avsd.UUCP (Richard Childers) writes: >gwyn@brl.arpa (Doug Gwyn) writes: >>rang@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 jeenglis@nunki.usc.edu
gwyn@smoke.BRL.MIL (Doug Gwyn) (10/12/89)
In article <2143@avsd.UUCP> childers@avsd.UUCP (Richard Childers) writes: >gwyn@brl.arpa (Doug Gwyn) writes: >>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, ... 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.
dts@quad.uucp (David T. Sandberg) (10/12/89)
In article <2142@avsd.UUCP> childers@avsd.UUCP (Richard Childers) writes: >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. 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: dts@quad.uucp ACTUAL: ..uunet!rosevax!sialis!quad!dts
flaps@dgp.toronto.edu (Alan J Rosenthal) (10/13/89)
In article <2143@avsd.UUCP> childers@avsd.UUCP (Richard Childers) conjectures: >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@rsp.is (Orn E. Hansen) (10/13/89)
In article <39902@bu-cs.BU.EDU>, austin@bucsf.bu.edu (Austin Ziegler) writes: > On 9 Oct 89 23:26:06 GMT, > dnewton@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: orn@rsp.is Computer Department.
orn@rsp.is (Orn E. Hansen) (10/14/89)
In article <18227@pasteur.Berkeley.EDU>, jas@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? > > 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@mimsy.UUCP (Chris Torek) (10/15/89)
In article <142@.rsp.is> orn@rsp.is (Orn E. Hansen) writes: >The code 'char h[]' equals 'char *h'. No. Please do not make this claim; it is false. We just went through this (probably my other followups have not reached Iceland yet). -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@cs.umd.edu Path: uunet!mimsy!chris
bill@twwells.com (T. William Wells) (10/16/89)
In article <143@.rsp.is> orn@rsp.is (Orn E. Hansen) writes: : In article <18227@pasteur.Berkeley.EDU>, jas@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 bill@twwells.com
chris@mimsy.UUCP (Chris Torek) (10/16/89)
>In article <18227@pasteur.Berkeley.EDU> jas@postgres.uucp (James Shankland) >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> orn@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. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@cs.umd.edu Path: uunet!mimsy!chris
bagpiper@pnet02.gryphon.com (Michael Hunter) (10/16/89)
bill@twwells.com (T. William Wells) writes: >In article <143@.rsp.is> orn@rsp.is (Orn E. Hansen) writes: >: In article <18227@pasteur.Berkeley.EDU>, jas@postgres.uucp (James Shankland) writes: >: > Why don't you try slaughtering a goat over your terminal, and letting the >: > 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. I just don't understand this harshness. Ya' know, I think life is pretty cool most of the time...but stress is definitely not my favorite part of life. Why do we have to use phrases like "Ignorant fool" and harsh rebuttals when replying to someones most likely harmless opinion. And you know, the original person might be close to correct. Think about the situation when you are dealing with a deadline and a small amount of information (say creeping requirements comming down from design folks and a true DEADline). You can tell me that you carefully track down those bugs in that new package that some other company wrote that you only have object and poor doc to, but for some reason I think that you are going to use you well honed intuition and take some guesstimations at the troubles. Don't tell me that this is well planned. The other thought that comes to mind is that if everything was well planned and thought out automatic theorem provers would be an order of magnitude easier to engineer. :) >: >: 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. IMHO true and false. The thinking and directed activity that might be applied in most lab work is VERY important. On the other hand, sometime intuition is very important. I will admit to being very jealous of those people in my math classes in school that always seemed to not only be able to solve all the problems but ALSO choose the most efficient way of getting to the solution. One of the books that I read on problem solving at the time was "How to solve it" by G. Ploya. From this and common sense (oh no, not that!) I realized that there was not way of teaching or forcing myself to pick those nice ways of solving problems. I just had to keep striving on improving my abilities to solve problems, and tune my problem solving filter as good as I could. With you comments on science being well thought out and well planned I'm not sure what I could do? Do I just give up because I did not learn an algorithm for problem solving? > >Followups have been directed to alt.flame. hmmmm...my news reader is broken, but it is getting pretty esoteric. > >--- >Bill { uunet | novavax | ankh | sunvice } !twwells!bill >bill@twwells.com I've seen you give some pretty good answers to some things...but this was a bit arrogant. Mike Hunter - Box's and CPU's from HELL: iapx80[012]86, PR1ME 50 Series, 1750a UUCP: {ames!elroy, <routing site>}!gryphon!pnet02!bagpiper INET: bagpiper@pnet02.gryphon.com
gwyn@smoke.BRL.MIL (Doug Gwyn) (10/16/89)
In article <143@.rsp.is> orn@rsp.is (Orn E. Hansen) writes: >Randomly trying things gives you a multiple perspective to observe a single >point. Sometimes called SCIENCE, .. 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@philmtl.philips.ca (Ray Dunn) (10/17/89)
In article <143@.rsp.is> orn@rsp.is (Orn E. Hansen) writes: >> 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. 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: ray@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
jharkins@sagpd1.UUCP (Jim Harkins) (10/17/89)
In article <11296@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes: >No, we generally consider somebody who randomly tries things as a very >poor scientist. At my old company we called such people 'managers'. jim
jxy7070@ultb.isc.rit.edu (J.X. Yih) (04/29/90)
Dear netters: I have used MSC 5.0 for more than 1.8 years. But I never got such a problem... I bought a new computer 5.7 months ago. Everytime I want to debug my program by using CV, it just pulls down the "search" window immediately and stops forever. (I mean I must RESET my computer by Ctrl-Alt-Del) Can any expert there help me? And the configuration of my computer is as follows: 80286 AT 2 par ports (with a printer) 2 ser ports (with a 2400 modem on COM 1) (without mouse) 1.2 MB disk driver X 1 1.44 MB disk driver X 1 20 MB hard disk X 1 12/8 MHz MSC 5.0 Any help will be greatly appreciated. June-Shyan Yih jxy7070@ultb.isc.rit.edu
elidriss@goofi.greco-prog.fr (Elhoussine ELIDRISSI) (05/11/91)
Hello Everybody, Is there any available programs on FTP that makes data analysis in Turbo C (or any other language). For any help, suggestion or information, please e-mail to me at elidriss@prof.greco-prog.fr , since our news server seems not to work these days. Please excuse me for my bad english, and tkanks in advance. Elhoussine ELIDRISSI elidriss@prof.greco-prog.fr
NYK100@psuvm.psu.edu (06/15/91)
Hi I have a problem in compiling some programs using project. The error message is following. linker error:segment overflowed maximum size:_BSS following is another problem I got when I compile another set of programs. error message is following.. BGI error:graphics not initialized (use 'initgraph') If any of you know the solution, then let me know. Thanks . nyk100@psuvm.psu.edu
wolfram@cip-s08.informatik.rwth-aachen.de (Wolfram Roesler) (06/19/91)
NYK100@psuvm.psu.edu writes: >linker error:segment overflowed maximum size:_BSS check the compiler and linker options to increase the size of the BSS segment. But probably you have something like `static long[999999]' in your program. This array would be put in the BSS segment, thus making it 999999* sizeof(long) bytes longer. Try dynamic allocation. >BGI error:graphics not initialized (use 'initgraph') Do what it says, call the initgraph function. See the BGI docu for details. CU \/\/olfram