Re: Inconsistent Program Results

Francine.Neary@xxxxxxxxxxxxxx wrote:
I am learning C, having fun with strings & pointers at the moment!

The following program is my solution to an exercise to take an input,
strip the first word, and output the rest. It works fine when you give
it 2 or more words, but when there's only 1 word the results vary
depending on whether it's on Windows or Linux: under MSVC it displays
no output (as it should); under gcc/Linux it instead gives
"Segmentation fault".

#include <malloc.h>

This is not a standard header. You probably should be include
<stdlib.h> instead.

#include <stdio.h>
#include <memory.h>

Another non-standard header, I have no idea what you would
need that for. Avoid non-standard headers unless you know
why you use them, i.e. if you do something system-specific
- but there's nothing system-specific in your program that
would require this.

#define LEN 1000

void rdinpt();

Why do you lie to the compiler? The function of the same name
you define later takes an argument, a pointer to pointer to
char.

void main()

Under both Windows and Linux main() always returns an int (and
your main function aactually returns an int). And to make it
clear that it doesn't take any arguments better write it as

int main( void ):

{
char *s, *restrict;
rdinpt(&s);
restrict=strchr(s,' ');

If there's no space in the string you got then strchr() returns
NULL.

printf("%s\n", ++restrict);

That forces printf() in the case that there was no space in the
string you got to dereference NULL+1 - whatever that may point
to it's rather likely that this isn't any memory you own. And
in that case you have undefined behaviour and everything can
happen. Printing nothing or segfaulting are only two of many
possibilities.

So you need to check the return value of strchr() and only
try to print out something if that wasn't NULL.

free(s), s=restrict=0;

Why use the comma operator instead of a semicolon here? And
since both 's' and 'restrict' are pointers you better make
that clear by assigning NULL instead. The next person having
to read your code will thank you.

return (0);
}

void rdinpt(char **s)
{
*s=(char *) malloc( (unsigned int) LEN);

Why the cast to 'char*'? I suspect you put it there to keep
the compiler from complaining about an assignment from an
int to a pointer. But casting is not the solution in that
case, it only makes things worse. You need to include
<stdlib.h> to make the compiler aware that malloc() returns
a void pointer and not an int, as it will assume if it does
not know about the return type of malloc(). And, by the way,
the argument to malloc() is of type 'size_t', not unsigned
int. But casting here is also superfluous. If the compiler
knows what kind of argument malloc() expects it will do the
conversion all by itself if necessary (another argument for
including <stdlib.h>).

And if you use malloc() never forget to check its return value.
It can fail, returning NULL, and then you not only have no
memory but if you use this return value your program may crash
or do even worse things.

(void) gets(*s);

And now you used _the_ function you never ever should use.
It is broken by design since if the user enters more than
LEN-1 characters the function will write past the end of
the memory you allocated. So, never ever even think of
using it. Use fgets() instead - there you can tell how
many chars you are prepared to read in.

return(0);

Strange, above you told that the function doesn't return
anyting... And, by the way, you don't need parentheses
around the return value, 'return' isn't a function.

}

If you don't already have ask the compiler to output lots
of warnings (e.g. using at least the options '-W -Wall' if
you use gcc). Try to understand what makes the compiler
complain and correct your program so that it compiles
cleanly. This will teach you a lot about the mistakes you
are making.
Regards, Jens
--
\ Jens Thoms Toerring ___ jt@xxxxxxxxxxx
\__________________________ http://toerring.de
.

Relevant Pages

  • Re: about the array
    ... 3- If you cast to the wrong type by accident, ... are malloc and free. ... the compiler should issue a diagnostic - gcc ... unknown set of arguments, and return an int. ...
    (comp.lang.c)
  • Re: why still use C?
    ... >>type of the object pointed to by a pointer differs from the type that I, ... >>the programmer, know to be the real type pointed at. ... When you're using implementation defined behaviour, the compiler ... I would argue that the malloc() is just such a case. ...
    (comp.lang.c)
  • Re: How does C cope if architecture doesnt address bytes?
    ... >>which the malloc() call occurs, figure out the type of the pointer which ... alignment in the implementation, rather than in either part of it. ... compiler and library are so strictly separate that there is no ... # The pointer returned if the allocation succeeds is suitably aligned so ...
    (comp.lang.c)
  • Re: Help. What is the error?
    ... int main ... check if malloc has succeeded before using it. ... If param put in the cast to shut the compiler up then it just goes to show *why* you should never put in a cast to shut the compiler up, you only put in casts when you understand *why* the compiler complained and exactly what the effect will be. ... So malloc returns a 64 bit pointer, but when main was compiled the compiler assumed it would be getting a 32 bit int, so it only grabs half of the address and then converts that in to a pointer which obviously produces a garbage value. ...
    (comp.lang.c)
  • Re: forwards declarations!
    ... h, long m, int w, int l); ... compiler obviously doesn't. ... LRESULT callerFunction(HWND, long, WPARAM, LPARAM), HWND ... Not quite the same as straight forwards function pointer usage. ...
    (microsoft.public.vc.language)