/usr/include/aio.h

/usr/include/aio.h

[Jonny Grant]

Hello

Just wondering :

a) why there are these macros like AIO_ALLDONE below? Surely the enum is enough.

b) why the enum's aren't numbered, so when looking in a debugger it's easier to follow the number back to this header file

/* Return values of cancelation function.  */
enum
{
  AIO_CANCELED,
#define AIO_CANCELED AIO_CANCELED
  AIO_NOTCANCELED,
#define AIO_NOTCANCELED AIO_NOTCANCELED
  AIO_ALLDONE
#define AIO_ALLDONE AIO_ALLDONE
};


Cheers, Jonny

Re: /usr/include/aio.h

[Paul Eggert]

On 10/3/20 3:02 PM, Jonny Grant wrote:
> a) why there are these macros like AIO_ALLDONE below? Surely the enum is enough.

POSIX requires symbolic constants to be defined as macros. It's kind of a silly 
requirement; perhaps that should get fixed someday (you can file a change 
request :-).

> b) why the enum's aren't numbered, so when looking in a debugger it's easier to follow the number back to this header file

That'd be more work to maintain. With GDB you can type "print AIO_ALLDONE+0" to 
see the numeric value.

Re: /usr/include/aio.h

[Andreas Schwab]

On Okt 03 2020, Paul Eggert wrote:

> That'd be more work to maintain. With GDB you can type "print
> AIO_ALLDONE+0" to see the numeric value.

Or use print/d.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: /usr/include/aio.h

[Jonny Grant]

Hi Paul,

On 03/10/2020 23:39, Paul Eggert wrote:
> On 10/3/20 3:02 PM, Jonny Grant wrote:
>> a) why there are these macros like AIO_ALLDONE below? Surely the enum is enough.
> 
> POSIX requires symbolic constants to be defined as macros. It's kind of a silly requirement; perhaps that should get fixed someday (you can file a change request :-).

I imagine that's difficult to get POSIX changes, they would usually take in changes from POSIX implementations first right?

>> b) why the enum's aren't numbered, so when looking in a debugger it's easier to follow the number back to this header file
> 
> That'd be more work to maintain. With GDB you can type "print AIO_ALLDONE+0" to see the numeric value.

Ok I'll try that. I recall it was the int return code of aio_cancel(), so I was just looking to see what number it corresponded with in aio.h, there are only 3 values in the enum, can be counted, but I always find explicit enum values clearer.

Jonny

Re: /usr/include/aio.h

[Paul Eggert]

On 10/5/20 8:29 AM, Jonny Grant wrote:
> I imagine that's difficult to get POSIX changes, they would usually take in changes from POSIX implementations first right?

That's preferable, yes. Though there is a chicken and egg problem.

Re: /usr/include/aio.h

[Jonny Grant]

[-- Attachment #1: Type: text/plain, Size: 843 bytes --]

Hi Paul

On 05/10/2020 18:52, Paul Eggert wrote:
> On 10/5/20 8:29 AM, Jonny Grant wrote:
>> I imagine that's difficult to get POSIX changes, they would usually take in changes from POSIX implementations first right?
> 
> That's preferable, yes. Though there is a chicken and egg problem.

It looks like everything would compile fine with the enum alone as follows:

enum
{
  AIO_CANCELED = 0,
  AIO_NOTCANCELED = 1,
  AIO_ALLDONE = 2
};


Could this comment patch be considered?

I clarified aio_cancel is the cancel function, and also replaced "maximal" with "maximum"


BTW, could __REDIRECT_NTH be documented in that header?
It seems to call the same functions that __USE_FILE_OFFSET64 enables - although those are only declared by __USE_LARGEFILE64
maybe scope to reduce the use of those two macros if only one is needed?


Cheers, Jonny

[-- Attachment #2: aio.h.patch --]
[-- Type: text/x-patch, Size: 600 bytes --]

--- aio.h.orig	2020-10-05 21:46:23.354543383 +0100
+++ aio.h	2020-10-05 21:48:51.337228111 +0100
@@ -86,7 +86,7 @@
    This implementation follows the one in Irix.  */
 struct aioinit
   {
-    int aio_threads;		/* Maximal number of threads.  */
+    int aio_threads;		/* Maximum number of threads.  */
     int aio_num;		/* Number of expected simultanious requests. */
     int aio_locks;		/* Not used.  */
     int aio_usedba;		/* Not used.  */
@@ -99,7 +99,7 @@
 #endif
 
 
-/* Return values of cancelation function.  */
+/* Return values of the aio_cancel function.  */
 enum
 {
   AIO_CANCELED,

Re: /usr/include/aio.h

[Paul Eggert]

On 10/5/20 1:53 PM, Jonny Grant wrote:
>
> It looks like everything would compile fine with the enum alone as follows:
>
> enum
> {
>    AIO_CANCELED = 0,
>    AIO_NOTCANCELED = 1,
>    AIO_ALLDONE = 2
> };


Everything in glibc, most likely yes. But application code that uses 
"#ifdef AIO_NOTCANCELLED" wouldn't work.


>
> Could this comment patch be considered?
>
Yes, it should be fine.

Re: /usr/include/aio.h

[Jonny Grant]

On 05/10/2020 22:35, Paul Eggert wrote:
> 
> On 10/5/20 1:53 PM, Jonny Grant wrote:
>>
>> It looks like everything would compile fine with the enum alone as follows:
>>
>> enum
>> {
>>    AIO_CANCELED = 0,
>>    AIO_NOTCANCELED = 1,
>>    AIO_ALLDONE = 2
>> };
> 
> 
> Everything in glibc, most likely yes. But application code that uses "#ifdef AIO_NOTCANCELLED" wouldn't work.

May I ask if glibc would ever make an update that caused application code to fail to compile?

If POSIX says it must be be a macro, is there a reason there is an enum at present as well?

In which case that would make it:

#define AIO_CANCELED 0
#define AIO_NOTCANCELED 1
#define AIO_ALLDONE 2

Jonny

Re: /usr/include/aio.h

[Florian Weimer]

* Jonny Grant:

> May I ask if glibc would ever make an update that caused application
> code to fail to compile?

Yes, occasionally, like when we introduce new identifiers required by
standards.

Thanks,
Florian
-- 
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill