* /usr/include/aio.h
@ 2020-10-03 22:02 Jonny Grant
2020-10-03 22:39 ` /usr/include/aio.h Paul Eggert
0 siblings, 1 reply; 9+ messages in thread
From: Jonny Grant @ 2020-10-03 22:02 UTC (permalink / raw)
To: libc-alpha
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: /usr/include/aio.h
2020-10-03 22:02 /usr/include/aio.h Jonny Grant
@ 2020-10-03 22:39 ` Paul Eggert
2020-10-04 6:54 ` /usr/include/aio.h Andreas Schwab
2020-10-05 15:29 ` /usr/include/aio.h Jonny Grant
0 siblings, 2 replies; 9+ messages in thread
From: Paul Eggert @ 2020-10-03 22:39 UTC (permalink / raw)
To: Jonny Grant; +Cc: libc-alpha
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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: /usr/include/aio.h
2020-10-03 22:39 ` /usr/include/aio.h Paul Eggert
@ 2020-10-04 6:54 ` Andreas Schwab
2020-10-05 15:29 ` /usr/include/aio.h Jonny Grant
1 sibling, 0 replies; 9+ messages in thread
From: Andreas Schwab @ 2020-10-04 6:54 UTC (permalink / raw)
To: Paul Eggert; +Cc: Jonny Grant, libc-alpha
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."
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: /usr/include/aio.h
2020-10-03 22:39 ` /usr/include/aio.h Paul Eggert
2020-10-04 6:54 ` /usr/include/aio.h Andreas Schwab
@ 2020-10-05 15:29 ` Jonny Grant
2020-10-05 17:52 ` /usr/include/aio.h Paul Eggert
1 sibling, 1 reply; 9+ messages in thread
From: Jonny Grant @ 2020-10-05 15:29 UTC (permalink / raw)
To: Paul Eggert; +Cc: libc-alpha
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: /usr/include/aio.h
2020-10-05 15:29 ` /usr/include/aio.h Jonny Grant
@ 2020-10-05 17:52 ` Paul Eggert
2020-10-05 20:53 ` /usr/include/aio.h Jonny Grant
0 siblings, 1 reply; 9+ messages in thread
From: Paul Eggert @ 2020-10-05 17:52 UTC (permalink / raw)
To: Jonny Grant; +Cc: libc-alpha
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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: /usr/include/aio.h
2020-10-05 17:52 ` /usr/include/aio.h Paul Eggert
@ 2020-10-05 20:53 ` Jonny Grant
2020-10-05 21:35 ` /usr/include/aio.h Paul Eggert
0 siblings, 1 reply; 9+ messages in thread
From: Jonny Grant @ 2020-10-05 20:53 UTC (permalink / raw)
To: Paul Eggert; +Cc: libc-alpha
[-- 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,
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: /usr/include/aio.h
2020-10-05 20:53 ` /usr/include/aio.h Jonny Grant
@ 2020-10-05 21:35 ` Paul Eggert
2020-10-06 10:52 ` /usr/include/aio.h Jonny Grant
0 siblings, 1 reply; 9+ messages in thread
From: Paul Eggert @ 2020-10-05 21:35 UTC (permalink / raw)
To: Jonny Grant; +Cc: libc-alpha
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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: /usr/include/aio.h
2020-10-05 21:35 ` /usr/include/aio.h Paul Eggert
@ 2020-10-06 10:52 ` Jonny Grant
2020-10-06 11:11 ` /usr/include/aio.h Florian Weimer
0 siblings, 1 reply; 9+ messages in thread
From: Jonny Grant @ 2020-10-06 10:52 UTC (permalink / raw)
To: Paul Eggert; +Cc: libc-alpha
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: /usr/include/aio.h
2020-10-06 10:52 ` /usr/include/aio.h Jonny Grant
@ 2020-10-06 11:11 ` Florian Weimer
0 siblings, 0 replies; 9+ messages in thread
From: Florian Weimer @ 2020-10-06 11:11 UTC (permalink / raw)
To: Jonny Grant; +Cc: Paul Eggert, libc-alpha
* 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
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2020-10-06 11:11 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-10-03 22:02 /usr/include/aio.h Jonny Grant
2020-10-03 22:39 ` /usr/include/aio.h Paul Eggert
2020-10-04 6:54 ` /usr/include/aio.h Andreas Schwab
2020-10-05 15:29 ` /usr/include/aio.h Jonny Grant
2020-10-05 17:52 ` /usr/include/aio.h Paul Eggert
2020-10-05 20:53 ` /usr/include/aio.h Jonny Grant
2020-10-05 21:35 ` /usr/include/aio.h Paul Eggert
2020-10-06 10:52 ` /usr/include/aio.h Jonny Grant
2020-10-06 11:11 ` /usr/include/aio.h Florian Weimer
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).