Re: Git rejecting branch merge
On 10/2/20 2:52 AM, Joel Brobecker wrote: I wonder I can get the branch moved, so I can do the benchmarking :) Any suggestions how to do that? I just installed a small patch, hot-fix style which I am hoping will fix your problem. Can you try it? It passes the testsuite, so the change should be safe. I can confirm I was able to delete a branch on remove server: $ git push origin --delete refs/users/marxin/heads/gfc-trailing-spec To git+ssh://gcc.gnu.org/git/gcc.git - [deleted] refs/users/marxin/heads/gfc-trailing-spec Thanks for it, Martin Let me know how it goes. I will finish the work over the weekend so as to replace the local diff by an actual commit (after review from a coworker of mine).
Re: [RFC] man7/system_data_types.7: Document [unsigned] __int128
On 2020-10-01 15:46, Jonathan Wakely wrote: > I hope WG14 will adopt something like > http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2465.pdf and the > whole mess will go away. > > intmax_t will be deprecated, and implementations can provide 128-bit > integers without caveats. On 2020-10-01 19:31, Joseph Myers wrote: On Thu, 1 Oct 2020, Alejandro Colomar via Gcc wrote: Because 'intmax_t' has a bug (actually I know GCC rejected the bug report, but the problem is still there and users should be informed about this) which is related to __int128. __int128 is not an integer type as defined by any existing version of ISO C, precisely because it's wider than intmax_t, and changing intmax_t would be a big ABI problem (involving new symbol versions for about 100 printf/scanf-related functions in glibc, 200 on platforms with multiple long double variants). See the proposed removal of intmax_t in C2x (accepted in principle at the first virtual Freiburg meeting, but so far without any wording accepted for any specific approach to removal regarding e.g. preprocessor arithmetic and other places depending on intmax_t). That removal would allow __int128 to be considered an extended integer type as defined by C2x and later (with int128_t typedef in , etc.), if desired. Thanks for pointing out that the standard acknowledges the bug in [u]intmax_t. It's good to know. Also good to know they plan to fix it. Thanks, Alex
Re: [PATCH v2 1/2] system_data_types.7: Add 'void *'
Hi Paul, On 2020-10-01 19:32, Paul Eggert wrote: > If you're going to document this at all, I suggest documenting 'void' as > well as 'void *', and putting both sets of documentation into the same > man page. > All the types we're documenting are in the same page: system_data_types(7). And then we have links with the name of each type. And yes, I also pretend to document 'void'. > For 'void *' you should also mention that one cannot use arithmetic on > void * pointers, so they're special in that way too. Good suggestion! > Also, you should > warn that because one can convert from any pointer type to void * and > then to any other pointer type, it's a deliberate hole in C's > type-checking. Also good. I'll talk about generic function parameters for this. > It might not also hurt to mention 'void const *', 'void > volatile *', 'void const volatile *', etc. Those are qualifiers for the type, and I don't see how any of them would apply differently to 'void *' than to any other pointer type (or any type at all), so I think they don't belong to system_data_types(7). However, it might be good that someone starts a page called 'type_qualifiers(7)' or something like that. I would love that someone documents 'volatile' correctly, as there aren't many good sources about it. If someone who knows when to use --and especially when not to use-- 'volatile', is reading this, think about it :-) I still wonder if I used it correctly in the few cases I've had to. BTW, I'll CC the LKML. > > For 'void' you can mention the usual things, such as functions returning > void, and functions declared with (void) parameters, why one would want > to cast to (void), and so forth. Yes, I was thinking about that. > > You're starting to document the C language here, and if you're going to > do that you might as well do it right. I'm trying to do so :) Thanks, Alex
Re: [PATCH v2 1/4] system_data_types.7: Add int_leastN_t family of types
Hi Paul, On 2020-10-01 19:38, Paul Eggert wrote: > On 10/1/20 7:35 AM, Alejandro Colomar via Libc-alpha wrote: >> +The narrowest signed integer type >> +of a width of at least N bits, > > Motivation is missing here. Why is there an int_leastN_t type at all? Well, I'd say the motivation is for the standard to allow unicorn implementations that have types that are not of normal widths For example, this allows an implementation to have an int of 33 bits, have int_least32_t be that int, and then not provide int32_t. But, I'd say that writing this information in the man would only confuse readers, would not be helpful because those are actually unicorns. The few programmers that may need that info might better go to the standard. > Also, on all glibc platforms, int_leastN_t is equivalent to intN_t; this > should probably be mentioned. We deliberately decided to not give any information on this. Unless there's a strict requirement by the standard, or there's some very good reason for it, the programmer should treat typedefs as what they actaully are: opaque types with some width, signedness and other requirements, which we document here. > > Similarly for int_fastN_t. Same as above. Thanks, Alex
Re: [PATCH v2 1/2] system_data_types.7: Add 'void *'
Hi Michael, On 2020-10-02 10:24, Alejandro Colomar wrote: On 2020-10-01 19:32, Paul Eggert wrote: > For 'void *' you should also mention that one cannot use arithmetic on > void * pointers, so they're special in that way too. Good suggestion! > Also, you should > warn that because one can convert from any pointer type to void * and > then to any other pointer type, it's a deliberate hole in C's > type-checking. Also good. I'll talk about generic function parameters for this. I think the patch as is now is complete enough to be added. So I won't rewrite it for now. Please review the patch as is, and I'll add more info to this type in the future. Thanks, Alex
RE: [PATCH v2 1/2] system_data_types.7: Add 'void *'
From: Alejandro Colomar > Sent: 02 October 2020 09:25 > > For 'void *' you should also mention that one cannot use arithmetic on > > void * pointers, so they're special in that way too. > > Good suggestion! Except that is a gcc extension that is allowed in the kernel. > > Also, you should > > warn that because one can convert from any pointer type to void * and > > then to any other pointer type, it's a deliberate hole in C's > > type-checking. > > Also good. I'll talk about generic function parameters for this. That isn't what the C standard says at all. What is says is that you can cast any data pointer to 'void *' and then cast it back to the same type. This matters because the compiler will 'remember' structure alignment through 'void *' casts. So you can't use memcpy() to copy from a potentially misaligned (typed) pointer. 'void *' should only be used for structures that are 'a sequence of bytes'. (eg things that look a bit like read() or write()). David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
Re: Git rejecting branch merge
On Fri, 2 Oct 2020 at 08:14, Martin Liška wrote: > > On 10/2/20 2:52 AM, Joel Brobecker wrote: > >>> I wonder I can get the branch moved, so I can do the benchmarking :) > >>> Any suggestions how to do that? > > > > I just installed a small patch, hot-fix style which I am hoping will > > fix your problem. Can you try it? It passes the testsuite, so the change > > should be safe. > > I can confirm I was able to delete a branch on remove server: > > $ git push origin --delete refs/users/marxin/heads/gfc-trailing-spec > To git+ssh://gcc.gnu.org/git/gcc.git > - [deleted] refs/users/marxin/heads/gfc-trailing-spec That's because I fixed GCC's hook to allow branch deletion: https://gcc.gnu.org/pipermail/gcc/2020-October/233914.html
Re: [PATCH v2 1/2] system_data_types.7: Add 'void *'
On Fri, 2 Oct 2020 at 09:28, Alejandro Colomar via Gcc wrote: > However, it might be good that someone starts a page called > 'type_qualifiers(7)' or something like that. Who is this for? Who is trying to learn C from man pages? Should somebody stop them?
Re: [PATCH v2 1/2] system_data_types.7: Add 'void *'
On Fri, 2 Oct 2020 at 12:49, Jonathan Wakely wrote: > > On Fri, 2 Oct 2020 at 09:28, Alejandro Colomar via Gcc > wrote: > > However, it might be good that someone starts a page called > > 'type_qualifiers(7)' or something like that. > > Who is this for? Who is trying to learn C from man pages? Should > somebody stop them? Yes, I think so. To add context, Alex has been doing a lot of work to build up the new system_data_types(7) page [1], which I think is especially useful for the POSIX system data types that are used with various APIs. With the addition of the integer types and 'void *' things are straying somewhat from POSIX into C. I think there is value in saying something about those types, but I'm somewhat neutral about their inclusion in the page. But Alex has done the work, and I'm willing to include those types in the page. I do think that something like type_qualifiers(7) strays over the line of what should be covered in Linux man-pages, which are primarily about the kernel + libc APIs. [2] Thanks, Michael [1] https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git/tree/man7/system_data_types.7 [2] Mind you, man-pages trayed over the line already very many years ago with operators(7), because who ever remembers all of the C operator precedences. -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/
Re: [PATCH v2 1/2] system_data_types.7: Add 'void *'
Hi Alex, On 10/2/20 10:48 AM, Alejandro Colomar wrote: > Hi Michael, > > On 2020-10-02 10:24, Alejandro Colomar wrote: >> On 2020-10-01 19:32, Paul Eggert wrote: >> > For 'void *' you should also mention that one cannot use arithmetic on >> > void * pointers, so they're special in that way too. >> >> Good suggestion! >> >> > Also, you should >> > warn that because one can convert from any pointer type to void * and >> > then to any other pointer type, it's a deliberate hole in C's >> > type-checking. >> >> Also good. I'll talk about generic function parameters for this. > I think the patch as is now is complete enough to be added. > > So I won't rewrite it for now. > Please review the patch as is, > and I'll add more info to this type in the future. Actually, I would rather prefer one patch series, rather than patches on patches please. It also makes review of the overall 'void *' text easier if it's all one patch. So, If you could squash the patches together and resubmit, that would be helful. Thanks, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/
Re: [PATCH v2 1/2] system_data_types.7: Add 'void *'
Hi Alex, On 10/1/20 6:55 PM, Alejandro Colomar wrote: > > > On 2020-10-01 18:38, Michael Kerrisk (man-pages) wrote: >> Hi Alex, >> >>> +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. >> I know you are correct about POSIX, but which part of the >> standard did you find this information in? The only >> reference that I find in POSIX is the dlsym() spec. Is it >> covered also somewhere else in the standrd? >> >> Thanks, >> >> Michael >> > > Hi Michael, > > I've bean searching, and dlsym is the only one: > > > > user@debian:~/Desktop/src/Standards/susv4-2018$ grep -rn "pointer to a > function" > functions/regfree.html:530:"undefined" means that the action > by the application is an error, of similar severity to passing a bad > pointer to a function. > functions/dlsym.html:138:Note that conversion from a void * > pointer to a function pointer as in: > functions/regcomp.html:530:"undefined" means that the action > by the application is an error, of similar severity to passing a bad > pointer to a function. > functions/regexec.html:530:"undefined" means that the action > by the application is an error, of similar severity to passing a bad > pointer to a function. > functions/V2_chap02.html:3039:There are three types of action that > can be associated with a signal: SIG_DFL, SIG_IGN, or a pointer to a > function. Initially, > functions/regerror.html:530:"undefined" means that the action > by the application is an error, of similar severity to passing a bad > pointer to a function. > user@debian:~/Desktop/src/Standards/susv4-2018$ grep -rn "function pointer" > basedefs/glob.h.html:165:"../functions/glob.html">glob() > prototype definition by removing the restrict qualifier from the > function pointer > xrat/V4_xsh_chap02.html:114:when the application requires it; for > example, if its address is to be stored in a function pointer variable. > functions/dlsym.html:138:Note that conversion from a void * > pointer to a function pointer as in: > user@debian:~/Desktop/src/Standards/susv4-2018$ grep -rn "pointer to > function" > functions/dlsym.html:73:converted from type pointer to function to type > pointer to void; otherwise, dlsym() shall return the > address of the > user@debian:~/Desktop/src/Standards/susv4-2018$ > > From those, the only one that documents this is functions/dlsym. > The rest is noise. > > The most explicit paragraph in dlsym is the following: > > [[ > Note that conversion from a void * pointer to a function pointer as in: > > fptr = (int (*)(int))dlsym(handle, "my_function"); > > is not defined by the ISO C standard. > This standard requires this conversion to work correctly > on conforming implementations. > ]] Okay -- so, one more thing for a revised (squashed) patch. I think you better say that that POSIX requirements exists only since POS0X.1-2008 Technical Corrigendum 1 (2013). Thanks, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/
Re: Git rejecting branch merge
> > I can confirm I was able to delete a branch on remove server: > > > > $ git push origin --delete refs/users/marxin/heads/gfc-trailing-spec > > To git+ssh://gcc.gnu.org/git/gcc.git > > - [deleted] refs/users/marxin/heads/gfc-trailing-spec > > That's because I fixed GCC's hook to allow branch deletion: > https://gcc.gnu.org/pipermail/gcc/2020-October/233914.html Interesting that you would manage this aspect yourselves. The git-hooks have a config option that allow to control which branch can be deleted (via a list of regular expressions). -- Joel
Re: Git rejecting branch merge
On Fri, 2 Oct 2020 at 13:19, Joel Brobecker wrote:
>
> > > I can confirm I was able to delete a branch on remove server:
> > >
> > > $ git push origin --delete refs/users/marxin/heads/gfc-trailing-spec
> > > To git+ssh://gcc.gnu.org/git/gcc.git
> > > - [deleted] refs/users/marxin/heads/gfc-trailing-spec
> >
> > That's because I fixed GCC's hook to allow branch deletion:
> > https://gcc.gnu.org/pipermail/gcc/2020-October/233914.html
>
> Interesting that you would manage this aspect yourselves.
> The git-hooks have a config option that allow to control which branch
> can be deleted (via a list of regular expressions).
Which is what Joseph said, I think. The problem was that the
update_hook script still gets called for branch deletions, and it was
rejecting them. My fix was just to stop rejecting them:
Author: Jonathan Wakely
Date: Thu Oct 1 18:04:54 2020 +
Do not check anything for ref deletions
diff --git a/update_hook b/update_hook
index 8b342b5..a392230 100755
--- a/update_hook
+++ b/update_hook
@@ -12,6 +12,9 @@ def main():
ref_name = sys.argv[1]
old_object = sys.argv[2]
new_object = sys.argv[3]
+if re.fullmatch('0+', new_object) is not None:
+# This is a branch deletion.
+sys.exit(0)
# Do not allow updates introducing ancestry based on the old
# git-svn repository, to ensure people rebase onto the new history
# rather than merging branches based on git-svn history into those
Maybe the hooks.update-hook script should not be called at all for ref
deletions, if they are meant to be handled elsewhere.
Re: [PATCH v2 1/2] system_data_types.7: Add 'void *'
On Fri, 2 Oct 2020 at 12:31, Michael Kerrisk (man-pages) wrote: > > On Fri, 2 Oct 2020 at 12:49, Jonathan Wakely wrote: > > > > On Fri, 2 Oct 2020 at 09:28, Alejandro Colomar via Gcc > > wrote: > > > However, it might be good that someone starts a page called > > > 'type_qualifiers(7)' or something like that. > > > > Who is this for? Who is trying to learn C from man pages? Should > > somebody stop them? > > Yes, I think so. To add context, Alex has been doing a lot of work to > build up the new system_data_types(7) page [1], which I think is > especially useful for the POSIX system data types that are used with > various APIs. It's definitely useful for types like struct siginfo_t and struct timeval, which aren't in C. Trying to document C seems like a huge task, ill-suited for man-pages, and not worth the effort. Maybe some people prefer man pages, but for everybody else https://en.cppreference.com/w/c already exists and seems like a better use of time.
Re: [PATCH v2 1/4] system_data_types.7: Add int_leastN_t family of types
On Fri, 2 Oct 2020 at 09:36, Alejandro Colomar via Gcc wrote: > > Hi Paul, > > On 2020-10-01 19:38, Paul Eggert wrote: > > On 10/1/20 7:35 AM, Alejandro Colomar via Libc-alpha wrote: > >> +The narrowest signed integer type > >> +of a width of at least N bits, > > > > Motivation is missing here. Why is there an int_leastN_t type at all? > > Well, I'd say the motivation is for the standard to allow > unicorn implementations that have types that are not of normal widths > For example, this allows an implementation to have an int of 33 bits, > have int_least32_t be that int, and then not provide int32_t. C allows that, but POSIX says int32_t is required.
Re: [PATCH 0/2] Document void *
On Thu, 1 Oct 2020 at 16:51, Alejandro Colomar via Gcc wrote: > > Hi Michael, > > On 2020-10-01 17:34, Michael Kerrisk (man-pages) wrote: > > Hello Alex, > > > > On 10/1/20 5:06 PM, Alejandro Colomar wrote: > >> Hello Michael, > >> > >> This type is very special, > >> so I will probably have missed some details about it. > > > > I do wonder if we actually need this in page at all, and given: > > > I think it should be. > I would also document 'void', even if it's a bit weird... > They are very useful, so why not document them? Because the man-pages are not a tutorial for the C language. "The Linux man-pages project documents the Linux kernel and C library interfaces that are employed by user-space programs." void and void* are not APIs.
Re: [PATCH v2 1/2] system_data_types.7: Add 'void *'
On 2020-10-02 15:06, Jonathan Wakely wrote: > On Fri, 2 Oct 2020 at 12:31, Michael Kerrisk (man-pages) > wrote: >> >> On Fri, 2 Oct 2020 at 12:49, Jonathan Wakely wrote: >>> >>> On Fri, 2 Oct 2020 at 09:28, Alejandro Colomar via Gcc wrote: However, it might be good that someone starts a page called 'type_qualifiers(7)' or something like that. >>> >>> Who is this for? Who is trying to learn C from man pages? Should >>> somebody stop them? >> >> Yes, I think so. To add context, Alex has been doing a lot of work to >> build up the new system_data_types(7) page [1], which I think is >> especially useful for the POSIX system data types that are used with >> various APIs. > > It's definitely useful for types like struct siginfo_t and struct > timeval, which aren't in C. Hi Jonathan, But then the line is a bit diffuse. Would you document 'ssize_t' and not 'size_t'? Would you not document intN_t types? Would you document stdint types, including 'intptr_t', and not 'void *'? I guess the basic types (int, long, ...) can be left out for now, and apart from 'int' those rarely are the most appropriate types for most uses. But other than that, I would document all of the types. And even... when all of the other types are documented, it will be only a little extra effort to document those, so in the future I might consider that. But yes, priority should probably go to Linux/POSIX-only types. Thanks, Alex > > Trying to document C seems like a huge task, ill-suited for man-pages, > and not worth the effort. > > Maybe some people prefer man pages, but for everybody else > https://en.cppreference.com/w/c already exists and seems like a better > use of time. >
Re: Git rejecting branch merge
> Which is what Joseph said, I think. The problem was that the
> update_hook script still gets called for branch deletions, and it was
> rejecting them. My fix was just to stop rejecting them:
>
> Author: Jonathan Wakely
> Date: Thu Oct 1 18:04:54 2020 +
>
>Do not check anything for ref deletions
>
> diff --git a/update_hook b/update_hook
> index 8b342b5..a392230 100755
> --- a/update_hook
> +++ b/update_hook
> @@ -12,6 +12,9 @@ def main():
> ref_name = sys.argv[1]
> old_object = sys.argv[2]
> new_object = sys.argv[3]
> +if re.fullmatch('0+', new_object) is not None:
> +# This is a branch deletion.
> +sys.exit(0)
> # Do not allow updates introducing ancestry based on the old
> # git-svn repository, to ensure people rebase onto the new history
> # rather than merging branches based on git-svn history into those
>
>
>
> Maybe the hooks.update-hook script should not be called at all for ref
> deletions, if they are meant to be handled elsewhere.
Thanks for explaining the context; the script was being called by
the git-hooks via the update-hook config option. I understand better,
now, and the way you handled it seems right to me.
--
Joel
Re: [PATCH v2 1/2] system_data_types.7: Add 'void *'
On Fri, 2 Oct 2020 at 14:20, Alejandro Colomar wrote: > > > > On 2020-10-02 15:06, Jonathan Wakely wrote: > > On Fri, 2 Oct 2020 at 12:31, Michael Kerrisk (man-pages) > > wrote: > >> > >> On Fri, 2 Oct 2020 at 12:49, Jonathan Wakely > wrote: > >>> > >>> On Fri, 2 Oct 2020 at 09:28, Alejandro Colomar via Gcc > wrote: > However, it might be good that someone starts a page called > 'type_qualifiers(7)' or something like that. > >>> > >>> Who is this for? Who is trying to learn C from man pages? Should > >>> somebody stop them? > >> > >> Yes, I think so. To add context, Alex has been doing a lot of work to > >> build up the new system_data_types(7) page [1], which I think is > >> especially useful for the POSIX system data types that are used with > >> various APIs. > > > > It's definitely useful for types like struct siginfo_t and struct > > timeval, which aren't in C. > > Hi Jonathan, > > But then the line is a bit diffuse. > Would you document 'ssize_t' and not 'size_t'? Yes. My documentation for ssize_t would mention size_t, refer to the C standard, and not define it. > Would you not document intN_t types? > Would you document stdint types, including 'intptr_t', and not 'void *'? I would document neither. I can see some small value in documenting size_t and the stdint types, as they are technically defined by the libc headers. But documenting void* seems very silly. It's one of the most fundamental built-in parts of the C language, not an interface provided by the system. > I guess the basic types (int, long, ...) can be left out for now, I should hope so! > and apart from 'int' those rarely are the most appropriate types > for most uses. > But other than that, I would document all of the types. > And even... when all of the other types are documented, > it will be only a little extra effort to document those, > so in the future I might consider that. [insert Jurassic Park meme "Your scientists were so preoccupied with whether or not they could, they didn't stop to think if they should." ] I don't see value in bloating the man-pages with information nobody will ever use, and which doesn't (IMHO) belong there anyway. We seem to fundamentally disagree about what the man pages are for. I don't think they are supposed to teach C programming from scratch. > But yes, priority should probably go to Linux/POSIX-only types.
Re: [PATCH v2 1/2] system_data_types.7: Add 'void *'
Hi Jonathan, On 2020-10-02 15:27, Jonathan Wakely wrote: On Fri, 2 Oct 2020 at 14:20, Alejandro Colomar wrote: On 2020-10-02 15:06, Jonathan Wakely wrote: > On Fri, 2 Oct 2020 at 12:31, Michael Kerrisk (man-pages) > wrote: >> >> On Fri, 2 Oct 2020 at 12:49, Jonathan Wakely wrote: >>> >>> On Fri, 2 Oct 2020 at 09:28, Alejandro Colomar via Gcc wrote: However, it might be good that someone starts a page called 'type_qualifiers(7)' or something like that. >>> >>> Who is this for? Who is trying to learn C from man pages? Should >>> somebody stop them? >> >> Yes, I think so. To add context, Alex has been doing a lot of work to >> build up the new system_data_types(7) page [1], which I think is >> especially useful for the POSIX system data types that are used with >> various APIs. > > It's definitely useful for types like struct siginfo_t and struct > timeval, which aren't in C. Hi Jonathan, But then the line is a bit diffuse. Would you document 'ssize_t' and not 'size_t'? Yes. My documentation for ssize_t would mention size_t, refer to the C standard, and not define it. Would you not document intN_t types? Would you document stdint types, including 'intptr_t', and not 'void *'? I would document neither. I can see some small value in documenting size_t and the stdint types, as they are technically defined by the libc headers. But documenting void* seems very silly. It's one of the most fundamental built-in parts of the C language, not an interface provided by the system. I guess the basic types (int, long, ...) can be left out for now, I should hope so! and apart from 'int' those rarely are the most appropriate types for most uses. But other than that, I would document all of the types. And even... when all of the other types are documented, it will be only a little extra effort to document those, so in the future I might consider that. [insert Jurassic Park meme "Your scientists were so preoccupied with whether or not they could, they didn't stop to think if they should." ] I don't see value in bloating the man-pages with information nobody will ever use, and which doesn't (IMHO) belong there anyway. We seem to fundamentally disagree about what the man pages are for. I don't think they are supposed to teach C programming from scratch. Agree in part. I'll try to think about it again. In the meantime, I trust Michael to tell me when something is way off :) Thanks, really! Alex But yes, priority should probably go to Linux/POSIX-only types.
Re: [PATCH v2 1/2] system_data_types.7: Add 'void *'
On 10/2/20 2:10 AM, David Laight wrote: > Also, you should > warn that because one can convert from any pointer type to void * and > then to any other pointer type, it's a deliberate hole in C's > type-checking. That isn't what the C standard says at all. What is says is that you can cast any data pointer to 'void *' and then cast it back to the same type. I was talking about compile-time checking; you're talking about run-time behavior. We're both right in our own domains. It is a tricky area, and this suggests that perhaps we shouldn't be trying to document this stuff in a libc/kernel manual.
gcc-9-20201002 is now available
Snapshot gcc-9-20201002 is now available on https://gcc.gnu.org/pub/gcc/snapshots/9-20201002/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 9 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch releases/gcc-9 revision 54e50dc2d7633d1d5930f472aaeb4e52ba403ade You'll find: gcc-9-20201002.tar.xzComplete GCC SHA256=725a510d6b4b98721058d60863bf0a68b4b4f1d55cd92be41c6c95d135bbd656 SHA1=13f0749bb6098b0189a9cc7845bf6f8d46552324 Diffs from 9-20200925 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-9 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
