Regards:
Where the code trouble is?
#include <windows.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
int main(){
char *name;
char *title;
printf( "Enter your name:");
scanf( "%s", name );
title = strcat(name,"the Great");
printf( "Hello, %s\n", title );
return(0);
}
--------------------------------------------
thank you
may goodness be with you all 16 1581
mikelinyoho wrote: Regards:
Where the code trouble is?
#include <windows.h> #include <stdio.h> #include <stdlib.h> #include <string.h>
int main(){
char *name; char *title; printf( "Enter your name:"); scanf( "%s", name );
Name is a pointer with no memory associated.Scanf dont allocate
memory.
Change char * name to an array.Use fgets instead of scanf to avoid
overflow issues. title = strcat(name,"the Great"); printf( "Hello, %s\n", title ); return(0); }
--------------------------------------------
thank you may goodness be with you all
Do you get compiler errors or what?
Can you be more specific?
Alex.
mikelinyoho wrote: Regards:
Where the code trouble is?
#include <windows.h>
non standard header
#include <stdio.h> #include <stdlib.h>
Do you really need this?
#include <string.h>
#define MAXMUNCH ... /* some size big enough for you */
int main(){
int main(void){
is a tad bit better. char *name; char *title; printf( "Enter your name:"); scanf( "%s", name );
Not allocated enough (any) memory -- so you're
dead hereon.
Do name = malloc( sizeof *name * MAXMUNCH ); title = strcat(name,"the Great");
... and to add insult to injury.
printf( "Hello, %s\n", title ); return(0); }
mikelinyoho wrote: Regards:
Where the code trouble is?
The same as in the last 4000 posts with pointers-to-nowhere from
clueless people who refuse to check the FAQ or follow the newsgroup
before posting.
mikelinyoho wrote: Where the code trouble is?
#include <windows.h>
No such standard header, eliminate it.
#include <stdio.h> #include <stdlib.h> #include <string.h>
int main(){
char *name; char *title; printf( "Enter your name:"); scanf( "%s", name ); title = strcat(name,"the Great"); printf( "Hello, %s\n", title ); return(0); }
Don't use scanf for interactive input. Do fflush of the prompt.
Do read the action of strcat. Do assign memory space to fill. eg:
#include <stdio.h>
#include <string.h>
#define BUFSIZE 80
#define CAPTION " the Great"
int main(void) {
char name[BUFSIZE + 1 + strlen(CAPTION)];
char *p;
printf("Enter your name:);
fflush(stdout);
fgets(name, BUFSIZE, stdin);
if (p = strchr(name, '\n') *p = '\0';
strcat(name, CAPTION");
printf("Hello, %s\n", name);
return(0);
} /* not tested */
Note the test for a final \n in the input and stripping of it.
--
"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
"mikelinyoho" <mi*********@gmail.com> wrote in message
news:11*********************@z14g2000cwz.googlegro ups.com... Regards:
Where the code trouble is?
.... char *name; char *title; printf( "Enter your name:"); scanf( "%s", name );
The compiler might give a warning that 'name' is not initialised.
I would have expected scanf() to give an error when 'name' was (as I
assumed) null.
It fact on my test compiler 'name' has some arbitrary value (the program
worked), and not zero.
So ideally, there should be (1) a warning (2) 'name' is best set to null
when not initialised, to avoid undefined action, and (3) scanf() should at
very least not assign to a null pointer!
title = strcat(name,"the Great");
A space might help
Bartthe Great
CBFalconer wrote: #define BUFSIZE 80 #define CAPTION " the Great"
int main(void) { char name[BUFSIZE + 1 + strlen(CAPTION)];
Excuse my ignorance, but does it really work? Well, I tried it with gcc and
I see that it really works, but since when?
--
Anton Petrusevich
Anton Petrusevich <ca***@att-ltd.biz> writes: CBFalconer wrote:
#define BUFSIZE 80 #define CAPTION " the Great"
int main(void) { char name[BUFSIZE + 1 + strlen(CAPTION)];
Excuse my ignorance, but does it really work? Well, I tried it with gcc and I see that it really works, but since when?
Variable length arrays (VLAs) are a new feature in C99, not supported
in C90. gcc has supported them (or something very similar) as an
extension for some time. It won't work with a strict C90 compiler.
<OT>
I'm a little surprised to see that gcc doesn't complain about it, even
with "-ansi -pedantic -Wall -W".
</OT>
--
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.
Anton Petrusevich wrote: CBFalconer wrote:
#define BUFSIZE 80 #define CAPTION " the Great"
int main(void) { char name[BUFSIZE + 1 + strlen(CAPTION)];
Excuse my ignorance, but does it really work? Well, I tried it with gcc and I see that it really works, but since when?
That should really have been sizeof(CAPTION) to be portable to
C90. Then it doesn't need the +1 either.
--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
"Bart C" <bc@freeuk.com> wrote: "mikelinyoho" <mi*********@gmail.com> wrote in message news:11*********************@z14g2000cwz.googlegro ups.com... char *name; char *title; printf( "Enter your name:"); scanf( "%s", name ); The compiler might give a warning that 'name' is not initialised.
Not necessarily.
I would have expected scanf() to give an error when 'name' was (as I assumed) null.
It fact on my test compiler 'name' has some arbitrary value (the program worked),
No, it didn't. It merely appeared to.
So ideally, there should be (1) a warning (2) 'name' is best set to null when not initialised, to avoid undefined action, and
Writing through a null pointer is no more defined than writing through a
wild pointer. title = strcat(name,"the Great");
A space might help
A space would not make the code any more correct. The real problem on
this line is similar to the one above.
Richard
"Richard Bos" <rl*@hoekstra-uitgeverij.nl> wrote in message
news:43****************@news.xs4all.nl...
.... So ideally, there should be (1) a warning (2) 'name' is best set to null when not initialised, to avoid undefined action, and
Writing through a null pointer is no more defined than writing through a wild pointer.
Maybe, but an error is more or less guaranteed with a null pointer and makes
it easy to check for. An arbitrary wild pointer is difficult to check for
and leads to code that works on test then fails unexpectedly.
Bart.
In article <43******@212.67.96.135>, Bart C <bc@freeuk.com> wrote: "Richard Bos" <rl*@hoekstra-uitgeverij.nl> wrote in message news:43****************@news.xs4all.nl...
Writing through a null pointer is no more defined than writing through a wild pointer.
Maybe, but an error is more or less guaranteed with a null pointer and makes it easy to check for.
I know of at least two architectures in which NULL is all-zero-bits
but in which writing at (or near that location, such as a[3] when
a is NULL) would NOT result in a trap, because the architectures happen
to have memory at that location.
--
"[...] it's all part of one's right to be publicly stupid." -- Dave Smey
Walter Roberson wrote: In article <43******@212.67.96.135>, Bart C <bc@freeuk.com> wrote:
"Richard Bos" <rl*@hoekstra-uitgeverij.nl> wrote in message news:43****************@news.xs4all.nl...
Writing through a null pointer is no more defined than writing through a wild pointer.
Maybe, but an error is more or less guaranteed with a null pointer and makes it easy to check for.
I know of at least two architectures in which NULL is all-zero-bits but in which writing at (or near that location, such as a[3] when a is NULL) would NOT result in a trap, because the architectures happen to have memory at that location.
The vast majority of machines in use have NULL as a trap location. Richard's
development system likely does so as well. Although *NULL might well not
trap, it's in general more likely to, which can help with debugging.
This will not catch all such errors of course, but it doesn't hurt anything,
except for causing a tiny (probably imperceptible) performance hit, and may
help with debugging.
--
λz.λi.i(i((λn.λm.λz.λi.nz(λq.mqi))((λn.λz .λi.n(nzi)i)(λz.λi.i(((λn.λz.λi.n
(nzi)i)(λz.λi.i(iz)))zi)))((λn.λz.λi.n(nzi)i) (λz.λi.i(iz)))zi))
Bryan Donlan wrote: Walter Roberson wrote:
In article <43******@212.67.96.135>, Bart C <bc@freeuk.com> wrote:
"Richard Bos" <rl*@hoekstra-uitgeverij.nl> wrote in message news:43****************@news.xs4all.nl...
Writing through a null pointer is no more defined than writing through a wild pointer.
Maybe, but an error is more or less guaranteed with a null pointer and makes it easy to check for.
I know of at least two architectures in which NULL is all-zero-bits but in which writing at (or near that location, such as a[3] when a is NULL) would NOT result in a trap, because the architectures happen to have memory at that location.
The vast majority of machines in use have NULL as a trap location. Richard's development system likely does so as well. Although *NULL might well not trap, it's in general more likely to, which can help with debugging.
This will not catch all such errors of course, but it doesn't hurt anything, except for causing a tiny (probably imperceptible) performance hit, and may help with debugging.
Agreed.
I would also say that even on systems where writing to *NULL does not
trap, it is still likely (but not guaranteed) to give reproduceable
results which can be debugged.
For similar reasons on embedded systems I have changed the startup code
so that all RAM was initialised to all bits 0. I did not check on the
system whether NULL was all bits 0 or whether float or double 0 where
all bits 0, but it did meen the software was more predictable and easier
to debug when accessing uninitialised data. On another system they
initialised all RAM to 0x55 for the similar reason (I used all bits 0
because static variables without an initialiser where *not* set to 0).
IMHO the first stage in trying to debug a problem is always to reproduce
it, since if you can't reliably reproduce it you will never know if you
have fixed what caused the original bug report or something else that
you think might have caused it but did not.
--
Flash Gordon
Living in interesting times.
Although my email address says spam, it is real and I read it.
Bryan Donlan <bd*****@gmail.com> wrote: Walter Roberson wrote:
In article <43******@212.67.96.135>, Bart C <bc@freeuk.com> wrote:
"Richard Bos" <rl*@hoekstra-uitgeverij.nl> wrote in message news:43****************@news.xs4all.nl...
Writing through a null pointer is no more defined than writing through a wild pointer.
Maybe, but an error is more or less guaranteed with a null pointer and makes it easy to check for.
I know of at least two architectures in which NULL is all-zero-bits but in which writing at (or near that location, such as a[3] when a is NULL) would NOT result in a trap, because the architectures happen to have memory at that location.
The vast majority of machines in use have NULL as a trap location. Richard's development system likely does so as well. Although *NULL might well not trap, it's in general more likely to, which can help with debugging.
This will not catch all such errors of course, but it doesn't hurt anything, except for causing a tiny (probably imperceptible) performance hit, and may help with debugging.
On the contrary, it _will_ hurt. The programmer will start relying on
the assumption that he has either a null pointer, or a valid one. This
assumption is going to turn around and bite him sooner or later, and
then you try and find where it broke down.
Richard
Flash Gordon wrote: Bryan Donlan wrote:
Walter Roberson wrote:
In article <43******@212.67.96.135>, Bart C <bc@freeuk.com> wrote:
"Richard Bos" <rl*@hoekstra-uitgeverij.nl> wrote in message news:43****************@news.xs4all.nl...
> Writing through a null pointer is no more defined than writing > through a > wild pointer.
Maybe, but an error is more or less guaranteed with a null pointer and makes it easy to check for.
I know of at least two architectures in which NULL is all-zero-bits but in which writing at (or near that location, such as a[3] when a is NULL) would NOT result in a trap, because the architectures happen to have memory at that location.
The vast majority of machines in use have NULL as a trap location. Richard's development system likely does so as well. Although *NULL might well not trap, it's in general more likely to, which can help with debugging.
This will not catch all such errors of course, but it doesn't hurt anything, except for causing a tiny (probably imperceptible) performance hit, and may help with debugging.
Agreed.
I would also say that even on systems where writing to *NULL does not trap, it is still likely (but not guaranteed) to give reproduceable results which can be debugged.
For similar reasons on embedded systems I have changed the startup code so that all RAM was initialised to all bits 0. I did not check on the system whether NULL was all bits 0 or whether float or double 0 where all bits 0, but it did meen the software was more predictable and easier to debug when accessing uninitialised data. On another system they initialised all RAM to 0x55 for the similar reason (I used all bits 0 because static variables without an initialiser where *not* set to 0).
IMHO the first stage in trying to debug a problem is always to reproduce it, since if you can't reliably reproduce it you will never know if you have fixed what caused the original bug report or something else that you think might have caused it but did not.
Right.
0x99 (or any with MSBit 1) is a "*_tad_*" (and only) little better..
See Eric SosMan's reply in recent thread of "How to choose between
malloc and calloc" http://groups.google.com/group/comp....706ab502cce81f
Anand
PS: Is there a better way to point to another thread (not the long
google link way? This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Rachel Weeden |
last post by:
I'm working on an ASP Web application, and am having syntax issues in
a WHERE statement I'm trying to write that uses the CInt Function on a
field.
Basically, I want to select records using...
|
by: Viviana Vc |
last post by:
How can I programatically do the equivalent of the following:
cacls "C:\Program Files\test" /T /G Everyone:f ?
Thanks,
Viv
|
by: BlackFireNova |
last post by:
I have an Access 2003 mdb which contains software records. I need to
sort on a particular type of software, and then identify and count how
many copies there are per each group of that type...
|
by: MathewLovesC |
last post by:
Can someone help me out here? I have a bunch of test statements in the
program and my test printf("Do I have trouble here after
GetNumbers()?\n"); does not display rather I get garbage. Please...
|
by: Ray Stevens |
last post by:
I am attempting to test a VeriSign account and the setup instructions stated
that the certs file needed to go into the Windows\System32 folder. I am
getting an error from the code-behind assebly...
|
by: Tark Siala |
last post by:
hi
i working with TreeView in VB6, and have good Properity Named (Key)
with the Key i can goto Any Node i know hes Key.
but in VB.NET i can find the Key :(
please tell me where i can find the...
|
by: Bayazee |
last post by:
hi
can we hide a python code ?
if i want to write a commercial software can i hide my source code from
users access ?
we can conver it to pyc but this file can decompiled ... so ...!!
do you...
|
by: markmcgookin |
last post by:
Hi Folks,
I have a VB app, and I have been working at it for a while, and I am now at the stage where I want to create a search function. Now don't be scared! It is in the .Net compact framework,...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
| |