c standard regarding char str[ ], str[50] & *str 
Author Message
 c standard regarding char str[ ], str[50] & *str

On one compiler, this code works
             char *str;

             fgets(str,100,inputfile).

On another compiler
             char *str

             sprintf(str,"%d",child) /*child is int type*/

gave a segmentation fault

             char str[] gives array size missing fault,
        only char str[50] works with that sprintf.

What I'd like to know is what does the standard say, must I now create
my own space for character strings and is the old char *str method
of doing things now obsolete ? Or is this just a compiler issue ?



Tue, 25 Oct 2005 02:30:47 GMT  
 c standard regarding char str[ ], str[50] & *str

Quote:
> On one compiler, this code works
>              char *str;

>              fgets(str,100,inputfile).

Only by accident.  As far as the language is
concerned, the above constitutes 'undefined behavior'
-- which encompasses everything from 'seems to work'
to crashing your machine, and everything in between.

Quote:

> On another compiler
>              char *str

>              sprintf(str,"%d",child) /*child is int type*/

More undefined behavior.

Quote:

> gave a segmentation fault

That's one possible manifestation of undefined behavior.

Quote:

>              char str[] gives array size missing fault,

Right, except for function parameters or 'extern'
declarations, that is a syntax error.

Quote:
>         only char str[50] works with that sprintf.

Think about why.  str[50] actually reserves storage
for 'sprintf()', 'fgets()' etc. to use.

char *str;  only reserves storage for a *single* pointer.
It doesn't 'point' anywhere unless you make it.

Quote:

> What I'd like to know is what does the standard say, must I now create
> my own space for character strings

Yes, 'now' and 'previously'.  It's always been that way.

Quote:
>and is the old char *str method
> of doing things now obsolete ?

It's not a question of obsolescence.  It's a matter
of correctness.  C has always worked this way.

Quote:
>Or is this just a compiler issue ?

No, imo you're misunderstanding how C works.
Which textbook(s) are you reading?

-Mike



Tue, 25 Oct 2005 02:50:30 GMT  
 c standard regarding char str[ ], str[50] & *str

Quote:
> On one compiler, this code works
>              char *str;
>              fgets(str,100,inputfile).
> On another compiler
>              char *str
>              sprintf(str,"%d",child) /*child is int type*/
> gave a segmentation fault

>              char str[] gives array size missing fault,
>         only char str[50] works with that sprintf.
> What I'd like to know is what does the standard say, must I now create
> my own space for character strings and is the old char *str method
> of doing things now obsolete ? Or is this just a compiler issue ?

Writing into memory pointed by an uninitialised pointer is
undefined behaviour. Therefore no matter what the implementation
does, it is always right. So you could say it is a compiler issue.
To do things right, use malloc() to allocate proper storage for
the string you are writing.

--

| Kingpriest of "The Flying Lemon Tree" G++ FR FW+ M- #108 D+ ADA N+++|
| http://www.helsinki.fi/~palaste       W++ B OP+                     |
\----------------------------------------- Finland rules! ------------/
"Keep shooting, sooner or later you're bound to hit something."
   - Misfire



Tue, 25 Oct 2005 02:48:17 GMT  
 c standard regarding char str[ ], str[50] & *str

Quote:

> On one compiler, this code works
>              char *str;

>              fgets(str,100,inputfile).

> On another compiler
>              char *str

>              sprintf(str,"%d",child) /*child is int type*/

> gave a segmentation fault

>              char str[] gives array size missing fault,
>         only char str[50] works with that sprintf.

> What I'd like to know is what does the standard say, must I now create
> my own space for character strings and is the old char *str method
> of doing things now obsolete ? Or is this just a compiler issue ?

    This is Question 7.1 in the comp.lang.c Frequently
Asked Questions (FAQ) list

        http://www.eskimo.com/~scs/C-faq/top.html

... and I'd recommend you read Section 6 also.  (Since
your use of terms like "old" and "obsolete" suggests some
prior exposure to C, I'm shocked, shocked to find that
you haven't yet discovered the existence of the FAQ.)

--



Tue, 25 Oct 2005 02:57:52 GMT  
 c standard regarding char str[ ], str[50] & *str

Quote:

> On one compiler, this code works
>              char *str;

>              fgets(str,100,inputfile).

