Do you have any idea about regression after applying workaround 1 ? (For
example, wrong output in some cases)
2016-09-20 21:37 GMT+09:00 Ilia K :
> Hi!
>
> Please see possible workarounds in https://llvm.org/bugs/show_
> bug.cgi?id=28253.
>
> On Tue, Sep 20, 2016 at 10:57 AM, Chunseok Lee via ll
On Tue, Sep 20, 2016 at 2:51 PM Greg Clayton wrote:
>
> > On Sep 20, 2016, at 2:49 PM, Mehdi Amini wrote:
> >
> >
> >> On Sep 20, 2016, at 2:46 PM, Zachary Turner wrote:
> >>
> >> Occasionally (and in my experience *very* occasionally), you need to
> treat "" as different from null.
>
> doesn't
> On Sep 20, 2016, at 2:41 PM, Mehdi Amini wrote:
>
>>
>> On Sep 20, 2016, at 2:31 PM, Greg Clayton wrote:
>>
>> We should avoid crashing if there is a reasonable work around when the input
>> is bad. StringRef with NULL is easy, just put NULL and zero length and don't
>> crash. Just becaus
> On Sep 20, 2016, at 2:49 PM, Mehdi Amini wrote:
>
>
>> On Sep 20, 2016, at 2:46 PM, Zachary Turner wrote:
>>
>> Occasionally (and in my experience *very* occasionally), you need to treat
>> "" as different from null.
doesn't StringRef store an actual pointer to ""? This would mean
String
> On Sep 20, 2016, at 2:46 PM, Zachary Turner wrote:
>
> Occasionally (and in my experience *very* occasionally), you need to treat ""
> as different from null.
return an Optional?
—
Mehdi
> But the frequency with which that is really necessary is much lower than
> people realize. It
Occasionally (and in my experience *very* occasionally), you need to treat
"" as different from null. But the frequency with which that is really
necessary is much lower than people realize. It just seems high because of
the prevalence of raw pointers.
For every other case, you can use withNullA
> On Sep 20, 2016, at 2:31 PM, Greg Clayton wrote:
>
> We should avoid crashing if there is a reasonable work around when the input
> is bad. StringRef with NULL is easy, just put NULL and zero length and don't
> crash. Just because it is documented, doesn't mean it needs to stay that way,
>
Also, maybe that code could just return a StringRef. It's like I mentioned
a few days ago (don't remember if it was this thread or another), but when
you've got StringRefs all the way down, this problem pretty much disappears.
On Tue, Sep 20, 2016 at 2:36 PM Zachary Turner wrote:
> StringRef ha
StringRef has `withNullAsEmpty` which I added a few days ago. It will
return an empty StringRef. seems to me that should solve most of those
kinds of problems.
On Tue, Sep 20, 2016 at 2:31 PM Greg Clayton wrote:
> We should avoid crashing if there is a reasonable work around when the
> input i
We should avoid crashing if there is a reasonable work around when the input is
bad. StringRef with NULL is easy, just put NULL and zero length and don't
crash. Just because it is documented, doesn't mean it needs to stay that way,
but I am not going to fight that battle.
We should make every e
> On Sep 20, 2016, at 2:19 PM, Greg Clayton wrote:
>
> Again, strlen is a stupid example as it is well documented. All of llvm and
> clang are not.
IMO that is:
1) A free claim that is easily defeated (to prove you wrong on *all* of LLVM
being not document I just have to point you to one exa
On 20 September 2016 at 17:25, Greg Clayton wrote:
>
> Well the DWARF code was copied from LLDB into LLVM. The original person
> didn't update LLDB to use it, so things diverged.
Yeah, sorry I didn't mention that explicitly. I do recall someone
pointed that out when this came up previously.
> I
I don't think anyone is ok with that. I just think that a better solution
is to document them. Why handle at runtime what is known about at compile
time?
On Tue, Sep 20, 2016 at 2:24 PM Zachary Turner wrote:
> Well, but StringRef for example is well documented. So it seems to me
> like there'
> On Sep 20, 2016, at 2:21 PM, Ed Maste via lldb-dev
> wrote:
>
> On 19 September 2016 at 16:18, Zachary Turner via lldb-dev
> wrote:
>>
>> De-inventing the wheel - We should use more code from LLVM, and delete code
>> in LLDB where LLVM provides a solution.
>
> Another example of duplicated
Well, but StringRef for example is well documented. So it seems to me like
there's an example of a perfectly used assert. It's documented that you
can't use null, and if you do it asserts. Just like strlen.
The issue I have with "you can't ever assert" is that it brings it into an
absolute when
A better solution would be to return an error indicating what went wrong with
llvm::Error.
I really can't believe people are ok with "well you called me with the wrong
parameters that aren't documented, I am unhappy and will crash your program"
mentality.
> On Sep 20, 2016, at 2:11 PM, Adria
On 19 September 2016 at 16:18, Zachary Turner via lldb-dev
wrote:
>
> De-inventing the wheel - We should use more code from LLVM, and delete code
> in LLDB where LLVM provides a solution.
Another example of duplicated code is the debug info parsing (LLDB
source/Plugins/SymbolFile/DWARF vs LLVM li
Again, strlen is a stupid example as it is well documented. All of llvm and
clang are not.
> On Sep 20, 2016, at 1:59 PM, Zachary Turner wrote:
>
>
>
> On Tue, Sep 20, 2016 at 1:55 PM Greg Clayton wrote:
>
> > On Sep 20, 2016, at 1:45 PM, Zachary Turner wrote:
> >
> > I do agree that assert
My concern about this example:
void do_something(foo *p)
{
assert(p);
if (p)
p->crash();
}
Is that by skipping the operation when the pointer is null is that it's not
clear what it should do if it's precondition isn't met. Sure, it won't
crash, but it's also not going to "do some
On Tue, Sep 20, 2016 at 1:55 PM Greg Clayton wrote:
>
> > On Sep 20, 2016, at 1:45 PM, Zachary Turner wrote:
> >
> > I do agree that asserts are sometimes used improperly. But who's to say
> that the bug was the assert, and not the surrounding code? For example,
> consider this code:
> >
> > a
My 2¢:
> assert(p);
> int x = *p;
> …
> assert(ptr);
> int x = strlen(ptr);
Both of these should either check for null, be in a situation where p is
obviously good (e.g., p is data() from a stack-allocated std::vector), or use
references. The assertion to my mind is like an admission "I'm not
> On Sep 20, 2016, at 1:45 PM, Zachary Turner wrote:
>
> I do agree that asserts are sometimes used improperly. But who's to say that
> the bug was the assert, and not the surrounding code? For example, consider
> this code:
>
> assert(p);
> int x = *p;
Should be written as:
assert(p);
if
I do agree that asserts are sometimes used improperly. But who's to say
that the bug was the assert, and not the surrounding code? For example,
consider this code:
assert(p);
int x = *p;
Should this assert also not be here in library code? I mean it's obvious
that the program is about to crash
On Tue, Sep 20, 2016 at 4:37 PM, Ted Woodward via lldb-dev <
lldb-dev@lists.llvm.org> wrote:
>
> From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of
> Zachary Turner via lldb-dev
> Sent: Tuesday, September 20, 2016 12:47 PM
>
> > This kind of philisophical debate is probably worth
From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Zachary
Turner via lldb-dev
Sent: Tuesday, September 20, 2016 12:47 PM
> This kind of philisophical debate is probably worthy of a separate thread :)
> That being said, I think asserts are typically used in places where the
> On Sep 20, 2016, at 10:47 AM, Mehdi Amini wrote:
>
>>
>> On Sep 20, 2016, at 10:33 AM, Greg Clayton wrote:
>>
>>>
>>> On Sep 19, 2016, at 2:46 PM, Mehdi Amini wrote:
>>>
On Sep 19, 2016, at 2:34 PM, Greg Clayton wrote:
>
> On Sep 19, 2016, at 2:20 PM, Mehdi Ami
> On Sep 20, 2016, at 10:46 AM, Zachary Turner wrote:
>
> This kind of philisophical debate is probably worthy of a separate thread :)
> That being said, I think asserts are typically used in places where the
> assert firing means "You're going to crash *anyway*"
>
> It's like trying to hand
If you use the MI, that assumes that the server process is the one doing most
of the work. lldb is not meant to be a light-weight program, and if you start
feeding it a lot of symbol information you may find it taking up too many
resources to really want to run it on your device. For device d
> On Sep 20, 2016, at 10:33 AM, Greg Clayton wrote:
>
>>
>> On Sep 19, 2016, at 2:46 PM, Mehdi Amini wrote:
>>
>>>
>>> On Sep 19, 2016, at 2:34 PM, Greg Clayton wrote:
>>>
On Sep 19, 2016, at 2:20 PM, Mehdi Amini wrote:
>
> On Sep 19, 2016, at 2:02 PM, Greg Clayt
This kind of philisophical debate is probably worthy of a separate thread
:) That being said, I think asserts are typically used in places where the
assert firing means "You're going to crash *anyway*"
It's like trying to handle a bad alloc. What are you going to do anyway?
You can crash now or
> On Sep 19, 2016, at 2:46 PM, Mehdi Amini wrote:
>
>>
>> On Sep 19, 2016, at 2:34 PM, Greg Clayton wrote:
>>
>>>
>>> On Sep 19, 2016, at 2:20 PM, Mehdi Amini wrote:
>>>
On Sep 19, 2016, at 2:02 PM, Greg Clayton via lldb-dev
wrote:
> On Sep 19, 2016, at 1:
FWIW I added a function to StringRef the other day that looks like this:
static StringRef withNullAsEmpty(const char *Str) {
return StringRef(Str ? Str : "");
}
I've been using this code in converting existing uses of const char * over
to StringRef. It's not 100% what you want, but at least it
But StringRef is a smart string wrapper and it is there for exactly this
reason: to make string handling correct. So let us let it be smart and not
crash if you make it with null and call .size() on it...
> On Sep 19, 2016, at 2:37 PM, Zachary Turner wrote:
>
> FWIW, strlen(nullptr) will also c
Hi!
Please see possible workarounds in
https://llvm.org/bugs/show_bug.cgi?id=28253.
On Tue, Sep 20, 2016 at 10:57 AM, Chunseok Lee via lldb-dev <
lldb-dev@lists.llvm.org> wrote:
> Dear lldb dev team,
>
> I am working on running lldb-mi on arm32 device(like rpi) for remote
> debugging usage.
> Is
Dear lldb dev team,
I am working on running lldb-mi on arm32 device(like rpi) for remote
debugging usage.
Is there any way to run lldb-mi with python disabled ?
When building lldb with LLDB_DISABLE_PYTHON, it seems that dataformatter
initialization is failed due to the following code in
MICmnLLDBD
35 matches
Mail list logo
