Re: Adding ?
Date:Thu, 13 May 2021 16:00:56 -0700 From:John Nemeth Message-ID: <202105132300.14dn0uwz026...@server.cornerstoneservice.ca> | On May 13, 22:37, Joerg Sonnenberger wrote: | } The source is wrong to request strict C++14 | } compatibility and then use an extension. I do not agree with that. Whether or not it is the right thing to do in a particular case can be debated (I have always believed alloca to be an evil hack, and never justifiable, but...) but the general idea of "standard but for this one thing" (or small enumerated set of things) is a perfectly reasonable approach. Much better than "the standard is not good enough for me, so anything goes". | This comment reminds me of Henry Spencer's "All the World's | a VAX" comment: It shouldn't, different issue entirely. | However, the reality is that Linux sets the standard, No POSIX does that. Most serious developers will try to live with what POSIX provides when it is pointed out to them, but there are cases when that is not possible. Then we need to decide if the linux (or android which is often similar) or macos, or ... way is acceptable, avoiding NIH as much as possible, while not accepting garbage just because they (whoever they are) did it first. kre
Re: Adding ?
On May 13, 22:37, Joerg Sonnenberger wrote: } On Thu, May 13, 2021 at 09:58:50PM +0200, JaromÃr DoleÄek wrote: } > Le jeu. 13 mai 2021 à 21:44, Joerg Sonnenberger a écrit : } > > > No we don't, unless you are using PCC :D } > > > } > > > The block in only provides an alloca(3) prototype, and only } > > > if the compiler already #defines alloca as __builtin_alloca. } > > > } > > > While this works for gcc in some -std modes (e.g. gnu++14), it does } > > > not in others (c++14, c++11). } > > } > > Your analysis is wrong. We don't provide a prototype in standard modes } > > as that violates the user request. The prototype is enough to trigger } > > the builtin logic in GCC and Clang. } > } > Allright. } > } > Anyway, would it be wrong to add which unconditionally } > makes alloca() use the builtin, similar to what e.g. glibc (Linux) and } > FreeBSD do, or is it fundamentally wrong doing so? } } I don't see the point in it. The source is wrong to request strict C++14 } compatibility and then use an extension. Just because Linux folks do } that wrong doesn't mean we should cater to their bugs. This comment reminds me of Henry Spencer's "All the World's a VAX" comment: https://www.brcline.com/blog/the-ten-commandments-for-c-programmers . In a way, he is correct (adjusted for time of original posting). However, the reality is that Linux sets the standard, whether we like it or not. There are situations where we are going to have to bite the bullet and accept things that are impure. Whether or not this is one of those situations is current subject of debate. }-- End of excerpt from Joerg Sonnenberger
Re: Adding ?
On Thu, May 13, 2021 at 09:58:50PM +0200, Jaromír Doleček wrote: > Le jeu. 13 mai 2021 à 21:44, Joerg Sonnenberger a écrit : > > > No we don't, unless you are using PCC :D > > > > > > The block in only provides an alloca(3) prototype, and only > > > if the compiler already #defines alloca as __builtin_alloca. > > > > > > While this works for gcc in some -std modes (e.g. gnu++14), it does > > > not in others (c++14, c++11). > > > > Your analysis is wrong. We don't provide a prototype in standard modes > > as that violates the user request. The prototype is enough to trigger > > the builtin logic in GCC and Clang. > > Allright. > > Anyway, would it be wrong to add which unconditionally > makes alloca() use the builtin, similar to what e.g. glibc (Linux) and > FreeBSD do, or is it fundamentally wrong doing so? I don't see the point in it. The source is wrong to request strict C++14 compatibility and then use an extension. Just because Linux folks do that wrong doesn't mean we should cater to their bugs. Joerg
Re: Adding ?
Le jeu. 13 mai 2021 à 21:44, Joerg Sonnenberger a écrit : > > No we don't, unless you are using PCC :D > > > > The block in only provides an alloca(3) prototype, and only > > if the compiler already #defines alloca as __builtin_alloca. > > > > While this works for gcc in some -std modes (e.g. gnu++14), it does > > not in others (c++14, c++11). > > Your analysis is wrong. We don't provide a prototype in standard modes > as that violates the user request. The prototype is enough to trigger > the builtin logic in GCC and Clang. Allright. Anyway, would it be wrong to add which unconditionally makes alloca() use the builtin, similar to what e.g. glibc (Linux) and FreeBSD do, or is it fundamentally wrong doing so? Jaromir
Re: Adding ?
On Thu, May 13, 2021 at 12:51:45PM +0200, Jaromír Doleček wrote: > Le jeu. 13 mai 2021 à 01:04, Joerg Sonnenberger a écrit : > > > > On Wed, May 12, 2021 at 08:32:20PM +0200, Jaromír Doleček wrote: > > > Le mer. 12 mai 2021 à 13:50, Joerg Sonnenberger a écrit : > > > > > > > > On Wed, May 12, 2021 at 08:38:39AM +0200, Jaromír Doleček wrote: > > > > > would it be a bad thing to add a compatibility which would > > > > > use the builtin alloca() instead of the libc one when available? > > > > > > > > > > e.g. MySQL 8.0.* seems to rely on this. > > > > > > > > We provide it in stdlib.h as long as a standard mode is not set. > > > > I don't see the point of adding alloca.h. > > > > > > We don't provide the builtin in stdlib.h. > > > > Yes, we do. > > No we don't, unless you are using PCC :D > > The block in only provides an alloca(3) prototype, and only > if the compiler already #defines alloca as __builtin_alloca. > > While this works for gcc in some -std modes (e.g. gnu++14), it does > not in others (c++14, c++11). Your analysis is wrong. We don't provide a prototype in standard modes as that violates the user request. The prototype is enough to trigger the builtin logic in GCC and Clang. Joerg
Re: Adding ?
Le jeu. 13 mai 2021 à 12:58, Martin Husemann a écrit : > > On Thu, May 13, 2021 at 12:51:45PM +0200, Jaromír Dole?ek wrote: > > On the contrary, Linux explicitely #undefs alloca(), then > > #define alloca() as __builtin_alloca(), so it always works, regardless > > which -std. > > But isn't that obviously wrong and our version the correct one? > (Well, maybe we should never provide anything if there is no > __builtin_alloca()) It does the #define alloca guarded with #ifdef __GNUC__, so it's fine as long as you don't expect this header to work with <= gcc 2. Jaromir
Re: Adding ?
On Thu, May 13, 2021 at 12:51:45PM +0200, Jaromír Dole?ek wrote: > On the contrary, Linux explicitely #undefs alloca(), then > #define alloca() as __builtin_alloca(), so it always works, regardless > which -std. But isn't that obviously wrong and our version the correct one? (Well, maybe we should never provide anything if there is no __builtin_alloca()) Martin
Re: Adding ?
Le jeu. 13 mai 2021 à 01:04, Joerg Sonnenberger a écrit : > > On Wed, May 12, 2021 at 08:32:20PM +0200, Jaromír Doleček wrote: > > Le mer. 12 mai 2021 à 13:50, Joerg Sonnenberger a écrit : > > > > > > On Wed, May 12, 2021 at 08:38:39AM +0200, Jaromír Doleček wrote: > > > > would it be a bad thing to add a compatibility which would > > > > use the builtin alloca() instead of the libc one when available? > > > > > > > > e.g. MySQL 8.0.* seems to rely on this. > > > > > > We provide it in stdlib.h as long as a standard mode is not set. > > > I don't see the point of adding alloca.h. > > > > We don't provide the builtin in stdlib.h. > > Yes, we do. No we don't, unless you are using PCC :D The block in only provides an alloca(3) prototype, and only if the compiler already #defines alloca as __builtin_alloca. While this works for gcc in some -std modes (e.g. gnu++14), it does not in others (c++14, c++11). On the contrary, Linux explicitely #undefs alloca(), then #define alloca() as __builtin_alloca(), so it always works, regardless which -std. Jaromir
