[Gllug] SIGSEGV error

Nix nix at esperi.org.uk
Thu Aug 30 23:00:01 UTC 2007


[This was threaded incorrectly, and its total absence of context makes it
 quite difficult to tell you're responding to me. Please fix your mailer.]

On 30 Aug 2007, t. clarke told this:
> I beg to differ about the 'gotcha'  !
> I have a C compiler on a Unix box that ordinarily places such strings in the
> 'bss' area (or whatever its called) and thus allows them to me modified later.

Things will go into the BSS if they are static *modifiable* strings, e.g.

static char foo[] = "blah";

Every Unix compiler will do this, or emit code to initialize it manually
at program startup (much rarer because less efficient).

> Its a convenient way of initialising a string which can be modified as the
> program executes.

Yes.

> If the GNU compiler chooses to always place such strings in the text area
> thats up to it  -  but if a program was written originally on a machine
> with a compiler that uses the 'looser' behavior it will implode when
> compiled on a GNU compiler !
> 
> The -frwitable-strings switch was clearly a workaround for this problem

I think you're confusing static modifiable strings with static string
constants. It is the latter which -fwritable-strings causes to be placed
into modifiable storage. -fwritable-strings was a workaround allowing a
certain class of *undefined* behaviour (modifying *string constants*) to
work, at a considerable cost in efficiency.

-fwritable-strings affected *all* string constants, even things like

my_printf ("Hello world!\n");

It did not cause anything to be emitted into BSS that was not previously
BSSed: instead it caused string constants to be placed into the data
section rather than the readonly data section (BSS is a repository for
*zero-initialized* modifiable memory, anyway, and string constants
generally aren't initialized with zeroes but with, well, the string
constant).

Declarations like the foo variable declaration above remain in BSS
regardless of options: it would be a violation of the C Standard to
place them into nonmodifiable storage, and inefficient to put them
somewhere where they'd need manual initialization (although on some
platforms, lacking any analogue of BSS, this is needed).

> - IMHO its a shame its been removed as it means possibly some older C source
> will have to be modified instead if simply compiled with the extra switch.

It was removed (in GCC 3.4, actually, wow, was it that long ago?) on the
basis that modification of string constants has been invalid since the C
Standard was ratified in 1989, so it was only really useful for
compiling pre-Standard code: and GCC 3.3 had removed the ability to
compile such code as part of the final stage of the integrated C
preprocessor work. (A good thing too, because Joseph Myers rewrote the C
parser completely in GCC 4.0 for efficiency and maintainability reasons,
and supporting the basically random pile of exceptions implied by
-traditional would have complicated it no end.)

I have seen no complaints before now, and it's notable that now I see a
mention of it it's based on a misunderstanding of what that switch
actually did...

> In any event my comments were not intended as a critique of the C compiler or
> language, merely pointing out a possible source of the problem, since it stung
> me in the past !

I think you're misunderstanding the nature of your problem :(
-- 
Gllug mailing list  -  Gllug at gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug




More information about the GLLUG mailing list