RE: [PATCH 1/2] system_data_types.7: Add 'void *'
> > +.I void * > > +.RS > > +According to the C language standard, > > +a pointer to any object type may be converted to a pointer to > > +.I void > > +and back. > > +POSIX further requires that any pointer, > > +including pointers to functions, > > +may be converted to a pointer to > > +.I void > > +and back. > > +.PP > > +Conversions from and to any other pointer type are done implicitly, > > +not requiring casts at all. > > +Note that this feature prevents any kind of type checking: > > +the programmer should be careful not to cast a > > +.I void * > > +value to a type incompatible to that of the underlying data, > > +because that would result in undefined behavior. > > +.PP > > +This type is useful in function parameters and return value > > +to allow passing values of any type. > > +The function will usually use some mechanism to know > > +of which type the underlying data passed to the function really is. > > This sentence seems clunky. > > How about "The function will typically use some mechanism to know the > real type of the data being passed via a pointer to void." > > An example of "some mechanism" might be useful, though I don't have > one to offer. It's also bollocks. There are two main places 'void *' is used: 1) buffers (eg functions like read() and write()) when the associated byte length is also passed. This (sort of) includes memory allocation functions. 2) Passing a parameter for a callback function. In this case the pointer is always cast back to the original type before being used. What it shouldn't be used for is structures you don't want other code to look inside - use incomplete structs. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
RE: [PATCH v3] Many pages: Document fixed-width types with ISO C naming
From: Joseph Myers > Sent: 25 August 2022 15:39 > > On Thu, 25 Aug 2022, Linus Torvalds wrote: > > > That's a small detail that yes, we've tried to avoid the absolute > > humongous mess that the C standard library has with their horrendous > > 'PRId*' mess, but honestly, it's just a tiny detail. > > I've not yet implemented it for glibc or for GCC format checking, but C23 > adds 'wN' format length modifiers so you will be able to e.g. use "%w64d" > with printf to print an int64_t and won't need those PRI macros any more. Is that meant to work regardless of whether the type is int, long or long long provided the size is correct? Or does it require the compiler know which type inttypes.h uses for uint32_t and uint64_t? David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
RE: [RFC] bpf.2: Use standard types and attributes
From: Zack Weinberg > Sent: 25 April 2021 20:17 > > On Sat, Apr 24, 2021 at 4:43 PM David Laight via Libc-alpha > wrote: > > From: Alexei Starovoitov > > > On Fri, Apr 23, 2021 at 4:15 PM Alejandro Colomar > > > wrote: > ... > > > > Some pages also document attributes, using GNU syntax > > > > '__attribute__((xxx))'. Update those to use the shorter and more > > > > portable C2x syntax, which hasn't been standardized yet, but is > > > > already implemented in GCC, and available through either --std=c2x > > > > or any of the --std=gnu... options. > .. > > And the code below is no more portable that a #pragma'. > > It is probably worse than __attribute__((aligned(8))) > > +uint64_t [[gnu::aligned(8)]] value; > > The standards committee are smoking dope again. > > At least the '__aligned_u64 value;' form stands a reasonable > > chance of being converted by cpp into whatever your compiler supports. > > Is it actually necessary to mention the alignment overrides at all in > the manpages? They are only relevant to people working at the level > of physical layout of the data in RAM, and those people are probably > going to have to consult the header file anyway. Depends, if the man page defines the structure - it needs to contain its definition. If theory the man page ought to be the definition, and the code do what the man page says happens. An alternative is for the man page to say that the structure contains some fields - without prescribing the order, or stopping the implementation adding additional fields (or even changing the actual numeric type). This is more common in the standards documents. IMHO The Linux pages really ought to say how linux does things. (With notes about portability.) David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
RE: [RFC v2] bpf.2: Use standard types and attributes
From: Florian Weimer > Sent: 04 May 2021 20:46 > > * Alejandro Colomar: > > > The thing is, in all of those threads, the only reasons to avoid > > types in the kernel (at least, the only explicitly > > mentioned ones) are (a bit simplified, but this is the general idea of > > those threads): > > > > * Possibly breaking something in such a big automated change. > > * Namespace collision with userspace (the C standard allows defining > > uint32_t for nefarious purposes as long as you don't include > > . POSIX prohibits that, though) > > * Uglier > > __u64 can't be formatted with %llu on all architectures. That's not > true for uint64_t, where you have to use %lu on some architectures to > avoid compiler warnings (and technically undefined behavior). There are > preprocessor macros to get the expected format specifiers, but they are > clunky. I don't know if the problem applies to uint32_t. It does > happen with size_t and ptrdiff_t on 32-bit targets (both vary between > int and long). uint32_t can be 'randomly' either int or long on typical 32bit architectures. The correct way to print it is with eg "xxx %5.4" PRI_u32 " yyy". Typed like ptrdiff_t and size_t exist because of things like the x86 segmented model. Pointers are 32bit (segment and offset), size_t is (probably) 16 bit (nothing can be any bigger), but ptrdiff_t has to be 32bit to contain [-65535 .. 65535]. Kernel code has used u8, u16 and u32 since well before the standards body even thought about fixed width types (and well before Linux). ISTR they were considered as the standard names, but rejected and the current definitions approved. They were probably too worried about code already using u32 for a variable. (Shame they never fixed math.h) David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
RE: [RFC] bpf.2: Use standard types and attributes
From: Alexei Starovoitov
> Sent: 24 April 2021 00:20
>
> On Fri, Apr 23, 2021 at 4:15 PM Alejandro Colomar
> wrote:
> >
> > Some manual pages are already using C99 syntax for integral
> > types 'uint32_t', but some aren't. There are some using kernel
> > syntax '__u32'. Fix those.
> >
> > Some pages also document attributes, using GNU syntax
> > '__attribute__((xxx))'. Update those to use the shorter and more
> > portable C2x syntax, which hasn't been standardized yet, but is
> > already implemented in GCC, and available through either --std=c2x
> > or any of the --std=gnu... options.
> >
> > Signed-off-by: Alejandro Colomar
> > ---
> > man2/bpf.2 | 47 +++
> > 1 file changed, 23 insertions(+), 24 deletions(-)
> >
> > diff --git a/man2/bpf.2 b/man2/bpf.2
> > index 6e1ffa198..204f01bfc 100644
> > --- a/man2/bpf.2
> > +++ b/man2/bpf.2
> > @@ -188,39 +188,38 @@ commands:
> > .EX
> > union bpf_attr {
> > struct {/* Used by BPF_MAP_CREATE */
> > -__u32 map_type;
> > -__u32 key_size;/* size of key in bytes */
> > -__u32 value_size; /* size of value in bytes */
> > -__u32 max_entries; /* maximum number of entries
> > - in a map */
> > +uint32_tmap_type;
> > +uint32_tkey_size;/* size of key in bytes */
> > +uint32_tvalue_size; /* size of value in bytes */
> > +uint32_tmax_entries; /* maximum number of entries
> > +in a map */
>
> Nack.
> The man page should describe the kernel api the way it is in .h file.
And the code below is no more portable that a #pragma'.
It is probably worse than __attribute__((aligned(8)))
+uint64_t [[gnu::aligned(8)]] value;
The standards committee are smoking dope again.
At least the '__aligned_u64 value;' form stands a reasonable
chance of being converted by cpp into whatever your compiler supports.
OTOH the bfp developers want shooting for defining a structure
with hidden padding fields.
It they ensured that all 64bit fields were aligned they wouldn't
need the __aligned_u64 at all.
And would be much less likely to leak kernel stack to userspace.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT,
UK
Registration No: 1397386 (Wales)
