On Tue, 2023-11-07 at 19:02 -0500, Lewis Hyatt wrote:
> On Mon, Nov 6, 2023 at 8:29 PM David Malcolm <dmalc...@redhat.com>
> wrote:
> >
> > Here's a work-in-progress patch for GCC that adds a
> > libdiagnostics.h
> > header describing the public interface, along with various
> > testcases
> > that show usage examples for the API. Various aspects of this need
> > work; posting now for early feedback on overall direction.
> >
> > How does the interface look?
> >
> ...
> > +typedef unsigned int diagnostic_location_t;
>
> One comment that occurred to me... for GCC we have a lot of PRs that
> are unhappy about the 32-bit location_t and the consequent issues
> that
> arise with very large source files, or with very long lines that lose
> column information.
> So far GCC has been able to get by with "don't do that" advice, but a
> more general libdiagnostics may need to avoid that arbitrary
> limitation? I feel like it may not be that long before GCC needs to
> deal with it as well, perhaps with a configure option, but even now,
> it could make sense for libdiagnostic to use a 64-bit location_t
> itself from the outset, so it won't need to change later, even if
> it's
> practically restricted to 32 bits for now.
That's a good point.
Perhaps the interface should give back a pointer to an opaque type, so
it would be:
typedef struct diagnostic_location diagnostic_location;
and e.g.
extern const diagnostic_location *
diagnostic_manager_new_location_from_file_and_line (diagnostic_manager
*diag_mgr,
const diagnostic_file *file,
diagnostic_line_num_t
line_num);
where the diagnostic_manager owns the underlying memory.
Dave
