www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - array handling Linux<->Windows

reply "Thomas Kuehne" <eisvogel users.sourceforge.net> writes:
The code below will result in a segment fault under Linux but runs on
Windows.

int main(){
    char[] str="a1";
    str[0]++;
    assert(str[0]=='b');
    return 0;
}
Sep 27 2004
next sibling parent reply Ben Hinkle <bhinkle4 juno.com> writes:
Thomas Kuehne wrote:

 The code below will result in a segment fault under Linux but runs on
 Windows.
 
 int main(){
     char[] str="a1";
     str[0]++;
     assert(str[0]=='b');
     return 0;
 }
I don't think this is a bug - it's like the C (and C++) behavior for string literals. This came up on the main thread a few days ago. It should be mentioned in the doc if it isn't already. To get a modifyable string call dup. -Ben
Sep 27 2004
next sibling parent reply Stewart Gordon <Stewart_member pathlink.com> writes:
In article <cj90ft$a4o$1 digitaldaemon.com>, Ben Hinkle says...
<snip>
 I don't think this is a bug - it's like the C (and C++) behavior 
 for string literals.  This came up on the main thread a few days 
 ago.  It should be mentioned in the doc if it isn't already.  To 
 get a modifyable string call dup.
I'd been under the impression that initialising a char[] was supposed to create a modifyable copy of the initialisation data. But whatever the intended behaviour is, it ought to be portable. Stewart.
Sep 27 2004
next sibling parent Dave <Dave_member pathlink.com> writes:
Stewart Gordon wrote:
[snip]
 But whatever the intended behaviour is, it ought to be portable.
 
 Stewart.
Hear, hear!!
Sep 27 2004
prev sibling parent Burton Radons <burton-radons shaw.ca> writes:
Stewart Gordon wrote:
 But whatever the intended behaviour is, it ought to be portable.
Next you'll want undefined expressions to have consistent undefined behaviour. :) The code doesn't work on Windows either anyway. void main () { char [] a = "foo"; char [] b = "foo"; a [0] = 'b'; printf ("%.*s %.*s\n", a, b); } This prints "boo boo". This appears to be a bug in DMD, because constant sections are definitely available and used in Windows: void main () { ubyte *foo = cast (ubyte *) &main; printf ("%p %d\n", *foo, foo); *foo = *foo; } This prints the address and data properly but Access Violates in the assignment, indicating that "main" is put in a read-only section. Walter, once you come back, can you explain why const data is not being put into constant sections on Windows? I remember discussing this but it was years ago.
Sep 27 2004
prev sibling next sibling parent reply Arcane Jill <Arcane_member pathlink.com> writes:
In article <cj90ft$a4o$1 digitaldaemon.com>, Ben Hinkle says...
I don't think this is a bug - it's like the C (and C++) behavior for string
literals. This came up on the main thread a few days ago. It should be
mentioned in the doc if it isn't already. To get a modifyable string call
dup.
Hmmm. It's a shame we can't write: to get platform-neutral behavior, isn't it? Jill
Sep 27 2004
parent reply Regan Heath <regan netwin.co.nz> writes:
On Mon, 27 Sep 2004 13:28:17 +0000 (UTC), Arcane Jill 
<Arcane_member pathlink.com> wrote:
 In article <cj90ft$a4o$1 digitaldaemon.com>, Ben Hinkle says...
 I don't think this is a bug - it's like the C (and C++) behavior for 
 string
 literals. This came up on the main thread a few days ago. It should be
 mentioned in the doc if it isn't already. To get a modifyable string 
 call
 dup.
Hmmm. It's a shame we can't write: to get platform-neutral behavior, isn't it?
We can write that.. however the 'const' applies to the array reference, not the data it refers to, AFAIK there is no way to apply const to the data it refers to. Regan. -- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Sep 27 2004
parent reply Sean Kelly <sean f4.ca> writes:
In article <opsez7nkdr5a2sq9 digitalmars.com>, Regan Heath says...
 Hmmm. It's a shame we can't write:



 to get platform-neutral behavior, isn't it?