Only by accident.  You didn't initialize `str', so it can contain
any value, which may or may not be readable and modifiable by
your program but in any case is probably not suitable for you to
store a string in.  This is known as "undefined behavior" and it
can cause anything to happen--classically, it is supposed to make
demons shoot out of your nose.

This should not really be surprising.  If you write

    #include <stdio.h>

    int main(void)
    {
        int x;
        printf("%d\n", x);
        return 0;
    }

you shouldn't expect to see any particular value printed, and in
fact this program causes undefined behavior too.  If we use a
pointer, it's the same issue:

    #include <stdio.h>

    int main(void)
    {
        char *str;
        puts(str);
        return 0;
    }

Again, `str' wasn't initialized, so it's undefined.  All three of
these programs have the same problem.

Quote:
> On another compiler
>              char *str

>              sprintf(str,"%d",child) /*child is int type*/

> gave a segmentation fault

Good.  That's a feature.  This implementation is telling you "up
front" that your program is buggy and that you should fix it.
That's more helpful than the other implementation, which just
lets it run so that you can get in more trouble later.

Quote:
>              char str[] gives array size missing fault,

Arrays can't be defined without a bound.  (The bound can be
implicit if you supply an initializer.)

Quote:
>         only char str[50] works with that sprintf.

An array has memory associated with it from the start, so that's
fine.

Quote:
> What I'd like to know is what does the standard say, must I now create
> my own space for character strings and is the old char *str method
> of doing things now obsolete ? Or is this just a compiler issue ?

You have always had to create your own space for character
strings.  If your buggy code worked on some other implementation,
it was only by coincidence.
--
"Am I missing something?"
--Dan Pop


Tue, 25 Oct 2005 03:03:43 GMT  
 c standard regarding char str[ ], str[50] & *str

Quote:

> On one compiler, this code works
>              char *str;

>              fgets(str,100,inputfile).

The standard says this is wrong. fgets will put what it reads
wherever str is pointing. And right now str is not pointing
to any memory you own. This will give you a segfault if you are
lucky, strange errors if you are unlucky. You need to allocate
some memory.

str = malloc(100 * sizeof *str)
if(str == NULL)
   ...

Or define str like this

char str[100];

Quote:

> On another compiler
>              char *str

>              sprintf(str,"%d",child) /*child is int type*/

> gave a segmentation fault

Same problem as above

Quote:

>              char str[] gives array size missing fault,

This is not legal unless it is the last member of a struct.

struct s
{
    int a;
    char s[];  /*legal*/

Quote:
};
>         only char str[50] works with that sprintf.

A good thing.

Quote:

> What I'd like to know is what does the standard say, must I now create
> my own space for character strings and is the old char *str method
> of doing things now obsolete ?

It is not obsolete since it has never been legal. You have just been
unlucky uptil now.

Quote:
> Or is this just a compiler issue ?

This is a language issue.

--
Thomas.



Tue, 25 Oct 2005 02:58:13 GMT  
 c standard regarding char str[ ], str[50] & *str

Quote:

> On one compiler, this code works
>              char *str;

>              fgets(str,100,inputfile).

> On another compiler
>              char *str

>              sprintf(str,"%d",child) /*child is int type*/

> gave a segmentation fault

>              char str[] gives array size missing fault,
>         only char str[50] works with that sprintf.

> What I'd like to know is what does the standard say, must I now create
> my own space for character strings and is the old char *str method
> of doing things now obsolete ? Or is this just a compiler issue ?

You never allocated the memory - on *ANY* compiler it's just asking for
trouble. If it does work, you just overwrote some random memory location.
Don't do that.


Tue, 25 Oct 2005 06:27:06 GMT  
 
 [ 7 post ] 

 Relevant Pages 

1. char **str vs. char *str[]

2. char *str vs. char str[]

3. _T(str) vs (CString)str?

4. Dialogs: m_myCtrl.GetWindowText(str) or GetDlgItemText(IDC_MY_CTRL, str)?

5. char *str vs. char s

6. char* and char str[2]

7. convert int to str in pure standard C

8. Basic Question - char *str V/S int *

9. str != (char *) NULL

10. register char str[LEN]

11. how to address char * str[] ?

12. char *str - Pointer usage

 

 
Powered by phpBB® Forum Software