diff options
| author | Andrew Burgess <aburgess@redhat.com> | 2023-12-22 11:48:54 +0000 |
|---|---|---|
| committer | Andrew Burgess <aburgess@redhat.com> | 2024-01-04 09:24:18 +0000 |
| commit | c9f1e0dfc8f02a7772aa383cc305d9049075d1d8 (patch) | |
| tree | 2a18e0cbf9bd23a669f6e5ba5c4280d44f537b9f /gdb | |
| parent | 06bfdc6e5ee0745877ef941f50f680d342b5c585 (diff) | |
| download | gdb-c9f1e0dfc8f02a7772aa383cc305d9049075d1d8.zip gdb-c9f1e0dfc8f02a7772aa383cc305d9049075d1d8.tar.gz gdb-c9f1e0dfc8f02a7772aa383cc305d9049075d1d8.tar.bz2 | |
gdb: don't try to style content in error calls
While working on a later commit in this series I realised that the
error() function doesn't support output styling. Due to the way that
output from error() calls is passed around within the exception
object and often combined with other output, it's not immediately
obvious to me if we should be trying to support styling in this
context or not.
On inspection, I found one place in GDB where we apparently try to
apply styling within the error() output (in procfs.c). I suspect this
error() call might not be tested.
Rather than try to implement styling in the error() output, right now
I'm proposing to just remove the attempt to style error() output.
This doesn't mean that someone shouldn't add error() styling in the
future, but right now, I'm not planning to do that, I just wanted to
fix this in passing.
Approved-By: John Baldwin <jhb@FreeBSD.org>
Diffstat (limited to 'gdb')
| -rw-r--r-- | gdb/procfs.c | 6 |
1 files changed, 2 insertions, 4 deletions
diff --git a/gdb/procfs.c b/gdb/procfs.c index 1410bbc..0eafc2e 100644 --- a/gdb/procfs.c +++ b/gdb/procfs.c @@ -605,10 +605,8 @@ static void proc_error (procinfo *pi, const char *func, int line) { int saved_errno = errno; - error ("procfs: %s line %d, %ps: %s", - func, line, styled_string (file_name_style.style (), - pi->pathname), - safe_strerror (saved_errno)); + error ("procfs: %s line %d, %s: %s", + func, line, pi->pathname, safe_strerror (saved_errno)); } /* Updates the status struct in the procinfo. There is a 'valid' |