Yo John! On Sun, 21 Sep 2025 00:43:09 +0000 John Scott <[email protected]> wrote:
> This might come off as pedantic but I'd like to bring this to your > attention in case it's been overlooked. New to me. > POSIX and the Single UNIX Specification reserves names ending in "_t" > to the implementation for use in any header. Which is whee gpsd uses them. In its headers. _t is used to mean a type definition, which is how gpsd uses it. > 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. Never hd a collision yet. And note that gpsd predates that "standard". > If gpsd relies on undefined behavior in its operation, as many > applications do, that'd be one thing. The reason why this > specifically matters to me is because *client applications* need to > be written to use the 'struct gps_data_t' and like data types, and > therefore the namespace issue is viral: I must repeat the mistake in > my application in order to use libgps. Because it's a type name it's > not like it can be worked around with tricks like linker options or > dlopen(). How is thisundeefined behavior? If there was a name collision then the compiler would findit. > Fortunately I have an idea to solve this without too much pain. For > the gps.h header used by libgps client applications, the use of the > '_t' suffix could be kept by default but switched off with an include > guard. For example a program I write could #define something like > 'GPSD_POSIXLY_CORRECT' before including <gps.h>, so that when I do > include <gps.h>, it can do an '#ifdef GPSD_POSIXLY_CORRECT' and > define the same name without the _t suffix. This would let existing > applications keep doing what they're doing without any difference, > and because it's just the name of the structure type itself there's > no ABI change. Not too much pain? -T used in a huge number of plces. And when anything changes in gps.h there are no end of complaints from our users. > There are a lot of similar issues but it'd be better for a regular > gpsd contributor to decide what to do about those. Here are some > random examples from gps.h: When a real word compiler complains, we'll change ti. Until then there is way too much history to do any wholesale changes. > Modern GNU/Linux systems with a 64-bit word size make long 64 bits; gpsd is not just for modern Linux systems only This is a large source of problems with user submitted patches. The C standard only required 32 bits for a long, and this is still very common. > I recognize that these problems may not be a priority for fixing and > it's not my intention to "voluntell" anyone what to do about them. > With this mail I hope to ensure those choices are informed ones. Good things to take note of for new code, but way to invasive when the issues invavled do not have any known error effects. > P.S. A motivation for caring about this is I'm considering using gpsd > on a microcontroller with a real-time operating system like NuttX or > RTEMS and conformance to software standards when practical, In which case, assuming POSIX, Linux or 32-bit longs would be fatal. > and in > the absence of a reason to depart from them, will make esoteric use > cases like mine more likely to work without too much trouble. I'm > making a navigation system for my bicycle 🚲 Speaking of "trouble", let us know when you find any issue that actually affects compilation or execution. gpsd predates most standards and is well tested to ensure no real world issues like you describe exit. RGDS GARY --------------------------------------------------------------------------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 [email protected] Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can't measure it, you can't improve it." - Lord Kelvin
pgpjXp4Dkx6jj.pgp
Description: OpenPGP digital signature
