On 23/02/10 15:14, Ellery Newcomer wrote:
Is there any decent way to figure out where segfaults are coming from?
e.g. 200k lines of bad code converted from java
I tried gdb, and it didn't seem to work too well.
Die: DW_TAG_type_unit (abbrev 3, offset 0x6d)
parent at offset: 0xb
has children: F
Daniel Keep wrote:
>> ...
>>
>> I see that neither the constructor nor the postblit is called.
>> Apparently the bit representation is used. This has the risk of
>> violating struct invariants.
>>
>> Is it legal?
>>
>> Thank you,
>> Ali
>
> cast is to value conversions what a tactical nuclear stri
Okay, I'm trying to find out if a particular string is in an array of strings.
The best function that I can find for that appears to be find(), since there's
no contains() or anything
like that and in only works for associative arrays. So, my code is something
similar to this:
string[] list;
On 02/22/2010 08:41 PM, Jesse Phillips wrote:
Ellery Newcomer wrote:
Is there any decent way to figure out where segfaults are coming from?
e.g. 200k lines of bad code converted from java
I tried gdb, and it didn't seem to work too well.
Die: DW_TAG_type_unit (abbrev 3, offset 0x6d)
pare
Ellery Newcomer wrote:
> Is there any decent way to figure out where segfaults are coming from?
>
> e.g. 200k lines of bad code converted from java
>
> I tried gdb, and it didn't seem to work too well.
>
> Die: DW_TAG_type_unit (abbrev 3, offset 0x6d)
>parent at offset: 0xb
>has children:
Is there any decent way to figure out where segfaults are coming from?
e.g. 200k lines of bad code converted from java
I tried gdb, and it didn't seem to work too well.
Die: DW_TAG_type_unit (abbrev 3, offset 0x6d)
parent at offset: 0xb
has children: FALSE
attributes:
DW_AT_byte_size
> ...
>
> I see that neither the constructor nor the postblit is called.
> Apparently the bit representation is used. This has the risk of
> violating struct invariants.
>
> Is it legal?
>
> Thank you,
> Ali
cast is to value conversions what a tactical nuclear strike is to
peaceful negotiations
Jacob Carlborg wrote:
> On 2010-02-22 15.39, Nils Hensel wrote:
>> Daniel Keep schrieb:
>>> If you look at the real main function in src\phobos\internal\dmain2.d,
>>> you'll see this somewhere around line 109 (I'm using 1.051, but it's
>>> unlikely to be much different in an earlier version):
>>>
Is the following cast legal with dmd 2.040?
struct MyChar
{
dchar d;
this(dchar param)
in {
assert(false); // not called
}
body
{
d = param;
assert(d != param); // not called
}
this(this)
in {
assert(false); // not
Jonathan M Davis Wrote:
> Jesse Phillips wrote:
> > Please note that I do not know how any of this will related to practices
> > on Windows. And sadly this is not D specific and actually C stuff.
> >
> > 1. http://www.opengroup.org/onlinepubs/007908799/xsh/exec.html
> > 2. http://www.yolinux.com/
On 2010-02-22 15.39, Nils Hensel wrote:
Daniel Keep schrieb:
If you look at the real main function in src\phobos\internal\dmain2.d,
you'll see this somewhere around line 109 (I'm using 1.051, but it's
unlikely to be much different in an earlier version):
for (size_t i = 0; i< argc; i++)
{
Jonathan M Davis wrote:
> Jesse Phillips wrote:
>> As you may have noticed by the comments to on bug 3158. exec()[1] calls
>> replace your process, this means it will not continue your program. To
>> get arround this you find that people will first fork()[2] and exec on
>> the child process.
>
> A
Nils Hensel wrote:
Lars T. Kyllingstad schrieb:
I just realised that D2 also does what Daniel says Tango does. I guess
this is because D2's runtime, druntime, is based on Tango's runtime. So
most likely you don't need to use std.encoding after all.
Really? So all I'd need to do would be to s
Lars T. Kyllingstad schrieb:
> I just realised that D2 also does what Daniel says Tango does. I guess
> this is because D2's runtime, druntime, is based on Tango's runtime. So
> most likely you don't need to use std.encoding after all.
Really? So all I'd need to do would be to switch to D2? I'd
On Mon, 22 Feb 2010 11:24:36 -0500, strtr wrote:
Steven Schveighoffer Wrote:
But still, what does it matter? Just don't use D1 if you want a
compiler
error, or don't try and trick the system into modifying ROM! There are
plenty of projects using D1 that just don't do this, and they are
Steven Schveighoffer Wrote:
>
> But still, what does it matter? Just don't use D1 if you want a compiler
> error, or don't try and trick the system into modifying ROM! There are
> plenty of projects using D1 that just don't do this, and they are fine.
> Implementing features to help peop
On Mon, 22 Feb 2010 10:19:52 -0500, grauzone wrote:
Steven Schveighoffer wrote:
On Mon, 22 Feb 2010 09:27:57 -0500, strtr wrote:
Thanks, I understand.
But, how about a runtime error?
Isn't a literal placed in easy to identify should-only-read memory?
A segfault is a runtime error. The prob
grauzone Wrote:
>
> Windows can protect memory as read-only too. Why dmd doesn't do that is
> a mystery. Even if .exe doesn't support read-only data segments, the
> runtime could have done so in early start-up code.
>
If that is the case, then I'd suggest a(n enhancement?) bug-report :)
Steven Schveighoffer wrote:
On Mon, 22 Feb 2010 09:27:57 -0500, strtr wrote:
Thanks, I understand.
But, how about a runtime error?
Isn't a literal placed in easy to identify should-only-read memory?
A segfault is a runtime error. The problem with Windows is it doesn't
throw an error on writ
Lars T. Kyllingstad wrote:
Nils Hensel wrote:
Daniel Keep schrieb:
If you look at the real main function in src\phobos\internal\dmain2.d,
you'll see this somewhere around line 109 (I'm using 1.051, but it's
unlikely to be much different in an earlier version):
for (size_t i = 0; i < argc; i++
Nils Hensel wrote:
Daniel Keep schrieb:
If you look at the real main function in src\phobos\internal\dmain2.d,
you'll see this somewhere around line 109 (I'm using 1.051, but it's
unlikely to be much different in an earlier version):
for (size_t i = 0; i < argc; i++)
{
auto len = strlen(ar
On Mon, 22 Feb 2010 09:27:57 -0500, strtr wrote:
Thanks, I understand.
But, how about a runtime error?
Isn't a literal placed in easy to identify should-only-read memory?
A segfault is a runtime error. The problem with Windows is it doesn't
throw an error on writes to its data segment (unli
Daniel Keep schrieb:
> If you look at the real main function in src\phobos\internal\dmain2.d,
> you'll see this somewhere around line 109 (I'm using 1.051, but it's
> unlikely to be much different in an earlier version):
>
>> for (size_t i = 0; i < argc; i++)
>> {
>> auto len = strlen(argv[i])
Steven Schveighoffer Wrote:
> On Mon, 22 Feb 2010 08:32:20 -0500, strtr wrote:
>
> > Daniel Keep Wrote:
> >
> >>
> >> strtr wrote:
> >> > On winXP (D1) I can compile/run this code without a problem.
> >> > Not even a warning.
> >> >
> >> > void main() {
> >> > char[] s= "immutable literal?";
>
On Mon, 22 Feb 2010 08:32:20 -0500, strtr wrote:
Daniel Keep Wrote:
strtr wrote:
> On winXP (D1) I can compile/run this code without a problem.
> Not even a warning.
>
> void main() {
> char[] s= "immutable literal?";
> s[$-1] = '!';
> writefln(s);
> }
> Codepad runs into a segmentatio
Daniel Keep Wrote:
>
> strtr wrote:
> > On winXP (D1) I can compile/run this code without a problem.
> > Not even a warning.
> >
> > void main() {
> > char[] s= "immutable literal?";
> > s[$-1] = '!';
> > writefln(s);
> > }
> > Codepad runs into a segmentation fault.
> > http://codepad.or
Jonathan M Davis wrote:
Okay, I'm looking to be able to run an external program from within my D
program. The library functions for this appear to be in std.process. You
have system() and various versions of execv(). system() makes a call in
shell. execv() executes the program without a shell.
27 matches
Mail list logo
