Go Premium for a chance to win a PS4. Enter to Win

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 321
  • Last Modified:

gcc bug !?

Hi,
I think that I found some kind of bug in gcc.
This simple code to cycle through devices changes the last letter (device name, hda, hdb, etc)
This code compiles and runs fine on msDev, Borland, AIX V5.
When I compiled it on my Linux machine it results in a core dump (segmentation fault) as soon as you try to change the device letter.


#include <stdio.h>


int main()
{
    char* sDev = "/dev/hd_\n", /* the '_' is char # 8 */
        *p = NULL;

    p = &sDev[8];

    printf("%s\n", sDev);

    *p = ((char)0x61); /* ERROR on Linux */

    printf("%s\n", sDev);

    return 0;
}

?
0
bod_1
Asked:
bod_1
  • 6
  • 5
1 Solution
 
ozoCommented:
modification of a string literal is undefined behavior
writable string literals is a common extension
0
 
bod_1Author Commented:
I was taught that in C you'r supposed to be able to alter strings and arrays through an item's index or a pointer to that index.
0
 
ozoCommented:
then you weren't taught in strict compliance to ANSI Standard X3.159-1989
try
static char sDev[] = "/dev/hd_\n";
0
Industry Leaders: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

 
bod_1Author Commented:
ahh,
I've been using msDev and Borland soo often that using strict compiling really messed me up.  I still need to get used to it.
That answers my question.
Thanks Ozo.
0
 
bod_1Author Commented:
Yes,
That was the problem, I tried the same thing declaring an array instead and there were no problems.
0
 
bod_1Author Commented:
Ozo,
Do you want these points?
You straightened out my question for me
0
 
ozoCommented:
although it is a common extension to allow writeable string literals, and to guarantee that identical string literalls be distinct,
the ANSI C standard actually specifies them to be unmodifiable,
and if a program attemps to modify a literal rhe behavior is undefined.
a strictly conforming program should instead use:

     static char sDev[] = "/dev/hd_\n";

0
 
bod_1Author Commented:
When you told me that I lost some respect for C.  That rule puts some serious restrictions on what can be done regarding strings.
Altering unknown length strings is sometimes a necessity.

eg.  For a recent assignment at school I implemented a function with the ...'s.  If I had it my way, I would have malloc'd a string to hold the arguments, and realloc'd the string as needed if there were more args.  Because of that rule, I just set a limit on the number of args that could be passed.  I would have preferred the limits being set by the amount of memory available.
If I sound ignorant (ie. undoubtably there are some good reasons behind that rule) please excuse me;  I am still very new to this.

Anyways, thanks for the help Ozo.
0
 
ozoCommented:
malloc and realloc are in the C standard, so it sounds like your way should work.

The ANSI C Rationale (which is not actually part of the X3.159-1989 standard itself) says about section 3.1.4:
String literals are specified to be unmodifiable.  This specification allows implementations to share copies of strings with identical text, to place string literals in read-only memory, and perform certain optimizations.
...
Those members of the Committee who insisted that string literals should be modifiable were content to have this practice designated a common extension (see F.5.5).
Existing code which modifies string literals can be made strictly conforming by replacing the string literal with an initialized static character array.
...
0
 
bod_1Author Commented:
Ah,  I never tried modifying the string after using malloc...assumed that the rule applied to all char*'s.
That's not so bad then.
Thanks again Ozo
0
 
ozoCommented:
A string literal is a character sequence enclosed in double-quotes
(const char *) may be unmodifiable
0

Featured Post

Prepare for your VMware VCP6-DCV exam.

Josh Coen and Jason Langer have prepared the latest edition of VCP study guide. Both authors have been working in the IT field for more than a decade, and both hold VMware certifications. This 163-page guide covers all 10 of the exam blueprint sections.

  • 6
  • 5
Tackle projects and never again get stuck behind a technical roadblock.
Join Now