We can write that.. however the 'const' applies to the array reference, not the data it refers to, AFAIK there is no way to apply const to the data it refers to.
Yup. The C++ syntax would be something like: char const[] const str;
Sep 28 2004
parent reply "Ben Hinkle" <bhinkle mathworks.com> writes:
"Sean Kelly" <sean f4.ca> wrote in message
news:cjc6oe$2mci$1 digitaldaemon.com...
 In article <opsez7nkdr5a2sq9 digitalmars.com>, Regan Heath says...
 Hmmm. It's a shame we can't write:



 to get platform-neutral behavior, isn't it?
We can write that.. however the 'const' applies to the array reference, not the data it refers to, AFAIK there is no way to apply const to the data it refers to.
Yup. The C++ syntax would be something like: char const[] const str;
I think you mean "char const* const str" or "const char* const str" In C++ omitting the length of the array (eg char[] str) just means to implicitly determine the length from the initializer (I thought). So char str[] = "foobar"; is the same as char str[7] = "foobar"; which is very different than char* str = "foobar"; -Ben
Sep 28 2004
parent Sean Kelly <sean f4.ca> writes:
In article <cjc8s1$2nlu$1 digitaldaemon.com>, Ben Hinkle says...
"Sean Kelly" <sean f4.ca> wrote in message
news:cjc6oe$2mci$1 digitaldaemon.com...
 In article <opsez7nkdr5a2sq9 digitalmars.com>, Regan Heath says...
 Hmmm. It's a shame we can't write:



 to get platform-neutral behavior, isn't it?
We can write that.. however the 'const' applies to the array reference, not the data it refers to, AFAIK there is no way to apply const to the data it refers to.
Yup. The C++ syntax would be something like: char const[] const str;
I think you mean "char const* const str" or "const char* const str"
Well yeah, I was trying to create a D equivalent.
In C++ omitting the length of the array (eg char[] str) just means to
implicitly determine the length from the initializer (I thought). So
 char str[] = "foobar";
is the same as
 char str[7] = "foobar";
which is very different than
 char* str = "foobar";
It is kind of odd that there's no way to use "const" correctly here. What happens if you do this? char[] val = "static"; val ~= 'a'; ie. What is required to trigger the COW mechanism? I'd test this myself but my PC is about to go off for re-imaging. Sean
Sep 28 2004
prev sibling parent "Thomas Kuehne" <eisvogel users.sourceforge.net> writes:
Ben Hinkle schrieb:
 The code below will result in a segment fault under Linux but runs on
 Windows.

 int main(){
     char[] str="a1";
     str[0]++;
     assert(str[0]=='b');
     return 0;
 }
I don't think this is a bug - it's like the C (and C++) behavior for string literals. This came up on the main thread a few days ago. It should be mentioned in the doc if it isn't already.
To me it isn't a bug that the code runs/crashs. The problem is that it behaves different on different plattforms. Consider a module written on a Windows box that runs fine there but crashs when used on Linux. Now, pin-point me the problematic code ;) Thomas
Sep 27 2004
prev sibling parent reply Ant <Ant_member pathlink.com> writes:
In article <cj8uoq$63b$1 digitaldaemon.com>, Thomas Kuehne says...
The code below will result in a segment fault under Linux but runs on
Windows.

int main(){
    char[] str="a1";
    str[0]++;
    assert(str[0]=='b');
    return 0;
}
http://www.digitalmars.com/d/dcompiler.html " Differences from Win32 version * String literals are read-only. Attempting to write to them will cause a segment violation. * The configuration file is /etc/dmd.conf " I thik that's it Ant
Sep 27 2004
parent "Thomas Kuehne" <eisvogel users.sourceforge.net> writes:
Ant schrieb:
The code below will result in a segment fault under Linux but runs on
Windows.

int main(){
    char[] str="a1";
    str[0]++;
    assert(str[0]=='b');
    return 0;
}
http://www.digitalmars.com/d/dcompiler.html " Differences from Win32 version * String literals are read-only. Attempting to write to them will cause a segment violation. * The configuration file is /etc/dmd.conf " I thik that's it Ant
Hrrr, I've been searching through the language definition stuff, but there it is on the _compiler_ page! Thomas
Sep 27 2004