John Scott <[email protected]> writes:
> POSIX and the Single UNIX Specification reserves names ending in "_t"
> to the implementation for use in any header. The provision is at
> https://pubs.opengroup.org/onlinepubs/9799919799/functions/V2_chap02.html#tag_16_02_02
> but by "implementation" it means the operating system, or in our
> particular case it would be whatever C standard library one is using
> such as the GNU C Library. When an application defines an identifier
> that's reserved for the system to define, the behavior is undefined
> (except for certain special exceptions that don't apply here). This
> affects most of the client data types in gps.h.
My impression is that it's very normal for packages that provide
libraries to define types ending in _t. If it were only gpsd, and 95%+
of libraries were strictly conforming, that might be something -- but if
50%+ of libraries do it, then it really isn't a problem in gpsd.
As for relying on undefined behavior, in a very narrow pedantic sense
you might be right, but were an operating system to define a colliding
type, almost certainly that would result in gpsd failing to build.
Surely the arppoach is: We'll drive off that bridge when we come to it.
As for "too much pain", conditionally changing types is a lot of work,
and would need testing. It's a lot of pain, with the gain of -- so far
-- satisfying one pedant :-)
It would be intersting if you find an actual problem where building is
troubled in some environment.
> Unrelated remark:
>> struct attitude_t {
>> ⋮
>> // arbitrary time tag (see UBX-ESF-MEAS), 32 bit unsigned
>> unsigned long timeTag;
>> ⋮
>> }
> Modern GNU/Linux systems with a 64-bit word size make long 64 bits;
> this indirectly comes from a POSIX requirement. It would be nice if,
> for embedded applications or systems that don't have a pre-existing
> libgps that would have its ABI broken, if this could use uint32_t
> instead.
Following up on Gary said, gpsd is for any reasonable mostly-POSIX
system, not for GNU/Linux (although GNU/Linux is of course within the
set). It's not really Linux, though; C on 64-bit CPUs tends to be LP64.
It might be that with perfect hindsight that uint32_t would have been
better.
But looking at attitude_t, it's really hard to get upset about 4 bytes
(said as someone whose first computer had 8 kB). Especially since it's
between timespec and double -- it seems like it's really just a question
of having bytes that are in the type and 0 vs bytes that are padding.
I don't see any gain to changing it.
Are you trying to build on 16-bit processor?
